Question about Obsoleted vs. Historic
Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
I would assume historical reference. On 7/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
On 11-jul-2005, at 8:54, [EMAIL PROTECTED] wrote: This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. ...or BCP: 3152 Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT=5727 bytes) (Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also BCP0049) (Status: BEST CURRENT PRACTICE) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
John, The way I understand it, an RFC is only historic(al) if the technology it defines is no longer in use. An obsolete RFC means the technology is still being used, but some part of the specification (obsolete RFC) has been updated. An obsolete RFC can still be a standard as the RFC that obsoletes it may not change the protocol at all. One example of this is RFC 3912 which is the RFC that obsoletes your example (RFC 954) - read 3192's abstract for more detail. This is of course only my understanding. Best regards, Nick Staff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, July 10, 2005 11:54 PM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: Question about Obsoleted vs. Historic Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
I would point out that it is historically useful to be able to track changes between draft and full or proposed and draft and we don't list status information in the RFCs... Eliot [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Eliot, I would point out that it is historically useful to be able to track changes between draft and full or proposed and draft and we don't list status information in the RFCs... I agree with that. And, my head still hurts thinking about why we'd leave something as a Proposed Standard when its been obsoleted. Seems more like an Obsolete Standard ... but perhaps I am just nit-picking. John Eliot [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Nick, The way I understand it, an RFC is only historic(al) if the technology it defines is no longer in use. Well, as Iljitsch mail pointed out, some things (3152 Delegation of IP6.ARPA) are moved to Historic when the IETF wants people to stop using them ...' An obsolete RFC means the technology is still being used, but some part of the specification (obsolete RFC) has been updated. An obsolete RFC can still be a standard as the RFC that obsoletes it may not change the protocol at all. One example of this is RFC 3912 which is the RFC that obsoletes your example (RFC 954) - read 3192's abstract for more detail. This is of course only my understanding. If only part has been updated, then the RFC doing the update should say 'Updates RFC xyz', I think ... John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Question about Obsoleted vs. Historic
What is the reason for continuing to list something obsolete as a Draft Standard? Ummm, because most people don't notice standards maturity levels? But the idea of an obsolete Best CURRENT Practice makes MY head hurt... Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Question about Obsoleted vs. Historic
On Mon July 11 2005 02:54, [EMAIL PROTECTED] wrote: This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? Lack of action by the IESG. The RFC Editor maintains the rfc-index, and as far as I can tell does a good job of handling the updates/obsoletes/ updated by/obsoleted by information. Moving an RFC from the Standards Track to Historic, however, requires a Standards Action which has to be approved by the IESG per BCP 9, either as part of the review process (section 6.2) which the IESG ignores, or per section 6.4. In practice moving a document to Historic only seems to happen as a result of a rather complicated process where somebody writes yet another RFC suggesting a reclassification of some RFC as Historic, which if approved leads to the Standards Action (see draft-lear-newtrk-decruft-experiment-00.txt). Other cases include full Standards which have been obsoleted, such as STD 10 and STD 11. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: Question about Obsoleted vs. Historic
Sure, but the logic is nevertheless a bit contorted - but rather than debating what the current system *means* could be concentrate on what we should do in future? Incidentally 3596 (a DS) obsoletes 3152 (a BCP). That's unusual, but it isn't illogical. However, 3152 isn't shown as Obsolete in http://www.rfc-editor.org/rfcxx00.html#BCPbyBCP. Brian Eliot Lear wrote: I would point out that it is historically useful to be able to track changes between draft and full or proposed and draft and we don't list status information in the RFCs... Eliot [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf . newtrk resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Sam Hartman wrote: Scott == Scott Bradner [EMAIL PROTECTED] writes: Scott re draft-iesg-discuss-criteria-00.txt Scott I think this is a very helpful document - if followed by Scott the IESG it should reduce the number of what appears to be Scott blocking actions by ADs Scott but I did not see any enforcement mechanism - i.e. if an AD Scott enters a DISCUSS over a section 3.2 reason how does the Scott IESG tell that AD to back off? It seems like the alternate Scott voting process is not needed to have the IESG look at a Scott DISCUSS comments and reach a consensus that it is not (or Scott is) a legit DISCUSS area how about just waiting to see if we have a problem before designing new process? It seems likely that if there is internal conflict within the IESG, the IESG will find a way to resolve that conflict. If you don't feel that you can leave these sorts of details to the IESG, then you shouldn't be trusting the IESG at all. That's a valid position, but it is not resolved by creating enforcement mechanisms. In the end a lot of this comes down to judgement calls, and these guidelines help to set expectations for those calls. If someone sends in a DISCUSS and gets back Really? from a couple of other ADs, the judgement may rapidly swing the other way. I'd say the IESG is trying quite hard these days to clear DISCUSS ballots quickly if possible, and there are quite a few that vanish before or during the telechat. Also, by putting these guidelines into public view, we will hopefully get community feedback on marginal DISCUSSes, since they are visible in the tracker. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Phill, Just picking out the nub of your message: There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. I think the last phrase is unfair - if the IETF is putting a lot of effort into technology Foo, then it's a legitimate question to ask Why aren't you re-using Foo? But we do have as a non-criterion: o Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1. In other words, disagreement in preferences among technically sound approaches. As I read this, it would be legitimate for an AD to ask Did the WG consider Foo, and if so, have good reasons for rejecting it in favour of Bar? and illegitimate to say I like Foo more than Bar, so I'm blocking this. If we agree on this, some wordsmithing may be needed. Brian Hallam-Baker, Phillip wrote: draft-iesg-discuss-criteria-00.txt talks about this. Even within the IESG, we still have one or two points to resolve, but we wanted to get this out before the cutoff date. This isn't in any way intended to change any of the principles of the standards process, but we'd welcome community comment. This is actually quite good. In particular I think that it does go a long way in returning to the original concept of the IETF rather than what it had been turning into. There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. This issue is not unique to the IETF, at one point there was a major issue in W3C when some members suspected that Semantic Web would be imposed in this manner. I believe that a similar dynamic played a major role in causing OSI to become what it became. There are some cases where this is a good idea, it is clearly important that every IETF standard protocol is capable of making the transition to IPv6. But there are other cases where this really comes down to second guessing the WG or worst of all promoting a pet project. For example when I submit a draft proposing a prefix for use with SRV I do not expect to have to explain my reasons for using a technology that is widely supported by existing infrastructure over NAPTR, a technology which is only partially supported, has yet to gain a major constituency of users and may well end up being superceeded before it is widely adopted. Now some might say that the role of the IESG should be precisely to do this sort of thing, to encourage the adoption of technology that deserves to be employed as a technology base. I disagree because this leads working groups to think that its not their job to promote their work product and drive its adoption, they can simply rely on the IESG to do their work for them by forcing other groups who have killer applications to do the heavy lifting for them. I spend a great deal of time working out how to get a protocol adopted, how to build the necessary coalitions of support to drive deployment. If I have a choice of technology platforms I am not going to necessarily pic the one that is the newest, brightest and shinyest. In the first place I have been caught out in the past several times following that route and finding that my spec is the only system built on the new platform. But more importantly the more infrastructure innovations a proposal requires the harder it is to build a coalition and the harder it is to keep it together. The most worrying version of this approach is when a group is told that in order to gain approval of the IESG it MUST take a particular technical approach. This is why I would like a very concrete statement in the DISCUSS document saying that a WG is free to choose an approach that uses deployed technology over another proposal without market traction. I know of two cases where a group has been essentially forced to significantly compromise their design in order to support BEEP. At this point it should be clear to anyone who follows the Web Services area that there is universal agreement amongst vendors and developers that the SOAP stack is the only one that will be used. This outcome has been clear to anyone who has followed this area for at least four years. I watched the SACRED group being bullied into adopting BEEP as a substrate. This makes even less sense when you know that SACRED was intended to be a compliment to XKMS which is defined to be a Web Service running over SOAP. The only argument I saw made at the meeting was that the IESG would expect BEEP to be supported so
RE: Question about Obsoleted vs. Historic
--On Monday, 11 July, 2005 13:12 +0300 [EMAIL PROTECTED] wrote: Eliot, I would point out that it is historically useful to be able to track changes between draft and full or proposed and draft and we don't list status information in the RFCs... I agree with that. And, my head still hurts thinking about why we'd leave something as a Proposed Standard when its been obsoleted. Seems more like an Obsolete Standard ... but perhaps I am just nit-picking. If, as a community, we cared, we could easily have both the tracking information and the status by introducing the little-known term former, as in Obsolete, former Draft Standard. Of course, how many procedural hoops we'd have to jump through to get there is another issue. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
On Mon, Jul 11, 2005 03:42:14PM +0200, Brian E Carpenter allegedly wrote: Phill, Just picking out the nub of your message: There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. I think the last phrase is unfair - if the IETF is putting a lot of effort into technology Foo, then it's a legitimate question to ask Why aren't you re-using Foo? But we do have as a non-criterion: o Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1. In other words, disagreement in preferences among technically sound approaches. As I read this, it would be legitimate for an AD to ask Did the WG consider Foo, and if so, have good reasons for rejecting it in favour of Bar? and illegitimate to say I like Foo more than Bar, so I'm blocking this. If we agree on this, some wordsmithing may be needed. Brian There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
At 9:54 AM +0300 7/11/05, [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? John I've assumed that it was to tell you it was at Draft Standard when the document that replaced it was issued. That way you can tell whether the new doc is a recycle-in-grade, an update to get something to the next step, or a downgrade. The real meat of the data here, though, is that you should look at 3912 if you want the current spec. Any other data about an obsolete spec is for historical interest only. If I'm right, that could be made clearer (by saying Status when active: or some such), but that doesn't really change meat of the information. regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Scott, On Mon, Jul 11, 2005 03:42:14PM +0200, Brian E Carpenter allegedly wrote: Phill, Just picking out the nub of your message: There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. I think the last phrase is unfair - if the IETF is putting a lot of effort into technology Foo, then it's a legitimate question to ask Why aren't you re-using Foo? But we do have as a non-criterion: o Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1. In other words, disagreement in preferences among technically sound approaches. As I read this, it would be legitimate for an AD to ask Did the WG consider Foo, and if so, have good reasons for rejecting it in favour of Bar? and illegitimate to say I like Foo more than Bar, so I'm blocking this. If we agree on this, some wordsmithing may be needed. Brian There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. Limiting the number of deployed solutions should be done based on the operational experience/market forces, and not by ADs/IESG pushing for a particular solution. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Scott W Brim wrote: There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. Sure, but I think some of these things (good, legitimate) are unknowable. In midcom we agreed to reuse an existing protocol, went through the process of identifying objective criteria to evaluate existing protocols against, did the evaluation, and ended up with a protocol that's nearly universally unpopular. It's left us with a midcom standard that's unlikely to be deployed and leaving open the door for a raft of alternative midcom protocols which may be deployed by their inventors but are unlikely to be standardized by the IETF because we've already got a midcom standard. Intentions can be the best and methodology can be rigorous (or a reasonable facsimile thereof) and still produce results that are less-than-useful. My preference would be to put more trust in working groups for this kind of decision, since it's the people working on the stuff who will best understand the tradeoffs between the inefficiencies in creating more protocols to support and the inefficiencies in making protocols do things they were not designed to do. The kind of decision you're talking about is an economic one as much as (or more than) a technical one, and I don't think the IESG is the right place to put the locus of that kind of decision-making even while I do agree they need to guide it. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Question about Obsoleted vs. Historic
No, lack of action by the community to request moving documents to Historic. There seem to be a number of these housekeeping tasks that have almost no benefit to the individual, have increasing costs and ever longer-term commitments and thus, not surprisingly, don't get done on a regular basis. Promotion and demotion of standards are prime examples, reviewing is another. Besides appealing to community spirit, other organizations deal with that by deputizing individuals that get recognized for doing this type of work in general, in one way or the other. This can take the New York's Strongest (Dept. of Sanitation) or the XYZ secretary approach. In many cases, people do unpleasant or boring or no-immediate-reward tasks in hope of getting promoted later - this is why I suggested WG secretaries earlier and maybe why having elected IESG secretaries or the IETF Dept. of Public Works (just leave your old standards at the curb) might be needed. Henning ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
On Mon, Jul 11, 2005 08:21:57AM -0700, Yakov Rekhter allegedly wrote: There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. Limiting the number of deployed solutions should be done based on the operational experience/market forces, and not by ADs/IESG pushing for a particular solution. So you would have blessed IPv8? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Question about Obsoleted vs. Historic
Bruce Lilly wrote: On Mon July 11 2005 02:54, [EMAIL PROTECTED] wrote: This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? Lack of action by the IESG. No, lack of action by the community to request moving documents to Historic. And confusion in the standards process as to whether a new PS or DS truly replaces an old STD, but that's something we've already beaten to death in newtrk. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Yakov, Ultimately the marketplace will decide, but when a WG provides multiple solutions to the same problem it has the potential to confuse the marketplace, retard adoption of any solution, interfere with interoperability, etc. Standards ought to avoid confusion, not contribute to it. Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: When to DISCUSS?
My biggest concern here is not the IESG itself, it's the folk who presume to speak on its behalf. I think it is important to have the statement be explicit and unambiguous. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Monday, July 11, 2005 9:42 AM To: Hallam-Baker, Phillip Cc: IETF Discussion Subject: Re: When to DISCUSS? Phill, Just picking out the nub of your message: There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. I think the last phrase is unfair - if the IETF is putting a lot of effort into technology Foo, then it's a legitimate question to ask Why aren't you re-using Foo? But we do have as a non-criterion: o Disagreement with informed WG decisions that do not exhibit problems outlined in Section 3.1. In other words, disagreement in preferences among technically sound approaches. As I read this, it would be legitimate for an AD to ask Did the WG consider Foo, and if so, have good reasons for rejecting it in favour of Bar? and illegitimate to say I like Foo more than Bar, so I'm blocking this. If we agree on this, some wordsmithing may be needed. Brian Hallam-Baker, Phillip wrote: draft-iesg-discuss-criteria-00.txt talks about this. Even within the IESG, we still have one or two points to resolve, but we wanted to get this out before the cutoff date. This isn't in any way intended to change any of the principles of the standards process, but we'd welcome community comment. This is actually quite good. In particular I think that it does go a long way in returning to the original concept of the IETF rather than what it had been turning into. There is however one area that should be made very explicit as a non issue for DISCUSS, failure to employ a specific technology platform. I have been concerned on a number of occasions where it has appeared that in order to get a specification approved by the IESG it would be necessary to adopt a particular technology being promoted by IESG members. This issue is not unique to the IETF, at one point there was a major issue in W3C when some members suspected that Semantic Web would be imposed in this manner. I believe that a similar dynamic played a major role in causing OSI to become what it became. There are some cases where this is a good idea, it is clearly important that every IETF standard protocol is capable of making the transition to IPv6. But there are other cases where this really comes down to second guessing the WG or worst of all promoting a pet project. For example when I submit a draft proposing a prefix for use with SRV I do not expect to have to explain my reasons for using a technology that is widely supported by existing infrastructure over NAPTR, a technology which is only partially supported, has yet to gain a major constituency of users and may well end up being superceeded before it is widely adopted. Now some might say that the role of the IESG should be precisely to do this sort of thing, to encourage the adoption of technology that deserves to be employed as a technology base. I disagree because this leads working groups to think that its not their job to promote their work product and drive its adoption, they can simply rely on the IESG to do their work for them by forcing other groups who have killer applications to do the heavy lifting for them. I spend a great deal of time working out how to get a protocol adopted, how to build the necessary coalitions of support to drive deployment. If I have a choice of technology platforms I am not going to necessarily pic the one that is the newest, brightest and shinyest. In the first place I have been caught out in the past several times following that route and finding that my spec is the only system built on the new platform. But more importantly the more infrastructure innovations a proposal requires the harder it is to build a coalition and the harder it is to keep it together. The most worrying version of this approach is when a group is told that in order to gain approval of the IESG it MUST take a particular technical approach. This is why I would like a very concrete statement in the DISCUSS document saying that a WG is free to choose an approach that uses deployed technology over another proposal without market traction. I know of two cases where a group has been essentially forced to significantly compromise their
RE: When to DISCUSS?
Scott, If IPv8 meets all of the criteria of an IETF protocol it should be labeled as an IETF protocol. I don't remember the verb blessed being operational in the IETF, perhaps I should reread the RFCs for it. The point is, instead of people peering into the future in a star chamber, one can presume that the world is inhabited by rationale actors and the right outcomes will occur. Let's ask a different question: what is the empirical evidence for There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate.? Is there a demonstrable case/occasion for this point? It seems that maintaining the charter to spec-ing and establishing interoperable Internet protocols should be a guiding principle. Regards, peterf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott W Brim Sent: Monday, July 11, 2005 08:56 To: Yakov Rekhter Cc: IETF Discussion Subject: Re: When to DISCUSS? On Mon, Jul 11, 2005 08:21:57AM -0700, Yakov Rekhter allegedly wrote: There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. Limiting the number of deployed solutions should be done based on the operational experience/market forces, and not by ADs/IESG pushing for a particular solution. So you would have blessed IPv8? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: When to DISCUSS?
From: Scott W Brim [mailto:[EMAIL PROTECTED] There are occasions when limiting the number of deployed solutions is very good for the future of the Internet, and in those cases, pushing for Foo even when Bar is just as good is quite legitimate. I have no argument at all when the IESG suggests a previously deployed approach over an undeployed approach or promotes one deployed approach over another or one undeployed approach over another. What I do have a real problem with is being told that I have to adopt approach which depends on undeployed infrastructure when there is an alternative approach that does not require new infrastructure. It is only common sense to tell people not to reinvent TCP. Telling people that they have to wait for the existing DNS infrastructure to support new record types is not an acceptable demand. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
At 09:54 AM 7/11/2005 +0300, [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? Because Jon Postel always did it that way? Seriously, the idea is that the document was a Draft Standard when it was published. You can obsolete it, but you cannot change its publication status. Should its status change to Historic when it is obsoleted? Maybe, although we have never done it that way (and we do have 20+ years of history). (Note that in fact the RFC Editor added publication status to its index database last year; the new field is included in rfc-index.xml. This shows the status upon publication, in cases where the status is changed later.) There are quite a few twisty little passages lurking here, and they mostly stem from a basic semantic confusion between a document (RFC) number and the protocol that is specified in that document (or maybe not). The RFC number is in fact a document number, but we have chosen to overload it as a protocol designator. We say RFC 793 or TCP more or less interchangeably, but 793 is really only a document. In my view, a result of the ISD proposal in newtrk should be to cleanly remove this semantic overloading of RFC numbers. An ISD would define a protocol independent of a document identifier (RFC number). I believe that we should move with all deliberate speed to engineer an ISD-based system for IETF standards, rather than to make small patches to RFC designations. Bob Braden John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When to DISCUSS?
Brian E Carpenter wrote: In the end a lot of this comes down to judgement calls, and these guidelines help to set expectations for those calls. If someone sends in a DISCUSS and gets back Really? from a couple of other ADs, the judgement may rapidly swing the other way. I'd say the IESG is trying quite hard these days to clear DISCUSS ballots quickly if possible, and there are quite a few that vanish before or during the telechat. Also, by putting these guidelines into public view, we will hopefully get community feedback on marginal DISCUSSes, since they are visible in the tracker. Given that IETF is poorly operated these days, guidelines or interpretations by management entities on the guidelines must be wrong. So, there is no point arguing that the current guidelines and the current interpretations on them are good enough. Either (or both) the guidelines defined by the current process or the management entities chosen through the current process are wrong. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
I'm hesitant to relaunch this thread, but there are a number of points that incite me to comment. Since there's been a fair amount of repetition, may I ask people only to chime in with new thoughts? Paul Hoffman wrote: At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. C. M. Heard wrote: ... RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In what venue will this discussion take place? I think it has to be this list, absent a relevant WG. Joe Touch wrote: ... [re a mandatory section in all drafts] The goal of putting it in the template is to encourage it be addressed, rather than forgotten altogether. However, I'm not at all in favor of requirements to IDs that are added ad-hoc; until this actually makes it into an RFC as a formal requirement, it won't be in the word template I manage. I don't agree that all operational requirements need to be in process RFCs as formal requirements. We need to give the IESG of the day some freedom to adapt requirements to current conditions. I felt that the requirement for IANA Considerations was a fine idea when it was introduced, and certainly nothing that needed to be BCPized. Ned Freed wrote: ... I also predicted that two things would happen: (1) A draft containing IANA considerations and an empty IANA considertions section would be approved and (2) That this section would take on the status of boilerplate in some draft templates. Both predictions have now come to pass. If true, (1) means that a mistake was made by several successive layers of review. (2) is beside the point. But... Bruce Lilly wrote: ... You can make it three: mine says: This memo adds no new IANA considerations. The presence of this template text indicates that the author/editor has not actually reviewed IANA considerations. Yes. Great idea. I updated my own XML template similarly. Ned Freed wrote: ... As I expect you know, the IANA checks all documents at Last Call time, and the RFC Editor checks them before publication, for missing missed IANA actions. However, redundancy does not seem to me to be a bad idea. Of course I know this. But the tendency will be for the text to be believed and for the review to be less thorough. Ditto if it becomes known that the *next* reviewer's check list includes check for overlooked IANA issues: Y/N You're fighting human nature here, and you're gonna lose. Always. The question is, what's the least bad compromise? Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jul 11, 2005, at 11:15 AM, Brian E Carpenter wrote: I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. Personally, I never wonder whether there are any IANA-defined values in a specification. I do wonder from time to time what numbers are appropriate for various uses (gee, this is the IP protocol, and I want to say that the interior header is TCP. How does one say that?), and when I want to get a new number I wonder how to go about getting one. Once it is assigned, I'm afraid I don't much care who assigned it or by what process. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
On 11-jul-2005, at 12:22, [EMAIL PROTECTED] wrote: The way I understand it, an RFC is only historic(al) if the technology it defines is no longer in use. Well, as Iljitsch mail pointed out, some things (3152 Delegation of IP6.ARPA) are moved to Historic when the IETF wants people to stop using them ...' For the record: RFC 3152 basically just says we now use ip6.arpa rather than ip6.int for IPv6 reverse DNS and points to RFC 2874. RFC 2874 wants us to use bit labels for the reverse DNS (which is very cool but unfortunately isn't backward compatible and requires not just a new resource record but a partial rewrite of the software used in pretty much all DNS servers). RFC 2874 is experimental but that's just pretense, as there aren't currently, nor have there ever been any bitlabel delegations under ip6.arpa, as far as my research has been able to uncover. (RFC 1886 specified the nibble format with ip6.int, which looks like d.e.a.d.b.e.a.f.1.0.0.2.ip6.int.) So RFC 3152 was never practice, the alleged practice isn't current, and I'll refrain from commenting on best. RFC 3596 (draft standard) finally cleans the whole mess up for the most part by saying in so many words that people should use the nibble method with ip6.arpa for the IPv6 reverse DNS, but unfortunately it claims that RFC 3152 was mainly about s/ip6.int/ ip6.arpa/g, ignoring the whole bitlabel/nibble thing. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Ietf Digest, Vol 15, Issue 19
Now the initial internet-draft deadline has passed I want to respond to the main points of this message. I don't believe that a point-by- point rebuttal is useful, due to the length of the message and repetition of arguments. Comments follow inline. On 6 Jul 2005, at 18:01, Bruce Lilly wrote: Date: 2005-07-06 04:06 From: Stephen Casner [EMAIL PROTECTED] Stephen, you wrote: That's not it. Of course all the existing registrations would be copied. However, all of the many RTP-related RFCs that refer to MIME registrations would become obsolete and need to be revised. A fair number of those RFCs are referenced by other SDO's documents. Are any of those RFCs on the Standards Track? Are they all at full Standard? Those which are Standards Track but not yet full Standard need to be followed up on to advance on the Standards Track, and that would be a good time to do a global replace of MIME with RTP and add an IANA considerations section directing IANA to mark the type in the MIME registry as obsolete. Should take about 30 seconds to do that. The MIME registrations will never go away (unfortunately for MIME), so if a particular implementer goes ferreting through the MIME registrations because he has an old copy of a document that says MIME, he'll still find the type. Some of the motivations for moving the RTP namespace into the MIME namespace were: - To avoid different names for the same media format, such as MIME's audio/basic and RTP's PCMU. More on this below. To date, I know of no same media format for MIME and RTP; Magnus specifically mentioned audio/amr, which has different formats, and alluded to a tiny number of others but was not specific. The simplest is audio/L16. For historical reasons, audio/basic and audio/pcmu are identical but have different names: eliminating duplicate names for such formats was one of the initial reasons for using the MIME namespace for RTP. The audio/amr format contains identical media data, but the RTP transport is defined to strip the initial magic number, which is redundant with fields in the RTP protocol headers. The wide band version of AMR, and the related EVRC formats are similar. ... The AVT working group did a lot of work between then and now to specify the mechanism for the registrations and to create registrations with what I believe was careful attention to detail. This process has imposed very little load on the MIME folks; in fact, it has received little notice until the recent consideration of two subtypes under the text major type. That is because of the way MIME works and has always worked; the text type is for media containing human-readable (w/o software) text. The fallback is to text/plain, which is what the Internet Message Format carries in the absence of MIME. There are relatively few interoperability considerations for audio and video media subtypes, so the attitude is largely ho hum, another subtype; who cares. Not for text. More below. ... There is no proposal to change the way email, html, and fax use MIME types. On the contrary, any registration of a format which requires software for interpretation, contains binary content, etc. under the MIME text type would require massive backwards compatibiliy- and interoperability- breaking changes. Given the mission-critical use of the affected applications (e.g. IETF business such as this and other mailing lists) that is simply unacceptable. The thrust of most of the rest of this message seems to be that the use of MIME type to identify RTP audio and video formats is uncontroversial, but you have a serious concern over use of text formats with RTP, since you believe these will disrupt MIME operations due to leakage. This concern difficult to justify for several reasons: 1) These types have been in widespread use for several years now; there have been no reports of actual operational problems, opposed to the theoretical arguments being made here. 2) As has been mentioned previously, the text/t140 format, which started this discussion, does comply with the MIME registration rules for the text media type. The format is plain UTF-8 text with implicit timing data, there are no embedded control characters, the CRLF sequence is only used to identify line breaks, and a language tag is available. The claimed massive backwards compatibility- and interoperability- breaking changes you suggest would occur have not been needed in the five years since this format was registered; or as a result of the 8 years worth of deployment of other RTP formats signalled using a range of MIME media types within SDP. ... The simple rule -- necessary to ensure interoperability -- is MIME registry, MIME rules. If the RTP specification writers were to conform to the MIME rules -- which are in plain view in RFCs 2046 2049 -- there wouldn't be an issue; mind you, the types might be of little interest outside or
Re: Question about Obsoleted vs. Historic
On Monday, July 11, 2005 09:54:14 AM +0300 [EMAIL PROTECTED] wrote: Hi, I was wondering if someone could help me out on this one. I was doing a bit of analysis on the current RFC list, and noticed that some Draft Standard documents are obsoleted. For example: 954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler. Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted by RFC3912) (Status: DRAFT STANDARD) This really made me scratch my head. One would imagine if a protocol is obsoleted by another, it would not be listed as a Draft Standard any longer. What is the reason for continuing to list something obsolete as a Draft Standard? I think there is a bit of confusion here. Obsoleted by RFC does _not_ mean that the technology or protocol described in the present document is obsolete. It does not even mean that the specification contained in the document is obsolete. What it means is that RFC contains a newer version of the same specification, which stands on its own. By contrast, Updated by RFC means that RFC extends or updates the specificiation, possibly even resulting in a new version, but also requires reading the present document -- it does not stand on its own. Described another way, if one document updates another, it is the moral equivalent of a patch. If a document obsoletes another, then it is like a complete copy of the new file (and often is exactly that). These notations are intended to help find older and newer versions of a specification, extensions, base documents, etc. They are entirely about document history, and are orthogonal to the progression of a specification through the standards process. For example, it is entirely reasonable and even common to have RFC obsoletes RFC, where RFC is at Proposed and RFC is at Draft or is even a full standard. Now in the particular case at hand, it is entirely possible and even likely that the intent is for RFC3912 (also at Draft) to eventually progress to full standard in the place of RFC954. It can be reasonably argued that in such a case, the publication status of RFC954 should be changed, and even that it should have been changed by RFC3912. It's just (apparently) not what has always been done. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
At 8:15 PM +0200 7/11/05, Brian E Carpenter wrote: Paul Hoffman wrote: At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. But neither does a section that says there are no new values registered. The presence of a null section only says this document didn't cause any new registrations by its publication. A section that says here are the IANA registries that are relevant to this document would be useful to that implementer. We have never tried that, and I suspect it would take a lot of energy and thinking to do so. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Hi John K, I would point out that it is historically useful to be able to track changes between draft and full or proposed and draft and we don't list status information in the RFCs... I agree with that. And, my head still hurts thinking about why we'd leave something as a Proposed Standard when its been obsoleted. Seems more like an Obsolete Standard ... but perhaps I am just nit-picking. If, as a community, we cared, we could easily have both the tracking information and the status by introducing the little-known term former, as in Obsolete, former Draft Standard. Of course, how many procedural hoops we'd have to jump through to get there is another issue. That seems like the most reasonable approach, to me - putting the 'former' tag, not having to jump through procedural hoops ... John L. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 2434 term IESG approval
On Fri, 8 Jul 2005, Robert Elz wrote: The relevant part is from section 2, basicly all of page 5 of the doc. ... Everything between is about documentation requirements, just read them ... ... New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials ... This does not say that the _only_ criterion that can be used by the IESG as a condition for approval of the assignment is that there be adequate documentation. Nor, in my opinion, does anything in the rest of the document imply that. ps: I believe this is my last word on this topic. Mine too. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [newtrk] Question about Obsoleted vs. Historic
Henning, No, lack of action by the community to request moving documents to Historic. There seem to be a number of these housekeeping tasks that have almost no benefit to the individual, have increasing costs and ever longer-term commitments and thus, not surprisingly, don't get done on a regular basis. Promotion and demotion of standards are prime examples, reviewing is another. Besides appealing to community spirit, other organizations deal with that by deputizing individuals that get recognized for doing this type of work in general, in one way or the other. This can take the New York's Strongest (Dept. of Sanitation) or the XYZ secretary approach. In many cases, people do unpleasant or boring or no-immediate-reward tasks in hope of getting promoted later - this is why I suggested WG secretaries earlier and maybe why having elected IESG secretaries or the IETF Dept. of Public Works (just leave your old standards at the curb) might be needed. Have you seen draft-ietf-newtrk-cruft-00? It proposes something along these lines. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Ted, I've assumed that it was to tell you it was at Draft Standard when the document that replaced it was issued. That way you can tell whether the new doc is a recycle-in-grade, an update to get something to the next step, or a downgrade. The real meat of the data here, though, is that you should look at 3912 if you want the current spec. Any other data about an obsolete spec is for historical interest only. If I'm right, that could be made clearer (by saying Status when active: or some such), but that doesn't really change meat of the information. I'd strongly suggest some tag to indicate that its no longer active. In many cases, a Standard is marked Obsolete because it has been updated for some reason; often times because of some critical bug or other issues. I don't think the IETF wants to recommend an obsolete standard as something folks should go and implement. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [newtrk] Question about Obsoleted vs. Historic
Brian, What is the reason for continuing to list something obsolete as a Draft Standard? Lack of action by the IESG. No, lack of action by the community to request moving documents to Historic. Section 6.2 of 2026 does say the following: When a standards-track specification has not reached the Internet Standard level but has remained at the same maturity level for twenty-four (24) months, and every twelve (12) months thereafter until the status is changed, the IESG shall review the viability of the standardization effort responsible for that specification and the usefulness of the technology. Following each such review, the IESG shall approve termination or continuation of the development effort, at the same time the IESG shall decide to maintain the specification at the same maturity level or to move it to Historic status. My guess is that anything marked as obsolete will be stuck at its current maturity level in perpetuity, making it a good candidate to go to Historic. 2026 seems to state that the IESG will handle this. However, Eliot's Crust removal draft could come to play here. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Bob, A question for you: What is the reason for continuing to list something obsolete as a Draft Standard? Because Jon Postel always did it that way? Seriously, the idea is that the document was a Draft Standard when it was published. You can obsolete it, but you cannot change its publication status. Should its status change to Historic when it is obsoleted? Maybe, although we have never done it that way (and we do have 20+ years of history). First off, 2026 says: 4.2.4 Historic A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the Historic level. So, it would appear, to me, that anything that has been obsoleted is, in fact, Historic. But perhaps I am nit-picking. My question is - what do we mean by an Obsoleted Proposed Standard? Does this have any relevance? What I am still confused about is that, for a particular technology, what does the IETF 'recommend' or would want to see implemented for a particular standard? Obviously, Historic carries the connotation that the IETF doesn't suggest to be implemented. Does the IETF think that Standards that have been Obsoleted SHOULD be implemented or SHOULD NOT be implemented? If I wanted to do something and had 2 protocols to choose from, one that was Proposed Standard and one that was Obsolete but Full Standard, which one would the IETF like that I implement? Perhaps I am asking to much from the RFC Index (http://www.ietf.org/iesg/1rfc_index.txt) but one would think that we could provide a meaningful way to convey what we think of our own technology? (Note that in fact the RFC Editor added publication status to its index database last year; the new field is included in rfc-index.xml. This shows the status upon publication, in cases where the status is changed later.) There are quite a few twisty little passages lurking here, and they mostly stem from a basic semantic confusion between a document (RFC) number and the protocol that is specified in that document (or maybe not). The RFC number is in fact a document number, but we have chosen to overload it as a protocol designator. We say RFC 793 or TCP more or less interchangeably, but 793 is really only a document. In my view, a result of the ISD proposal in newtrk should be to cleanly remove this semantic overloading of RFC numbers. An ISD would define a protocol independent of a document identifier (RFC number). I believe that we should move with all deliberate speed to engineer an ISD-based system for IETF standards, rather than to make small patches to RFC designations. Well, you can guess my position on this as well. thanks, John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'PWE3 Control Word for use over an MPLS PSN' to Proposed Standard
The IESG has received a request from the Pseudo Wire Emulation Edge to Edge WG to consider the following document: - 'PWE3 Control Word for use over an MPLS PSN ' draft-ietf-pwe3-cw-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cw-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Quota and Size Properties for DAV Collections' to Proposed Standard
The IESG has received a request from the WWW Distributed Authoring and Versioning WG to consider the following document: - 'Quota and Size Properties for DAV Collections ' draft-ietf-webdav-quota-07.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-07.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Message Submission BURL Extension' to Proposed Standard
The IESG has received a request from the Enhancements to Internet email to support diverse service environments WG to consider the following document: - 'Message Submission BURL Extension ' draft-ietf-lemonade-burl-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-lemonade-burl-01.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Internet Message Access Protocol (IMAP) CATENATE Extension' to Proposed Standard
The IESG has received a request from the Enhancements to Internet email to support diverse service environments WG to consider the following document: - 'Internet Message Access Protocol (IMAP) CATENATE Extension ' draft-ietf-lemonade-catenate-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-07-25. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-lemonade-catenate-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
