syackey@entec.Wichita.NCR.COM (Steve Yackey) (12/09/88)
We are trying to develop a conformance test "strategy" for our tcp/ip based network products. This includes tcp and ip as well as some standard applications like smtp, ftp, telnet etc... Questions came up like - Should we test for conformance with the mil-stds or the rfc's ? Is there significant difference between the two ? Is there a notion that one is "better" than the other ? If there is a difference, how are these resolved (who changes)? thanx, yackman pcfsomh.
braden@VENERA.ISI.EDU (12/22/88)
[3:5] "Military Standard Internet Protocol," MIL-STD-1777,
Department of Defense, August 1983.
This specification, as amended by RFC-963, is intended to
describe the Internet Protocol but has some serious omissions
(e.g., the mandatory subnet extension of RFC-950). It is
also out of date. If there is a conflict, RFC-791, RFC-792,
and RFC-950 must be taken as authoritative.
[4.2:2] "Transmission Control Protocol," MIL-STD-1778, US
Department of Defense, August 1984.
This specification as amended by RFC-964 is intended to
describe the same protocol as RFC-793 [4.2:1]. If there
is a conflict, RFC-793 takes precedence.
[5.2:3] "File Transfer Protocol," MIL-STD-1780, Department of
Defense.
This Mil-Std is based on an earlier version of the FTP
specification (RFC-765) and is obsolete.
A future revision of RFC-1083, "IAB Official Protocol Standards", will
describe the primacy of the RFC's over the MilStd's. Unfortunately, the
DoD has chosen not to correct or update the MilStd's for a long time.
In implementing TCP or IP, you may find reading them somewhat helpful as
background material, but you must be aware that they are seriously out
of date in some areas. RFC-1009 and the soon-to-be-published Host
Requirements RFC take precedence over MilStds and protocol RFC's.
Bob Bradenstjohns@BEAST.DDN.MIL (Mike St. Johns) (12/23/88)
About the time the MIL STDs were being completed, DOD made the decision to do no further work on them after publishing - believing that ISO was just around the corner. I guess what I'm trying to say is that it's a feature, not a bug! Mike
jbn@glacier.STANFORD.EDU (John B. Nagle) (12/24/88)
In article <8812211742.AA04654@braden.isi.edu> braden@VENERA.ISI.EDU writes: >Unfortunately, the >DoD has chosen not to correct or update the MilStd's for a long time. Well, actually, DCA did fund an update of the TCP MIL-STD in 1985, but the contractor doing the work (whom I will not name) spent all the money and didn't finish the job. This discouraged further efforts in that direction. John Nagle
braden@VENERA.ISI.EDU (12/27/88)
In article <8812211742.AA04654@braden.isi.edu> braden@VENERA.ISI.EDU writes: >Unfortunately, the >DoD has chosen not to correct or update the MilStd's for a long time. Well, actually, DCA did fund an update of the TCP MIL-STD in 1985, but the contractor doing the work (whom I will not name) spent all the money and didn't finish the job. This discouraged further efforts in that direction. John Nagle John, From my experience, I suspect that what this proves is that one cannot procure intellectual effort through the same administrative machinery that one uses to buy, say, tank radios, and have any reasonable hope for success. I claim that the design and engineering of protocols is still intellectual effort, and it requires the large-scale collaboration of the entire technical community of the Internet. I therefore suspect it was the process, not the vendor, that was broken in the DCA protocol efforts. Bob Braden
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (12/27/88)
Bob: I doubt that the vendor's failure to perform proves anything about the DoD procurement regulations and/or methodologies. For example, I was able to read your message suggesting that there is a fault over a communication network procured under the same procurement regulations. Without the benefit of reading DCA's Request For Proposal, the only things that might be inferred from the vendor's failure is A) this was a rather blatant "buy-in" by an under-capitalized company in hopes procuring further contracts, B) the individuals assigned to the project did not have the technical background necessary to translate the RFCs into a MIL-STD, or C) there was a requirement for the documents to conform to 2167 standards which were not negotiated correctly. Merton
Mills@UDEL.EDU (12/28/88)
Bob, As one of the participants in the 1985 DCA update of the TCP and IP specs (along with several others, including John), I was dismayed that the good stuff contributed did not appear as an RFC, at least. Part of that was the contractor's fault and part of that was probably ours in not insisting that whatever was produced and turned in to DCA is made available for electronic or even OCR hijack. I suggest a polite inquiry from you or Phil Gross to DCA in your official capacities might even make that happen. Dave
Mills@UDEL.EDU (12/28/88)
Merton, DCA funded the effort as a task order, which was subcontracted to various parties. The prime contractor was to formulate specific amendments to the MIL-STD-1777 and -1778, documents (which the prime contractor in fact wrote). but so far as I know was not to redraft the documents themselves. The subcontractors submitted rough-draft proposals, which were then redrafted into a report and submitted to DCA. While it is not clear in what form that report was submitted, at least some of the proposals made it out to the community for discussion and comment. I remember a series of amendments to the ICMP RFC which were managed in this way. Somewhere in my 20,000- message mail archives scattered over three TOPS-20s, several Unix systems and a Fuzzball in a pear tree is a massive message containing the dozens of messages contributed to this effort. In a day or two I might even be able to excavate that treasure from the mounds of dusty archive tapes and then it might take me much longer than that. I don't relish that chore and I suppose the prime contractor doesn't either, especially since the knowledgable people and bit buckets have probably since gone on to a better life. While I am no defender of the Government contracting process (having done my own bit in that area), I don't think the prime contractor, the subcontractors or DCA did anything specifically wrong. I would, however, like to yet and once again plead to the DCA protocol standards committees that information such as this should be routinely shared with the IETF and given the widest possible distribution. Dave
mcc@ETN-WLV.EATON.COM (Merton Campbell Crockett) (12/28/88)
Dave: I'm not a defender of the DoD procurement process; however, I do think Bob's comment that the failure of some organisation to produce a new MIL-STD draft for DCA is proof of the inadequacy of the DoD procurement process is unjust- ified. I don't mean to imply that there isn't a problem with the process-- I personally think that Congress over-reacted to some abuses that occurred during the '50s. I, also, think that Congress made some mistakes in the guise of "equal opportunity" during the '60s and '70s. Merton