Comments within and below. > Actually, you and I are not as much in disagreement as it might seem at > first. > Unfortunately, the reality is that some RFCs don't track industry > practice. I would say 1812 is the definitive document, but I would > also agree this is largely by reference rather than official > supercession. We agree. > At the London IETF a couple of weeks ago, some people (I'd have to > dig up names, but I think they are at USC/ISI, where the RFC Editor > function lives) said they are actively working on an update to the > host requirements document. I didn't have a chance to ask whether > they are also thinking of an 1812 update so the pair of documents are > again more or less in sync. I do plan to follow up on this. The > discussion was in the PTOMAINE BOF, so it isn't even a WG yet that > could act as a home for these documents. I'd suspect they would be > directly overseen by the IESG. Maybe it's just my feeble impression, but it seems that a lot of what was previously done at the ISI when John Postel was there is languishing now. RFC 1700 is a good example. It was semi-regularly updated (previous editions were 1340, 1060, 1010, 990, 960, etc.) and now it ot stalled in a 1994 edition that is for all intents and purposes obsolete without replacement. I know what is posted on the web site. It indicates that the protocols and ports page is the current practice for what was covered by RFC 1700, but that misses a salient point. RFCs were meant to be very portable. They were meant to be read by ASCII text readers of all flavors. HTML, while very good for many things, is probably not the best medium of transport for RFCs. That's just my silly opinion and nothing else. In the same vein. Another person posted a request/comment regarding ports and what is used for a particular application. The issue is not one easily and readily resolved. If you go to RFC 1700, all ports are listed as registered for both TCP and UDP. I believe Jon Postel originally did it this way so as not to constrain an application on a given port to use one transport mechanism only. Somebody could come along a few years later and invent a better mousetrap and redesign a protocol to use the other transport method (TACACS and TACACS+ come to mind in this regard). Still, with a few notable exceptions, most applications out there use either TCP or UDP for the transport layer. There should be a readily available document, such as RFC 1700 or its successor, that clearly distinguishes the transport layer in use for the application. There should be a "*" placed by TCP or UDP registration to signify the assigned protocol for use. Placing a "*" next to both, as in the case of DNS, would signify that both TCP and UDP are used. For those apps out there that are not readily identifiable as to their preferred transport layer function, then assign a value of "U" for unknown until somebody can step up to the plate and say one way or another. That would make RFC 1700's successor document truly useful. v/r, Paul Werner ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=17704&t=17704 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
