Re: Discuss criteria for documents that advance on the standards track
--On Tuesday, August 30, 2011 14:51 -0700 Fred Baker f...@cisco.com wrote: What's also not fair game is to raise the bar - to expect the document at DS to meet more stringent criteria than it was required to meet at the time of PS approval. Hmmm, the demonstrated interoperability requirement of DS/IS is in fact a raising of the bar,and one that has served us well. We don't (although IMHO we should) require even an implementation to go to PS. I know it is controversial, but there is at least one other area in which we should be raising the bar for DS/IS by dropping the bar for Proposed. If we really want to get PS specs out quickly while the percentage of people who easily write very high quality technical English in the IETF continues to go down, we need to stop the behavior of various IESG members simulating technical editors or translators to fix PS text (or insisting that the author or WG do so, which, IMO, is less bad but still often a problem). Doing that will get documents out faster, perhaps even a lot faster in some cases, but will inevitably result in PS documents that need significant editorial work before being approved at DS. I think that would actually be a good thing. I think that stuffing explicit placeholders to the effect of this needs to be rewritten to be completely clear to folks who haven't participated in the WG into PS documents would be a fine idea -- it would get those documents finished and out while making their preliminary nature very clear. But it implies a higher editorial quality standard --a higher bar-- for DS/IS than for PS. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Keith, thank you for the feedback. Some responses inline: 1. Fix the broken IESG voting system before you try to establish more decision criteria. I do agree with your general thinking here. The way that you describe the different positions is what I personally try to achieve in my IESG reviews. But I think you are overemphasizing the role of the vote designations. Again, I try to do this already, though maybe not always succeeding. In general, if the Area Directors are not doing their job of stopping bad stuff and moving good stuff along, they don't need a new voting system, they need to grow a spine. Elaborating a bit more about this: We have plenty of cases where a DISCUSS has been left standing, and today that acts as your NO vote. (Obviously, in many cases this was an error, or lack of effort. I'm quilty of this for sure, even right now I have a queue of DISCUSSes and their proposed resolutions that I need to go check.) But I think a DISCUSS should stand, if there is a serious issue and it is not rectified. There are corner cases where a single AD has an opinion that is not shared by the rest of the community. For those cases we have an override procedure. This has been never been invoked, but that's probably because it gets pretty ugly way before that -- there are often heated discussions between ADs about discusses. We have the ABSTAIN vote, which some ADs use to vote NO, often together with other ADs who feel the same. There's never been a case where this would have blocked a document from proceeding, as we've never collected the necessary 1/3 number of ADs to vote ABSTAIN for any single document. My conclusion is that ABSTAIN stands for NO-OBJECTION in practical terms. I don't recommend its use... 2. Don't overconstrain the use of DISCUSS. In particular, don't ever create a situation where a reviewer can't cite a problem with a document, regardless of whether that problem has previously been enumerated. I agree, and that's why the guidelines I posted are just that -- guidelines. They are not binding rules, they leave room for a judgment call. 3. I take serious issue with the statement in the draft that IESG reviews are reviews of last resort and the implication that WG reviews are sufficient. In numerous situations this has not been the case. Of course. But I don't see a conflict between a review of last resort and having the last resort find issues. I wish we'd find less issues, but at least I still view the IESG as the final check, that should catch issues if others have not. Its not a last resort in the sense that it would not be invoked; we do review all documents very carefully. Its a last resort only in the sense that there is an expectation that previous stages should have produced a quality result without issues. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Would having professional editors make a difference here? On Aug 31, 2011, at 2:31 AM, John C Klensin wrote: --On Tuesday, August 30, 2011 14:51 -0700 Fred Baker f...@cisco.com wrote: What's also not fair game is to raise the bar - to expect the document at DS to meet more stringent criteria than it was required to meet at the time of PS approval. Hmmm, the demonstrated interoperability requirement of DS/IS is in fact a raising of the bar,and one that has served us well. We don't (although IMHO we should) require even an implementation to go to PS. I know it is controversial, but there is at least one other area in which we should be raising the bar for DS/IS by dropping the bar for Proposed. If we really want to get PS specs out quickly while the percentage of people who easily write very high quality technical English in the IETF continues to go down, we need to stop the behavior of various IESG members simulating technical editors or translators to fix PS text (or insisting that the author or WG do so, which, IMO, is less bad but still often a problem). Doing that will get documents out faster, perhaps even a lot faster in some cases, but will inevitably result in PS documents that need significant editorial work before being approved at DS. I think that would actually be a good thing. I think that stuffing explicit placeholders to the effect of this needs to be rewritten to be completely clear to folks who haven't participated in the WG into PS documents would be a fine idea -- it would get those documents finished and out while making their preliminary nature very clear. But it implies a higher editorial quality standard --a higher bar-- for DS/IS than for PS. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
My interpretation of what you wrote is that in your mind there is absolutely no difference between a SHOULD and a MAY. They are both optional, and you implement whatever you have time to implement, with SHOULD's prioritized higher than MAY's. Even if that is not what you mean, it is what many implementors do. I would offer this highlights the problem with today's SHOULD. Some think SHOULD means something is OK to implement, but life does not end if you do not do it. Others think SHOULD means something HAS to be implemented, unless the environment indicates the protocol will not work in some corner case. On Aug 30, 2011, at 3:08 PM, hector wrote: When I approach a protocol to implement, the first thing I typically do is extract and develop the basic wiring of the protocol, the minimum requirements. Make sure the basic framework is correct 100%, then I look for the SHOULDs and also MAYS which are the easiest to add. I look at the SHOULD by order of importance and also complexity. How much CANDY is it? It is a security feature? What are the other implementation requirements, tools, APIs, etc. Generally I want to get security out the way. Its like SMTP AUTH - its not required but anyone cleaning up and rewriting an SMTP spec today, might include the AUTH extension as a SHOULD. And implementators are keen to the importance of it. But nothing won't break down if you don't, less functionality but the basic structure is still there. Its the same approach used for all the protocols we support. Start with the basics and then add on as necessary. Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Interesting example. I like it. I agree that when to retry is not at all a protocol issue. That probably is why we are in fuzzy land, and this highlights why SHOULD is bad. The availability of SHOULD drew the author of the mentioned RFC to mix a user interface / user experience issue with a protocol issue. Saying a client SHOULD retry immediately, to migrate subscriptions, is an implementation detail and has absolutely NOTHING to do with the protocol. It would be OK to have a NOTE in the protocol RFC discussing that deactivated is an opportunity to migrate the subscription. It would be OK to have an Informational implementor's guide that notes that it would be good for clients to leverage the deactivated state to quickly migrate a subscription. However, there is NOTHING in the protocol to say SHOULD. On Aug 30, 2011, at 3:15 PM, Adam Roach wrote: In this case, unless the implementation has a good reason, failing to re-subscribe will result in behavior that the user perceives as broken. I don't think that's really MAY territory. /a On 8/30/11 1:57 PM, Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
On 2011-08-31 06:05, Mykyta Yevstifeyev wrote: ... Well, a reasonable argument. At Appendix A of draft-rfc-editor-errata-process-02 (http://tools.ietf.org/html/draft-rfc-editor-errata-process-02#appendix-A) I found a proposal from Brian Carpenter to point to errata list in the RFC itself, probably in Status of this Memo section. So this may be a solution. ... Status of this Memo already has a link to http://www.rfc-editor.org/info/rfc. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
31.08.2011 8:09, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mykyta Yevstifeyev Sent: Tuesday, August 30, 2011 9:05 PM To: ietf@ietf.org Subject: Re: Limitations in RFC Errata mechanism I think given the current mechanism I would just submit such things under Editorial. This is an option; but doing so makes work of RFC Editor when incorporating metadata errata harder. If we have such thing as Metadata erratum type, and if such erratum gets verified, RFC Editor will be capable of noticing and acting quickly (I doubt RFC Editor pays much attention to Editorial errata when submitted/verified). I'm sure the RFC Editor appreciates people in the IETF trying to make their work easier, but since so far they haven't complained about this in particular, I'm not sure it's something that actually needs fixing. Usually, when metadata erratum is reported, and some AD verifies it, this AD is to report this change to RFC Editor manually, despite the fact the verification notification is cc'ed to rfc-edi...@rfc-editor.org; also note that processing such errata may take additional time because the whole IESG may be necessary to be consulted, and so on. At least one step of this process may be simplified simply. I was able to type Appendix A just now into that section without difficulty. The preview page shows Section Appendix A says:, but that hardly seems a difficulty. This limitation makes submitters find the way to put what they want in this field whose entity, I think, should be limited to digits and .. This issue is probably of aesthetic importance. As a submitter, I didn't find typing Appendix A into that box and decoding the output to be at all inconvenient. It may not be perfect, but it's not terribly broken either. So this, as already mentioned, is an aesthetic question. However, Section TOC or Section Appendix A don't look nice. Typically a working group discusses an erratum when it is raised, and then it sits in limbo until a document update occurs. Isn't the right place for discussion about a particular one the mailing list of that working group or, if it's disbanded, the main IETF list? Well, there are AD-sponsored Individual Submissions, which have no associated WG, and IAB, IRTF and Independent docs which IETF community might have a limited interest in. If we had the lists where errata for: [...] I still don't see this as evidence that we need to have a forum specifically for discussing errata. I would have to subscribe to that list just in case there's ever any erratum opened for an RFC that interests me, and deal with the (possibly huge) amount of traffic that is not of interest. It seems to me that ietf@ietf.org is just fine for this purpose, and most of us already are on that one. I didn't see, for instance, any errata report against apps-related RFCs coming to apps-discuss list. This would only happen if such RFC was produced is appsawg WG. I didn't notice errata reports on genarea RFCs coming on IETF Discussion list, which would be logical. There may be more examples. Else, errata system should be configured to copy all notifications to specific area lists, which exists in all areas, which it currently isn't. I also haven't seen any demand prior to this for a special forum where errata are discussed, separate from the list(s) we already have. Discussing errata on IETF Discussion list will increase our traffic and will soon bore many people who aren't particularly interested in a variety of topics errata are submitted on. As far as I can tell, that's where this happens now, and I don't see it being much of a burden. Have we ever seen any errata coming on IETF Discussion? Mykyta Yevstifeyev I could be wrong, but I don't see much evidence that any of this stuff is broken enough to warrant a bunch of form changes, new mailing lists, or other new infrastructure. If it ain't broke, don't fix it. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Limitations in RFC Errata mechanism
31.08.2011 10:42, Julian Reschke wrote: On 2011-08-31 06:05, Mykyta Yevstifeyev wrote: ... Well, a reasonable argument. At Appendix A of draft-rfc-editor-errata-process-02 (http://tools.ietf.org/html/draft-rfc-editor-errata-process-02#appendix-A) I found a proposal from Brian Carpenter to point to errata list in the RFC itself, probably in Status of this Memo section. So this may be a solution. ... Status of this Memo already has a link to http://www.rfc-editor.org/info/rfc. Yes, this slipped my mind. Thanks. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Eric, John, Would having professional editors make a difference here? I know it is controversial, but there is at least one other area in which we should be raising the bar for DS/IS by dropping the bar for Proposed. If we really want to get PS specs out quickly while the percentage of people who easily write very high quality technical English in the IETF continues to go down, we need to stop the behavior of various IESG members simulating technical editors or translators to fix PS text (or insisting that the author or WG do so, which, IMO, is less bad but still often a problem). I think the existing Discuss criteria already says very clearly that editorial comments cannot be blocking DISCUSSes. I see a lot of language feedback from IESG and directorate reviews, but its rare to have them appear in the DISCUSSes. If they do, its inappropriate, you should push back. And I'm sure you will :-) Besides, we pay the RFC Editor a large amount of money every year to do the editing. Documents need to be clear enough to be understood, but the RFC editor can handle most of the editorial problems. (That being said, I've seen documents that were sent back because they really were not understandable. Obviously there is some bar under which you should not go, or the document cannot advance at all. This happens more in WG stages than in the IESG. But if you can't communicate your idea clearly then I think it should be up to you to hire co-workers/editors to help clarify your idea... not the IETF's problem, IMHO.) Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Exactly. I'm working my way through RFC2616bis, trying to distinguish between SHOULDs that actually have implications for interoperability and SHOULDs that are just there because the english word 'should' happened to make sense at the time. It's a huge pain. On 31/08/2011, at 5:42 PM, Eric Burger wrote: Interesting example. I like it. I agree that when to retry is not at all a protocol issue. That probably is why we are in fuzzy land, and this highlights why SHOULD is bad. The availability of SHOULD drew the author of the mentioned RFC to mix a user interface / user experience issue with a protocol issue. Saying a client SHOULD retry immediately, to migrate subscriptions, is an implementation detail and has absolutely NOTHING to do with the protocol. It would be OK to have a NOTE in the protocol RFC discussing that deactivated is an opportunity to migrate the subscription. It would be OK to have an Informational implementor's guide that notes that it would be good for clients to leverage the deactivated state to quickly migrate a subscription. However, there is NOTHING in the protocol to say SHOULD. On Aug 30, 2011, at 3:15 PM, Adam Roach wrote: In this case, unless the implementation has a good reason, failing to re-subscribe will result in behavior that the user perceives as broken. I don't think that's really MAY territory. /a On 8/30/11 1:57 PM, Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On Aug 31, 2011, at 2:31 AM, John C Klensin wrote: --On Tuesday, August 30, 2011 14:51 -0700 Fred Baker f...@cisco.com wrote: What's also not fair game is to raise the bar - to expect the document at DS to meet more stringent criteria than it was required to meet at the time of PS approval. Hmmm, the demonstrated interoperability requirement of DS/IS is in fact a raising of the bar,and one that has served us well. We don't (although IMHO we should) require even an implementation to go to PS. I know it is controversial, but there is at least one other area in which we should be raising the bar for DS/IS by dropping the bar for Proposed. If we really want to get PS specs out quickly while the percentage of people who easily write very high quality technical English in the IETF continues to go down, we need to stop the behavior of various IESG members simulating technical editors or translators to fix PS text (or insisting that the author or WG do so, which, IMO, is less bad but still often a problem). Doing that will get documents out faster, perhaps even a lot faster in some cases, but will inevitably result in PS documents that need significant editorial work before being approved at DS. Given that people commonly implement and deploy Proposed Standards in products, sometimes even prior to their approval as Proposed Standards, I think this is a very bad idea. I think it's likely to create interoperability problems between PS and DS versions of products, and sometimes between implementations of the same PS version. For better or worse, the widespread desire to implement at PS (recommendations in 2026 notwithstanding) pretty much forces IETF to try to produce high quality prose at PS. I agree that IESG should not generally be acting as technical editors, so maybe IETF needs to find some way to provide technical editors who are proficient in technical English before documents are reviewed by IESG. Documents written by native English speakers would also benefit. Maybe the GEN-ART review could be expanded, or maybe the RFC Editor could assume some role here (awkward though that might be at first). Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On Aug 31, 2011, at 2:36 AM, Jari Arkko wrote: Keith, thank you for the feedback. Some responses inline: 1. Fix the broken IESG voting system before you try to establish more decision criteria. I do agree with your general thinking here. The way that you describe the different positions is what I personally try to achieve in my IESG reviews. But I think you are overemphasizing the role of the vote designations. Again, I try to do this already, though maybe not always succeeding. In general, if the Area Directors are not doing their job of stopping bad stuff and moving good stuff along, they don't need a new voting system, they need to grow a spine. Elaborating a bit more about this: We have plenty of cases where a DISCUSS has been left standing, and today that acts as your NO vote. (Obviously, in many cases this was an error, or lack of effort. I'm quilty of this for sure, even right now I have a queue of DISCUSSes and their proposed resolutions that I need to go check.) But I think a DISCUSS should stand, if there is a serious issue and it is not rectified. There are corner cases where a single AD has an opinion that is not shared by the rest of the community. For those cases we have an override procedure. This has been never been invoked, but that's probably because it gets pretty ugly way before that -- there are often heated discussions between ADs about discusses. We have the ABSTAIN vote, which some ADs use to vote NO, often together with other ADs who feel the same. There's never been a case where this would have blocked a document from proceeding, as we've never collected the necessary 1/3 number of ADs to vote ABSTAIN for any single document. My conclusion is that ABSTAIN stands for NO-OBJECTION in practical terms. I don't recommend its use... The biggest problem with the current voting system (other than misleading labels, which do cause real problems of their own) is the presumption that the document should go forward no matter how few IESG members read the document. So No Objection votes from ADs who didn't read the document count as Yes votes, but there's also a presumption in the rules (as well as pressure from other ADs who want to get documents off the agenda) to clear Discuss votes in favor of moving a document forward whether or not the identified issues have been adequately addressed. (One thing that I didn't mention that also needs to be fixed if it's still the case is the presumption that the responsible AD votes Yes for the document. I don't know what the tools do now, but this Yes vote used to be automatically filled-in.) 2. Don't overconstrain the use of DISCUSS. In particular, don't ever create a situation where a reviewer can't cite a problem with a document, regardless of whether that problem has previously been enumerated. I agree, and that's why the guidelines I posted are just that -- guidelines. They are not binding rules, they leave room for a judgment call. 3. I take serious issue with the statement in the draft that IESG reviews are reviews of last resort and the implication that WG reviews are sufficient. In numerous situations this has not been the case. Of course. But I don't see a conflict between a review of last resort and having the last resort find issues. I wish we'd find less issues, but at least I still view the IESG as the final check, that should catch issues if others have not. Its not a last resort in the sense that it would not be invoked; we do review all documents very carefully. Its a last resort only in the sense that there is an expectation that previous stages should have produced a quality result without issues. That is not a valid expectation, in either theory or practice. That's my point. Arguably when a poor quality document gets to IESG, it's a failure on the part of the WG to do due diligence. But the problem is actually deeper than that - it's partially structural (in that IETF partitions almost all work into narrowly focused WGs who don't represent a sufficiently broad spectrum of interests), and partially due to a failure to consistently apply good engineering principles across all of IETF. IESG's assuming that the WG has produced a quality result basically works to mask the other problems with IETF's way of doing work. But even if WGs generally did produce high quality results without issues (which I don't think is the case now), IESG review should still not presume that they do. There will always be some failures at the WG level, and the IESG's job is to try to catch those. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On Aug 31, 2011, at 4:34 AM, Jari Arkko wrote: Eric, John, Would having professional editors make a difference here? I know it is controversial, but there is at least one other area in which we should be raising the bar for DS/IS by dropping the bar for Proposed. If we really want to get PS specs out quickly while the percentage of people who easily write very high quality technical English in the IETF continues to go down, we need to stop the behavior of various IESG members simulating technical editors or translators to fix PS text (or insisting that the author or WG do so, which, IMO, is less bad but still often a problem). I think the existing Discuss criteria already says very clearly that editorial comments cannot be blocking DISCUSSes. So nobody has the job of making sure that the documents are well-written in clear English? Besides, we pay the RFC Editor a large amount of money every year to do the editing. Documents need to be clear enough to be understood, but the RFC editor can handle most of the editorial problems. If the document is edited for clarity after final review, that's really a botch in the process. It means that the review doesn't apply to the version of the document being published. Of course the RFC Editor's resources shouldn't be used for documents that aren't otherwise deemed worthy of publication, and you'd like to avoid the RFC Editor having to do multiple reviews, so I admit that this is tricky to solve. (That being said, I've seen documents that were sent back because they really were not understandable. Obviously there is some bar under which you should not go, or the document cannot advance at all. This happens more in WG stages than in the IESG. But if you can't communicate your idea clearly then I think it should be up to you to hire co-workers/editors to help clarify your idea... not the IETF's problem, IMHO.) If writing clear specifications isn't the IETF's problem, I'm not sure what is. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Yes, but there is another factor that appears to be presumed in the discussions that might will help explains the critical difference: Even if SHOULD is interpreted as a MUST IMPLEMENT, there is no MUST USE guarantee by protocol consumers. An implementator might decide a particular SHOULD has an absolute no consumer value, it might even be harmful, and it might be a low adoption currently, that might be enough to ignore it. On the hand, if he says Oh, lets add it anyway, he must still present it as OPTION to the consumer for them to decide. In my view, SHOULD are user protocol options to set. Odds are good a SHOULD would be enabled out of the box. Some might be disabled out of the box. If its not an user option, then that means it must be enabled with no way to turn off. If so, then logic tells me that this SHOULD should of been a MUST to be begin right. No? -- HLS Eric Burger wrote: My interpretation of what you wrote is that in your mind there is absolutely no difference between a SHOULD and a MAY. They are both optional, and you implement whatever you have time to implement, with SHOULD's prioritized higher than MAY's. Even if that is not what you mean, it is what many implementors do. I would offer this highlights the problem with today's SHOULD. Some think SHOULD means something is OK to implement, but life does not end if you do not do it. Others think SHOULD means something HAS to be implemented, unless the environment indicates the protocol will not work in some corner case. On Aug 30, 2011, at 3:08 PM, hector wrote: When I approach a protocol to implement, the first thing I typically do is extract and develop the basic wiring of the protocol, the minimum requirements. Make sure the basic framework is correct 100%, then I look for the SHOULDs and also MAYS which are the easiest to add. I look at the SHOULD by order of importance and also complexity. How much CANDY is it? It is a security feature? What are the other implementation requirements, tools, APIs, etc. Generally I want to get security out the way. Its like SMTP AUTH - its not required but anyone cleaning up and rewriting an SMTP spec today, might include the AUTH extension as a SHOULD. And implementators are keen to the importance of it. But nothing won't break down if you don't, less functionality but the basic structure is still there. Its the same approach used for all the protocols we support. Start with the basics and then add on as necessary. Eric Burger wrote: What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: On 8/29/11 9:44 PM, Eric Burger wrote: Yes, and... I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: SHOULD send a 1 UNLESS you receive a 0 really means UNLESS you receive a 0, one MUST send a 1. My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: SHOULD send a 1 UNLESS you are in a walled garden SHOULD flip bit 27 UNLESS you have a disk SHOULD NOT explode UNLESS you are a bomb are all reasonable SHOULD-level statements. I would offer that ANY construction of SHOULD without an UNLESS is a MAY. Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. Let's examine this use of SHOULD. If the subscriber doesn't re-subscribe, is it an interop issue? No. Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. Does SHOULD get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. But don't ban the tool. /a
Re: 2119bis
On Aug 31, 2011, at 8:30 AM, Hector wrote: In my view, SHOULD are user protocol options to set. In my view, SHOULD should rarely be used for optional protocol features, because optional protocol features should themselves be rare. And the primary purpose of SHOULD is not to permit optional protocol features. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Keith Moore wrote: On Aug 31, 2011, at 8:30 AM, Hector wrote: In my view, SHOULD are user protocol options to set. In my view, SHOULD should rarely be used for optional protocol features, because optional protocol features should themselves be rare. And the primary purpose of SHOULD is not to permit optional protocol features. If SHOULD is read as a MUST IMPLEMENT, and that also implies MUST USE with no provision to disable then its should of been a MUST in the first place. When presented to consumers, we do this for the most part: o MUST items No options, to way to turn off. No GUI, Nada. Under rare circumstances, usually due to protocol conflicts, i.e. a MUST really should of been a SHOULD and it might have been a SHOULD in protocol STD, but made into a MUST in protocol RFC update and that now causes problems, hence undocumented switches are provided for support. o SHOULD items Here we have three forms of the options: [X] Extended Feature A- higher sweet benefit! default ON [_] Extended Feature B- Nice, but high overhead, default OFF [_] Extended Feature C- It was default ON, but operator said NAH! MAY options are similar but heres you have learn more about the consumer needs to decide what protocol overhead is added and/or initial ON/OFF position. Many Implementators makes decides on the basic of this SHOULD value offers. Its a big waste of them, it won't be implemented. But when its get more adoption, maybe. And we can't impose Bloat Ware options that prove to be bad or not desired, so you have to present these SHOULDS as options. I sense a bad direction with what is basically ALL or Nothing protocol implementation, including with there little adoption, complex to support and simply not required. This might be enough to raise the barrier on adoption for some protocols that insist on on a All or Nothing conformance mandate. Why even bother with SHOULD, and use have MUST and MAY? -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 31, 2011, at 9:12 AM, Hector wrote: Keith Moore wrote: On Aug 31, 2011, at 8:30 AM, Hector wrote: In my view, SHOULD are user protocol options to set. In my view, SHOULD should rarely be used for optional protocol features, because optional protocol features should themselves be rare. And the primary purpose of SHOULD is not to permit optional protocol features. If SHOULD is read as a MUST IMPLEMENT, and that also implies MUST USE with no provision to disable then its should of been a MUST in the first place. Just because a feature is optional does not mean that it's a protocol feature... i.e. it doesn't mean that it affects how the implementation interacts with peers. SHOULD is IMO most often useful not when specifying how a protocol acts on the wire, but when specifying how a protocol needs to be implemented on a particular platform, where the precise semantics, API details, etc. naturally differ from one platform to another. Why even bother with SHOULD, and use have MUST and MAY? To get people out of the rathole of trying to specify exactly how everything must work in excruciating detail, in a world where there is inherently going to be some necessary variation. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I've been traveling so have not had a chance to do anything but watch the discussion on a RFC 2119 update. a few thoughts 1/ I am far from convinced that there is a need to update RFC 2119 there is a bug in the boilerplate (as has been mentioned) and some people seem to have a hard time understanding what (to me) seem like clear descriptions of (for example) MUST SHOULD - but the issues do not seem serious enough to warrant replacing what is, basically, a simple dictionary usage constraint 2/ it seems like a very Bad Idea to move 2119 to historic- we move RFCs to historic when no one uses them or when they are a Bad Idea in light of updated technology - I do not think that makes much sense in this case - in addition it makes the status of RFCs that have a normative reference to a historic document a bit funky - if an update is actually needed there is no reason that I can come up with that it could not just be that -- an update 3/ I doubt that I'll ever catch up with Postel as the most referenced RFC author so that is not a consideration (for me) I wrote RFC 2119 (most using text from RFC 1122) because people were using MUST without saying what they meant, an update, if people think that one is actually needed, will serve that purpose as well as 2119 has. When I posted the original ID it was pointed out that I should also address when such terms should be used (i.e. try to limit the use to where it actually made sense protocol-wise) - I tried to do that but that part may not have been as successful as it might have been - any update might try to be clearer in this area that RFC 2119 is. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Keith Moore wrote: On Aug 31, 2011, at 9:12 AM, Hector wrote: If SHOULD is read as a MUST IMPLEMENT, and that also implies MUST USE with no provision to disable then its should of been a MUST in the first place. Just because a feature is optional does not mean that it's a protocol feature... i.e. it doesn't mean that it affects how the implementation interacts with peers. Thats the problem with trying generalize SHOULD as single interpretation for all SHOULDs when it is so highly subjective many times. I think you are speaking of long term operations where an SHOULD is so widely adopted, it inherently because a MUST have in all new implementations. So that vain, sure, eventually the better options naturally become part of the protocol to the extent the options might be even remove to simplify things. We also have the opposite where a SHOULD is implemented but no one users it so eventually, it may be remove as an option. SHOULD is IMO most often useful not when specifying how a protocol acts on the wire, but when specifying how a protocol needs to be implemented on a particular platform, where the precise semantics, API details, etc. naturally differ from one platform to another. Yeah, but its also very very useful to offering what parts of a protocol are on and off and let operators decide what they want. Don't we already do this? Why even bother with SHOULD, and just use MUST and MAY? To get people out of the rathole of trying to specify exactly how everything must work in excruciating detail, in a world where there is inherently going to be some necessary variation. I agree, it is the easy way out. But wouldn't it still be a rathole if SHOULD was still a MUST-IMPLEMENT concept which is why a MUST made it an rathole in the first place? Too many people didn't like, not want it nor wish to waste time on a unproven concept. So you make it a SHOULD or a MAY. With a MUST-IMPLEMENT view of SHOULD, then SHOULD really isn't compromise if you have to implement and even more so if no one is allowed to turn it off. -1 on RFC2119bis :) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Burger Sent: Wednesday, August 31, 2011 12:37 AM To: hector Cc: IETF discussion list Subject: Re: 2119bis I would offer this highlights the problem with today's SHOULD. Some think SHOULD means something is OK to implement, but life does not end if you do not do it. Others think SHOULD means something HAS to be implemented, unless the environment indicates the protocol will not work in some corner case. On the other hand, given the current SHOULD definition in RFC2119, I'm at a loss to understand how one could reasonably come to other than the second interpretation you give here. It's fairly explicit to me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
--On Wednesday, August 31, 2011 11:34 +0300 Jari Arkko jari.ar...@piuha.net wrote: Eric, John, Would having professional editors make a difference here? I know it is controversial, but there is at least one other ... I think the existing Discuss criteria already says very clearly that editorial comments cannot be blocking DISCUSSes. This issue drifts quickly from DISCUSS criteria into how we review, approve, and edit documents, but I think they are completely intertwined... so please forgive the apparent digression. I see a lot of language feedback from IESG and directorate reviews, but its rare to have them appear in the DISCUSSes. If they do, its inappropriate, you should push back. And I'm sure you will :-) Yes, but... First of all, a long list of editorial comments from one or more ADs can do fully as good a job of slowing a document down as a DISCUSS or two. And anyone smart enough to be on the IESG is more than capable of disguising what is really an editorial comment as a substantive issue that gets a DISCUSS. Part of the problem is that there are a whole series of judgment calls tangled up with this topic. For example: * If an AD says this particular paragraph is really important to the specification and, after several readings, I can't tell what is actually means or whether a particular implementation would be conforming, that is a problem, certainly worthy of a DISCUSS (or, given Keith's typology, NO until it is fixed. On the other hand, this particular paragraph is important and it is much harder to understand than it should be, even though the intent is clear is an editorial comment that should be non-blocking. I think we all know that the boundary between those two can be very thin and even a matter for debate. * I can't speak for others, but I'm often tired with a document for which I've got responsibility by the time I get it past the small revisions and nit-picking or WG LC and pre-IETF-LC comments from ADs. Faced with what I consider an inappropriate editorial comment or even an inappropriate DISCUSS, I have a choice between pushing back (thereby guaranteeing that I will have to deal with the document for additional weeks or months) or just making the requested changes and getting the document off my plate. I'm probably more stubborn about editorial matters than most people, but even I usually just give in. Besides, we pay the RFC Editor a large amount of money every year to do the editing. Documents need to be clear enough to be understood, but the RFC editor can handle most of the editorial problems. Yes, and I've been saying that, along with variations on let them do their job for years. But it introduces another set of issues. I don't think I'm giving away a secret by saying that they believe that their contracts and the way their performance is measured focus on pages of published output per month. They also believe that the IESG has told them things that amount to minimal editing or copy editing only on many occasions. Unless we can change things to shift from measuring what is easy to include a focus on quality improvements, the RFC Editor ends up in an impossible situation. From a standardization perspective, it also isn't desirable to make lots of editorial changes post-approval. AUTH48 is a rather dangerous process because it is easy to make mistakes there that no one catches or, again, for an exhausted author to make it is easier to let this go than to fight about it decisions. One could, in principle, send all such documents back to a producing WG for final, pre-publication review but, in my experience, most of the people in most WGs get more exhausted by the document end-game than most authors (and most other participants want to reopen long-dead issues by questioning the language used to describe them). This is precisely why many SDOs use a two-stage vote in which the first vote approves the general concepts and technical content, the document then gets edited into final form by profession staff, and then the first and only actual approval vote occurs (possibly by a different body with a different mission). That wouldn't work well in the IETF... and not only because we have a more-than-one-step standards process. I think we could adopt a process in which a WG, or an AD, could look at a document before IETF LC and say this is going to need a lot of editorial work before approval but the technical content looks ok, so let's hand it off to the RFC Editor now and get it cleaned up before a final WG review and IETF LC. But that has a lot of procedural and budgetary implications and I don't know if we are ready to deal with them. (That being said, I've seen documents that were sent back because they really were not understandable. Obviously there is some bar under which you should not go, or the document cannot advance at all. This happens more in WG stages than in the IESG. But if you can't communicate your idea clearly then I
Re: 2119bis
On Aug 31, 2011, at 10:03 AM, Murray S. Kucherawy wrote: On the other hand, given the current SHOULD definition in RFC2119, I'm at a loss to understand how one could reasonably come to other than the second interpretation you give here. It's fairly explicit to me. The simplest explanation is that people don't bother to read 2119. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
--On Wednesday, August 31, 2011 08:02 -0400 Keith Moore mo...@network-heretics.com wrote: I think the existing Discuss criteria already says very clearly that editorial comments cannot be blocking DISCUSSes. So nobody has the job of making sure that the documents are well-written in clear English? Keith, I don't think either Jari or I were saying anything remotely close to that. Think about it this way, moving away from the language in 2026 and back to the much-earlier assumptions on which that language, and the multiple-stage standards process, were based. With the understanding that these are oversimplifications, we can have three types of documents: (1) Complete spec, so complete and so clear that someone with reasonable familiarity with the technology but no contact with the authors, anyone who participated the relevant WG, or the WG mailing list can produce an implementation that will interoperate with other implementations --both those produced with the same level of knowledge and those produced by, or in coordination with, the authors. (2) Specs that are good and clear enough to act as aids to memory and documentation about agreement so that someone who participated in the WG and who can ask questions of a WG mailing list and/or the authors can produce an interoperable implementation. (3) A spec that just outlines an idea for others to try out. Because I want to avoid losing the distinction, I would point out that only the first is really suitable for use in a procurement spec (although people often accept the second and sometimes the third). From a standardization standpoint, we should consider the third as potentially appropriate for Experimental, especially if the purpose of the experiment is to help understand what the details should be. We've been trying to hold everything (even, in many cases, experimental documents) up until we get to that first criterion, but, if one looks at long-term history and reads between the lines, only DS and above actually require documentation at that level. We ought to, IMO, be permitting publication of PS documents at the second level as long as there are no _obvious_ ambiguities that cannot be figured out (the same way) by people of good will acting in good faith and with help from WG lists and as long as there are no other known [technical] defects. I suggest that we have called that second category Proposed Standard and then interpreted that term in ways that have caused us harm. It is closer to what ISO has called a Type II Technical Report (known in internal jargon as a pre-standard or sub-standard) and what IEEE calls (or used to call) a Draft Standard for Trial Use -- a document that represents consensus about the idea and about publication, including publication as a standard when it is mature enough, and good enough to form a basis for experimentation and serious evaluation, but not expected to meet criterion (1) above. From that particular narrow perspective, if one wants PS documents published quickly rather than killing them and the standards process through delays and nit-picking that are almost irrelevant to the technical content of the specification, then we either need to make some really major changes in how we do things or we need to be willing to publish things that, explicitly or implicitly contain notes like the following paragraph is horribly written and barely intelligible and will need to be fixed up for DS but, right now, everyone involved knows what it means. Insisting that all PS documents be well-written in clear English may actually be our enemy. That doesn't mean they shouldn't be. And it would be perfectly reasonable for some WGs and authors to decide the situation is do the work now (and accept the added delay) or do it later, so better now. But we should not be trying to force every PS document to meet such a standard... at least if we want to get them out quickly and have them treated as interim steps rather than final products. Besides, we pay the RFC Editor a large amount of money every year to do the editing. Documents need to be clear enough to be understood, but the RFC editor can handle most of the editorial problems. If the document is edited for clarity after final review, that's really a botch in the process. It means that the review doesn't apply to the version of the document being published. Of course the RFC Editor's resources shouldn't be used for documents that aren't otherwise deemed worthy of publication, and you'd like to avoid the RFC Editor having to do multiple reviews, so I admit that this is tricky to solve. Yes. See my previous note. (That being said, I've seen documents that were sent back because they really were not understandable. Obviously there is some bar under which you should not go, or the document cannot
Re: 2119bis
On Aug 31, 2011, at 9:57 AM, hector wrote: SHOULD is IMO most often useful not when specifying how a protocol acts on the wire, but when specifying how a protocol needs to be implemented on a particular platform, where the precise semantics, API details, etc. naturally differ from one platform to another. Yeah, but its also very very useful to offering what parts of a protocol are on and off and let operators decide what they want. Don't we already do this? yes, it is done to some degree. but that's not, in general, a desirable practice. (though there are cases where it can be justified). Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Keith Moore mo...@network-heretics.com wrote: The biggest problem with the current voting system (other than misleading labels, which do cause real problems of their own) is the presumption that the document should go forward no matter how few IESG members read the document. Keith makes a good point here; but I wouldn't agree to any rule that a particular number must read a document. Some ADs quite properly defer actual reading to review teams. So No Objection votes from ADs who didn't read the document count as Yes votes, No, they don't. (But I can't ask folks posting to this thread to actually _understand_ the difference.) Roughly, the rule says enough ADs must enter a position before a document can be approved. Basically, No-Objection says the AD is somewhat familiar with the document and actively consents to approving it. These positions are _NOT_ votes. but there's also a presumption in the rules (as well as pressure from other ADs who want to get documents off the agenda) to clear Discuss votes in favor of moving a document forward whether or not the identified issues have been adequately addressed. This is somewhat true, but the pressure is highly variable. The agendas _are_ too crowded (IMHO); but in most cases sufficient progress will have been made before the telechat that only a few seconds are needed to agree to AD-followup status. When there is no progress between telechats (most often due to unresponsive authors/editors), there _is_ some pressure to reduce what a DISCUSS asks for. It might help for non-IESG folk to chime in on whether this is good or bad... (There _are_ cases where the responsible AD puts quite a bit of pressure on the DISCUSS-holder: that's really an internal issue which I don't believe this list should be discussing.) (One thing that I didn't mention that also needs to be fixed if it's still the case is the presumption that the responsible AD votes Yes for the document. I don't know what the tools do now, but this Yes vote used to be automatically filled-in.) We're seeing a number of cases where the responsible AD holds a DISCUSS at the time of the telechat -- generally because LastCall hadn't ended yet when the document was placed on the agenda. IMHO, there's nothing there that needs fixing. Arguably when a poor quality document gets to IESG, it's a failure on the part of the WG to do due diligence. IMHO, there _are_ poor-quality documents that get on the IESG agenda. I'm not sure it helps to allocate blame... But there is a huge variance between WGs on diligence. I am alarmed by the sheer number of COMMENTS saying in essence, This document is not specific enough to guide an implementor to an interoperable implementation. To me, that's really-close to DISCUSS territory... However, we really don't have a process for improving situations like that -- other than for it to be a DISCUSS and for authors to actually be responsive (which would probably require repeating at least one LastCall). :^( In the absence of such a process, I really can't blame ADs for reducing such issues from DISCUSS to COMMENT, and entering ABSTAIN if they think the issue is serious. But the problem is actually deeper than that - it's partially structural (in that IETF partitions almost all work into narrowly focused WGs who don't represent a sufficiently broad spectrum of interests), and partially due to a failure to consistently apply good engineering principles across all of IETF. +1 This problem, of course, is endemic in organizations that depend on volunteers. And I really don't have suggestions on how to ensure sufficient wide-area review, though review teams certainly help. I wonder if there's some room for process-improvement by formalizing some role for review teams... IESG's assuming that the WG has produced a quality result basically works to mask the other problems with IETF's way of doing work. I don't agree that's what IESG members assume -- they IMHO instead presume that documenting ideas (even not-fully-baked ideas) is a mostly-unmitigated good-thing. But even if WGs generally did produce high quality results without issues (which I don't think is the case now), IESG review should still not presume that they do. There will always be some failures at the WG level, and the IESG's job is to try to catch those. I don't think we have universal agreement on that as a goal. Of course, neither do we have universal agreement that anyone else has the job to catch these. Some of us quite plainly believe it shouldn't be anyone's job to catch these: that ideas should be published and we should see whether rough consensus emerges later. (All of which brings us to the actual question: when advancing a maturity-level, what constitutes sufficient consensus? Arguably, folks will expect a higher maturity level to indicate that the standard is ready to be handed to an implementor, and
Re: Discuss criteria for documents that advance on the standards track
On Aug 31, 2011, at 10:42 AM, John C Klensin wrote: We ought to, IMO, be permitting publication of PS documents at the second level as long as there are no _obvious_ ambiguities that cannot be figured out (the same way) by people of good will acting in good faith and with help from WG lists and as long as there are no other known [technical] defects. That would be fine with me if we could somehow effectively discourage deployment of proposed standards in products. But that's a lost cause, IMO. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
non-2119
While 2119 is being discussed, I thought I'd mention a small I-D that Dave Crocker and I wrote on terminology that might be used in places where 2119 ought not apply. It's Non-Normative Synonyms in RFCs http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-01 Thoughts on this draft would be appreciated as well. Tony Hansen t...@att.com On 8/31/2011 9:28 AM, Scott O. Bradner wrote: I've been traveling so have not had a chance to do anything but watch the discussion on a RFC 2119 update. a few thoughts 1/ I am far from convinced that there is a need to update RFC 2119 there is a bug in the boilerplate (as has been mentioned) and some people seem to have a hard time understanding what (to me) seem like clear descriptions of (for example) MUST SHOULD - but the issues do not seem serious enough to warrant replacing what is, basically, a simple dictionary usage constraint 2/ it seems like a very Bad Idea to move 2119 to historic- we move RFCs to historic when no one uses them or when they are a Bad Idea in light of updated technology - I do not think that makes much sense in this case - in addition it makes the status of RFCs that have a normative reference to a historic document a bit funky - if an update is actually needed there is no reason that I can come up with that it could not just be that -- an update 3/ I doubt that I'll ever catch up with Postel as the most referenced RFC author so that is not a consideration (for me) I wrote RFC 2119 (most using text from RFC 1122) because people were using MUST without saying what they meant, an update, if people think that one is actually needed, will serve that purpose as well as 2119 has. When I posted the original ID it was pointed out that I should also address when such terms should be used (i.e. try to limit the use to where it actually made sense protocol-wise) - I tried to do that but that part may not have been as successful as it might have been - any update might try to be clearer in this area that RFC 2119 is. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Dear Jari, During the discussion of the two maturity levels change, a question was brought up about DISCUSSes appropriate for documents that advance on the standards track. We discussed this in the IESG and I drafted some suggested guidelines. Feedback on these suggestions would be welcome. The intent is to publish an IESG statement to complement the already existing general-purpose DISCUSS criteria IESG statement (http://www.ietf.org/iesg/statement/discuss-criteria.html). Here are the suggested guidelines for documents that advance to IS: http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt Comments appreciated. Please send comments either on this list or to the IESG (i...@ietf.org) in time before our next telechat (Thursday, September 8, 2011). Jari As with 2119bis, thank you guys for putting this together. The text in http://www.arkko.com/ietf/iesg/discuss-criteria-advancing.txt says IESG reviews should be considered as a review of last resort. Most documents reviewed by the IESG are produced and reviewed in the context of IETF working groups. In those cases, the IESG cannot overrule working group consensus without good reason; informed community consensus should prevail. I might have thought that the point for documents advancing on the standards track is that they already have *IETF* consensus (especially if they are being advanced without text changes), so the IESG cannot overrule *IETF* consensus without good reason ... which seems like a higher bar (one can more easily assume the existence of a rogue working group producing a rogue Internet-Draft, than a rogue IETF that is still sane enough to NomCom-select non-rogue ADs who will push back on rogue standards-track documents advancing :-) So perhaps s/informed working group consensus/informed IETF consensus/? I note that this isn't quite tying the IESG's hands (I'm reading this descriptive text as the moral equivalent of MUST NOT overrule IETF consensus without good reason, which leaves one hand free). Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
thanks Spencer for pointing this part out. On Aug 31, 2011, at 11:23 AM, Spencer Dawkins wrote: IESG reviews should be considered as a review of last resort. Most documents reviewed by the IESG are produced and reviewed in the context of IETF working groups. In those cases, the IESG cannot overrule working group consensus without good reason; informed community consensus should prevail. The idea that WG consensus should prevail is simply incorrect. It biases IESG in an inappropriate way. There are a number of very good reasons for overriding WG consensus, e.g. - there is no evidence of broad community consensus or a clear lack of broad community consensus - the document does not meet the criteria specified in 2026 (or other document when applicable) - the document is ambiguous in such a way that it is likely to degrade interoperability The WG DOES NOT represent the entire community.Far too often, WGs are deliberately chartered in such a way as to marginalize parts of the community Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
--On Wednesday, August 31, 2011 11:08 -0400 Keith Moore mo...@network-heretics.com wrote: On Aug 31, 2011, at 10:42 AM, John C Klensin wrote: We ought to, IMO, be permitting publication of PS documents at the second level as long as there are no _obvious_ ambiguities that cannot be figured out (the same way) by people of good will acting in good faith and with help from WG lists and as long as there are no other known [technical] defects. That would be fine with me if we could somehow effectively discourage deployment of proposed standards in products. But that's a lost cause, IMO. Keith, IMO, there are two possibilities here. At this point, sadly, both involve a chicken-and-egg problem. Such is life. (1) We proceed as if Proposed Standards are what 2026 (and the earlier culture) claims they are and work on ways to reinforce that notion in the community. If that is our goal, than getting documents out sooner and having them look a bit rough as well as being a bit rough is A Good Thing and reinforces the deploying at PS, much less at I-D, is taking a big risk. The idea isn't foreign to the industry: to take a handy example, we saw products identified as 801.11-draft-N floating around for years. Every vendor who shipped one (and their more sophisticated customers) knew that there could be serious incompatibilities between their approximations to the drafts and the real 802.11n. (2) We accept, and effectively encourage, deployment of proposed standards in products, either because it is a lost cause or because we think it is a good idea. As part of that, we move further down the path of ensuring that PS documents are complete and polished (my group (1)) and of guaranteeing that there will be no significant changes in the future (either in going to DS or in grade).If that is really our position, then we better stop grumbling about how long it takes to get PS documents out (and the partially-consequential deployment of technologies from I-Ds), accept the fact that the SDOs who used to be very concerned about how much faster the IETF was than they were have now won and become faster than us (in large measure because we have slowed down so much). And we should stop wasting time trying to figure out how many maturity levels we need or what those criteria should be because the answer is one level is what we get and pretending anything else, e.g., by trying to fine-tune procedures, is an embarrassing public act of self-delusion (stronger language occurs to me but would probably get the message killed by spam filters). Remember that, while ignoring procedures and category definitions that we don't follow is not desirable, fixing them to reflect a model that doesn't (and won't) exist either is a public demonstration that we are disconnected from reality. I'd much rather leave that distinction to some other SDOs than join them. YMMD. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY. Of course there is. Its the distinction between - Qualified SHOULD) Here lie dragons. Take the recommended route, unless you know how to fight them. Unqualified SHOULD) Here lie some dangers. Check with someone who knows, or take the recommended route. MAY) Here's an area. You could go there. Of course, the first and last pieces of text are preferred. But sometimes no one was brave enough to explore the area, so we don't actually know what dangers there are, they cannot be listed. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
On Aug 31, 2011, at 11:36 AM, John C Klensin wrote: We ought to, IMO, be permitting publication of PS documents at the second level as long as there are no _obvious_ ambiguities that cannot be figured out (the same way) by people of good will acting in good faith and with help from WG lists and as long as there are no other known [technical] defects. That would be fine with me if we could somehow effectively discourage deployment of proposed standards in products. But that's a lost cause, IMO. Keith, IMO, there are two possibilities here. At this point, sadly, both involve a chicken-and-egg problem. Such is life. (1) We proceed as if Proposed Standards are what 2026 (and the earlier culture) claims they are and work on ways to reinforce that notion in the community. [...] (2) We accept, and effectively encourage, deployment of proposed standards in products, either because it is a lost cause or because we think it is a good idea. [...] Agree with your description of the two possibilities, but I think the decision of possibility 2 has long since been forced on us by market expectation and habit. We could fix it, perhaps, by drastically changing how we label our products (dropping the whole notion of Proposed Standard, refusing to publish your category 2 documents as RFCs, etc.). But we can't significantly change market perception of what RFC and Proposed Standard mean. (which, BTW, is why I think that moving to a two-step process, while probably Mostly Harmless, won't do a bit of good in the overall scheme of things) Remember that, while ignoring procedures and category definitions that we don't follow is not desirable, fixing them to reflect a model that doesn't (and won't) exist either is a public demonstration that we are disconnected from reality. I'd much rather leave that distinction to some other SDOs than join them. YMMD. And my assertion is that the model inherent in your possibility #1 above doesn't exist and won't exist absent from drastic change. Insisting on high quality for proposed standards is recognizing current market reality. And I'm not one of those people who believes that market perceptions are inherently unchangeable. But expecting the market to change how it interprets our documents without us bothering to significantly change how we present them to the public - THAT would indeed be a serious disconnect from reality. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Keith, Peter, I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. I agree. In any case, Peter, I think its fine to add the NOT RECOMMENDED word to the boilerplate. Publish a spec on that, have it Update 2119, and then new RFCs would refer to that (say, 7119) instead of 2119 and everyone would be happy. But I'm not quite sure why there are other changes in the text. Maybe I need to be educated better. On quick read I got more questions from it than what I get from 2119... Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
Keith, Yes, to what you are saying, but I was pointing out that the text we're discussing isn't intended to apply to moving what a working group has consensus for onto the standards track, it's intended to apply to what the *IETF* already has consensus for, that's already on the standards track, further along the standards track. I think there's a higher bar, especially when a document is advancing unchanged, because I don't think there's any meaningful distinction between a widely deployed PS that could be improved, and advancing it to be a widely deployed IS that could be improved. I don't see the value-add from DISCUSSing the advancement, because the same document is sitting there as a proposed standard, and widely deployed. If ADs look at a document proposed for advancement and see real and meaningful opportunities to improve the specification, I think it makes just as much sense to advance the document, as is, and start looking for people who will produce an improved version, as to slow down the document for DISCUSSion in the hope you end up with an improved document, that can then advance. Finding those people, and chartering that work, falls well within the S in IESG, AFAICT. Thanks, Spencer - Original Message - From: Keith Moore To: Spencer Dawkins Cc: Jari Arkko ; IETF Discussion Sent: Wednesday, August 31, 2011 10:35 AM Subject: Re: Discuss criteria for documents that advance on the standards track thanks Spencer for pointing this part out. On Aug 31, 2011, at 11:23 AM, Spencer Dawkins wrote: IESG reviews should be considered as a review of last resort. Most documents reviewed by the IESG are produced and reviewed in the context of IETF working groups. In those cases, the IESG cannot overrule working group consensus without good reason; informed community consensus should prevail. The idea that WG consensus should prevail is simply incorrect. It biases IESG in an inappropriate way. There are a number of very good reasons for overriding WG consensus, e.g. - there is no evidence of broad community consensus or a clear lack of broad community consensus - the document does not meet the criteria specified in 2026 (or other document when applicable) - the document is ambiguous in such a way that it is likely to degrade interoperability The WG DOES NOT represent the entire community.Far too often, WGs are deliberately chartered in such a way as to marginalize parts of the community Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/31/11 9:48 AM, Jari Arkko wrote: Keith, Peter, I think you're overgeneralizing. My experience is that judicious use of SHOULD seems to make both protocols and protocol specifications simpler; trying to nail everything down makes them more complex. I agree. In any case, Peter, I think its fine to add the NOT RECOMMENDED word to the boilerplate. Publish a spec on that, have it Update 2119, and then new RFCs would refer to that (say, 7119) instead of 2119 Yes, that is one path. and everyone would be happy. I'm not sure that everyone would be happy, because I do think that some clarifications and additional guidelines might be helpful. But those, too, could go in a separate (likely Informational) document that would not necessarily update (and certainly not obsolete) 2119. But I'm not quite sure why there are other changes in the text. Maybe I need to be educated better. On quick read I got more questions from it than what I get from 2119... Thus the desirability of writing a separate document. Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/31/11 9:52 AM, Keith Moore wrote: or maybe just file an erratum. There is an erratum on file: http://www.rfc-editor.org/errata_search.php?eid=499 I started down this road in part while working to clear out errata... Peter -- Peter Saint-Andre https://stpeter.im/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Keith Moore wrote: On Aug 31, 2011, at 9:57 AM, hector wrote: Yeah, but its also very very useful to offering what parts of a protocol are on and off and let operators decide what they want. Don't we already do this? yes, it is done to some degree. Every protocol I have implemented such as PPP, RADIUS, SMTP, TELNET, FTP, POP3 among the augmented protocols all have some levels of Features presented as SHOULDs and MAYs and those seem necessary where exposed in some form of configuration options. They might be tweaked for optimal out of the box performance, so you might not need them. Just look at SMTP extensions, EHLO features. There are SHOULD for 5 mins timeouts and 5321 states that its good idea to make this configurable. Came in handy the other day! :) or even DKIM. Protocol options made available, but fined tune so the operators just can start using it. But not all will use the setting you prepare for them. but that's not, in general, a desirable practice. (though there are cases where it can be justified). While I agree long time engineering fine tuning, options become stable, deprecated or obsolete and short of an finely tuned embedded system, turnkey system, even smart phone/devices, and not really even then, I hardly seen any protocol with options not implement with some level of exposure deemed necessary. The simplest explanation is that people don't bother to read 2119. How can you make a claim like this with a straight face or I guess fingers? That invites useless conflicts like get a dictionary for the word Recommended, or just plain old accepting the simple idea that after determining all full implications above and beyond what was necessary is a valid reason to IGNORE the recommendation. -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
or maybe just file an erratum. I think it's fairly obvious that any document that actually uses NOT RECOMMENDED should define what it means, if it expects those words to have any meaning other than the ordinary English meaning of those words (with or without capitalization). I've seen documents that didn't quote the 2119 boilerplate verbatim because they didn't use all of the terms defined in 2119. I didn't see any problem with that. On Aug 31, 2011, at 11:48 AM, Jari Arkko wrote: In any case, Peter, I think its fine to add the NOT RECOMMENDED word to the boilerplate. Publish a spec on that, have it Update 2119, and then new RFCs would refer to that (say, 7119) instead of 2119 and everyone would be happy. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 31, 2011, at 11:55 AM, Hector wrote: Keith Moore wrote: On Aug 31, 2011, at 9:57 AM, hector wrote: Yeah, but its also very very useful to offering what parts of a protocol are on and off and let operators decide what they want. Don't we already do this? yes, it is done to some degree. Every protocol I have implemented such as PPP, RADIUS, SMTP, TELNET, FTP, POP3 among the augmented protocols all have some levels of Features presented as SHOULDs and MAYs and those seem necessary where exposed in some form of configuration options. They might be tweaked for optimal out of the box performance, so you might not need them. Just look at SMTP extensions, EHLO features. There are SHOULD for 5 mins timeouts and 5321 states that its good idea to make this configurable. Came in handy the other day! :) or even DKIM. Protocol options made available, but fined tune so the operators just can start using it. But not all will use the setting you prepare for them. Old protocols that were extended after they were widely deployed are one of the exceptional cases where SHOULD / SHOULD NOT / etc. make sense to describe protocol features. They can't always be MUSTs or MUST NOTs because of the need to maintain backward compatibility with old implementations. Things like timeout intervals are often labeled as SHOULDs because they aren't precisely determined, they're educated guesses. So implementors and perhaps operators should have some leeway to tweak them in light of experience. The simplest explanation is that people don't bother to read 2119. How can you make a claim like this with a straight face or I guess fingers? Because of long experience that indicates that implementors often fail to read base specifications thoroughly, much less the referenced specifications. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Discuss criteria for documents that advance on the standards track
--On Wednesday, August 31, 2011 11:47 -0400 Keith Moore mo...@network-heretics.com wrote: ... IMO, there are two possibilities here. At this point, sadly, both involve a chicken-and-egg problem. Such is life. (1) We proceed as if Proposed Standards are what 2026 (and the earlier culture) claims they are and work on ways to reinforce that notion in the community. [...] (2) We accept, and effectively encourage, deployment of proposed standards in products, either because it is a lost cause or because we think it is a good idea. [...] Agree with your description of the two possibilities, but I think the decision of possibility 2 has long since been forced on us by market expectation and habit. We could fix it, perhaps, by drastically changing how we label our products (dropping the whole notion of Proposed Standard, refusing to publish your category 2 documents as RFCs, etc.). But we can't significantly change market perception of what RFC and Proposed Standard mean. Whether we agree on how best to manage a perception change and what it takes, I agree that there is no single magic bullet, much less a painless one. I would turn your comment around slightly and say that a change in names is likely to have little or no effect on perceptions unless we actually change what we do. As I said in and earlier note, there is something of a chicken-and-egg problem here. while probably Mostly Harmless, won't do a bit of good in the overall scheme of things) For reasons I've explained in previous notes, I don't think procedural changes, especially from not followed and doesn't work but ancient or contemporary and [still] doesn't work or reflect reality, are harmless (mostly or otherwise). Remember that, while ignoring procedures and category definitions that we don't follow is not desirable, fixing them to reflect a model that doesn't (and won't) exist either is a public demonstration that we are disconnected from reality. I'd much rather leave that distinction to some other SDOs than join them. YMMD. And my assertion is that the model inherent in your possibility #1 above doesn't exist and won't exist absent from drastic change. Insisting on high quality for proposed standards is recognizing current market reality. If you are right, then fussing around with how many maturity levels we have, what criteria we claim we are using, and even how we name things, are dangerous as well as a waste of time and resources. That is where we are maybe in violent agreement -- we either ought to be identifying real problems and fixing them or just staying with what we have until we have the knowledge and will needed to make real changes. In that regard, I applaud one aspect of Jari's note, which is that it affects and IETF administrative procedure and not a fundamental (and unnecessary) procedural change. By contrast, suppose draft-housley-two-maturity-levels were just shelved for a while and replaced by an announcement by an AD or two (ideally from areas that have really low advancement rates even as compared to the already-low IETF average) that they intended to (i) accept a public assertion of interoperability as an implementation report, issue an IETF LC for DS to see if anyone with real experience with the protocol objects loudly, and then move to advance the document, and (ii) that they would construe the passage of the relevant number of month and public claims of deployment as sufficient incentive to issue an IETF LC for advancement to IS. If the rest of the IESG were willing to go along with that, we'd have a real experiment without permanent changes to the official procedures. People who saw a problem advancing a particular protocol or document could object and it would presumably work only for PS documents that were of high quality. If it worked out, we would have a basis for coming back and evaluating whether there really was enough of a difference between DS and IS to be worth the trouble and whether the practical differences between that sort of implementation report and today's interpretation of what is required was. And then we could take ...two-maturity-levels back up with some confidence about both utility and potential harm. And, if you are right and this is all hopeless without really major changes, then that experiment might give us the information needed to finally come to grips with that and either make the major change or accept the status quo and stop spending energy trying to turn the knobs a degree or two. And I'm not one of those people who believes that market perceptions are inherently unchangeable. But expecting the market to change how it interprets our documents without us bothering to significantly change how we present them to the public - THAT would indeed be a serious disconnect from reality. I actually agree. john
Re: Discuss criteria for documents that advance on the standards track
On Aug 31, 2011, at 12:19 PM, John C Klensin wrote: we either ought to be identifying real problems and fixing them or just staying with what we have until we have the knowledge and will needed to make real changes. That would certainly be my preference. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: non-2119
Isn't it already incorporated in Section 3 of 2119bis: When it is not appropriate to use the conformance terms, authors can use a variety of alternative words and phrases, such as: need to or mandatory instead of MUST; ought to or strongly encouraged instead of SHOULD; and might or discretionary instead of MAY. To prevent confusion, authors ought to use these alternative words and phrases instead of the lowercase versions of the conformance terms, and to use the conformance terms only in their uppercase versions. Mykyta 31.08.2011 18:10, Tony Hansen wrote: While 2119 is being discussed, I thought I'd mention a small I-D that Dave Crocker and I wrote on terminology that might be used in places where 2119 ought not apply. It's Non-Normative Synonyms in RFCs http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119-01 Thoughts on this draft would be appreciated as well. Tony Hansen t...@att.com On 8/31/2011 9:28 AM, Scott O. Bradner wrote: I've been traveling so have not had a chance to do anything but watch the discussion on a RFC 2119 update. a few thoughts 1/ I am far from convinced that there is a need to update RFC 2119 there is a bug in the boilerplate (as has been mentioned) and some people seem to have a hard time understanding what (to me) seem like clear descriptions of (for example) MUST SHOULD - but the issues do not seem serious enough to warrant replacing what is, basically, a simple dictionary usage constraint 2/ it seems like a very Bad Idea to move 2119 to historic- we move RFCs to historic when no one uses them or when they are a Bad Idea in light of updated technology - I do not think that makes much sense in this case - in addition it makes the status of RFCs that have a normative reference to a historic document a bit funky - if an update is actually needed there is no reason that I can come up with that it could not just be that -- an update 3/ I doubt that I'll ever catch up with Postel as the most referenced RFC author so that is not a consideration (for me) I wrote RFC 2119 (most using text from RFC 1122) because people were using MUST without saying what they meant, an update, if people think that one is actually needed, will serve that purpose as well as 2119 has. When I posted the original ID it was pointed out that I should also address when such terms should be used (i.e. try to limit the use to where it actually made sense protocol-wise) - I tried to do that but that part may not have been as successful as it might have been - any update might try to be clearer in this area that RFC 2119 is. Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis - SHOULD Classifications
Barry Leiba wrote: Just responding to a small part, here: � B) RFC2119 states SHOULD is the same as the adjective RECOMMENDED. As far I am concern, a recommendation is not a mandate nor obligation. .. But don't make the mistake of thinking that, in the context of RFC 2119, one can use one's own English sense of what the meanings of these terms are. Agree, that is why the final part of my email I suggested the consideration to remove the last sentence of the text be removed; The term RECOMMENDED is equivalent to SHOULD. Personally, it benefit us if we state SHOULD under different classifications. I'm just winging it, but perhaps: NEW ITEM IMPROVEMENT SECURITY (VERY IMPORTANT) A context of which the SHOULD offers has a lot of weight in the decision making process. Example: If the SHOULD is related to security, then all efforts MUST be to made to support it. If the SHOULD item is an improvement not related to security, then all efforts SHOULD be to made to support it. If the SHOULD item is a new item not related to security, then all efforts MAY be to made to support it. Of course, there is the interesting nature of recursion here and the last two can possibly be folded, but I think stating SHOULD compliance classified under new, improvement and the level of importance context will help rather than trying to state it as a generalize, ambiguous rule of thumb - A MUST BUT OPTIONAL IFF YOU KNOW WHAT YOU ARE DOING. The basic idea is that when is something is NEW there is lesser obligation to support it until its becomes widely adopted. If its really an important feature, like security, then it ought to be stated with a heavy obligatory emphasis. Also, we may consider other general guidelines text like: New protocol enhancements with SHOULD key words MUST NOT be used a non-compliance measurement tool of existing compliant implementations. i.e. current implementator are not broken because they are not currently supporting a SHOULD. A new protocol that has a OPTIONAL dependency on an existing optional protocol MUST NOT use MUST|SHOULD as an enforcement tool for make implementator to support the optional protocol. The last one I had trouble writing it, but I think you get the gist of it. Overall, I believe the system has worked - we got this far because we gave implementators the benefit of the doubt that valid reasons to ignore was done responsibly and the protocols still worked. The problem, in my view, has been an agenda of enforcing protocol behavior from a Throw the book non-compliance mindset, worst when dealing with integrated of optional protocols, yet not equally applied. e.g., I don't wish to honor that other protocol SHOULD but you MUST follow my protocol SHOULD. -- Sincerely Hector Santos http://www.santronics.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Keith == Keith Moore mo...@network-heretics.com writes: In my view, SHOULD are user protocol options to set. Keith In my view, SHOULD should rarely be used for optional Keith protocol features, because optional protocol features should Keith themselves be rare. And the primary purpose of SHOULD is not Keith to permit optional protocol features. Let me give an example of where I think SHOULD is useful: a TLS end-point SHOULD verify the received certificate against a trusted anchor. Removing this requirement in SMTP-TLS has meant that we now have opportunistically encrypted email transmission. It makes sense for the TLS library to have this option. In a web browser, the same SHOULD is much more controversial. Some TLS libraries have this as a MUST, and there is all sorts of trouble for people implementing other protocols or authentication mechanisms over TLS. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
I think we should update our RFCs when there's a generally accepted errata. I mean, I know about errata. I browse IETF docs through tools.ietf.org and they show me the errata links. But... shame on me... I don't click through those links often enough. I suspect I'd miss a few even if I was implementing something. Its far better if the entire document is up to date. I suspect this holds for other at least some other people, too. Jari On 31.08.2011 18:54, Peter Saint-Andre wrote: On 8/31/11 9:52 AM, Keith Moore wrote: or maybe just file an erratum. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Wednesday, August 31, 2011 9:03 AM To: Hector Cc: IETF discussion list Subject: Re: 2119bis Because of long experience that indicates that implementors often fail to read base specifications thoroughly, much less the referenced specifications. I absolutely agree, and also with your earlier point that a lot of people apparently either don't bother to read RFC2119 at all, or (in my experience) read it selectively. If there is an RFC2119bis, I would like to see it illustrate the cases where a MUST would be preferred over a SHOULD, and vice-versa, such that the implications to both the spec author and the reader are clarified. It already seems to start down that road, which is fine. But I don't think there's anything wrong with the definitions as we have them; I think they've served us well for the last fourteen years. I don't agree at all with the interpretation of SHOULD as an optional protocol feature in all cases. RFC2119 makes it clear what SHOULD and RECOMMENDED mean beyond the dictionary definition. They are not an invitation to disregard those requirements merely because they are hard to implement or would confuse end users if exposed. It seems clear to me that SHOULD is the same as MUST... UNLESS, and the unless part has to be carefully considered in terms of how interoperability will be affected, not how your source code or user interface will become more complicated. It's certainly the case that there are some documents that got use of SHOULD wrong, but that doesn't mean RFC2119 is broken. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Murray S. Kucherawy wrote: -Original Message- But I don't think there's anything wrong with the definitions as we have them; I think they've served us well for the last fourteen years. Correct and by far, most deployments have use SHOULD = OPTION with an documented right to IGNORE - so be it written so be it followed. The MUST-IMPLEMENT seems to be an exception and not the rule and even then is inconsistency in application seem to be very selective. Maybe Tony's I-D can help reinforce this concept of a Recommendation: SHOULD, RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. and I hope these terms still don't means MUST-IMPLEMENT and worst a MUST-USE by the operator. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector Sent: Wednesday, August 31, 2011 10:57 AM Cc: IETF discussion list Subject: Re: 2119bis But I don't think there's anything wrong with the definitions as we have them; I think they've served us well for the last fourteen years. Correct and by far, most deployments have use SHOULD = OPTION with an documented right to IGNORE - so be it written so be it followed. This sentence is self-contradictory. SHOULD is, by definition, not OPTIONAL. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Hyatt Taipei cancellation policy?
Hi, Also note that, according to Google maps, it is possible to take a bus from the overflow hotel to the meeting. It requires a 400 meters walk from the hotel to the bus stop, but that should be managble even for an IETF attendee... The total travel (walking+bus) is 13 minutes. Regards, Christer -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ole Jacobsen Sent: 31. elokuuta 2011 0:31 To: Dean Willis Cc: ietf@ietf.org Subject: Re: Hyatt Taipei cancellation policy? Dean, Before you give up completely I would check out: http://wikitravel.org/en/Taipei Taxis are not expensive, the Metro even less so, and there are at least some budget hotels nearby. I expect the local hosts to provide more information soon -- they already have some info on the website. I agree about the Hyatt hotel price. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Tue, 30 Aug 2011, Dean Willis wrote: On 8/23/11 9:24 AM, John C Klensin wrote: So I'm opposed to a USD 200 (or any other number) firm limit on hotel rates. At the same time, I continue to wish that the IAOC would be more open with the community about how these decisions are made and, in particular, how the tradeoffs between sponsorship (and hence lower costs to the IETF for meeting infrastructure and arrangements) and meetings costs to attendees are made... open enough that the community could give substantive guidance on the subject, guidance that I assume the IAOC would follow if it were coherent and plausible. Quite right. There's more than just the hotel rates. My budget is about $2500 US per IETF meeting. That has to cover airfare, the IETF meeting fee, the hotel, meals, service charges, ground transport, mobile phone roaming, incidentals, etc. $300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF THE FREAKING QUESTION. Having the backup hotel a 10 minute taxi ride away is out of the question -- I can't afford taxis. If I can't walk, I can't go. So guess what? I told the wife last night that I wasn't planning to go to the Taiwan meeting. I wanted to go, but I just don't see how it can happen. Maybe I'll win the lottery between now and then... I'm disappointed. I'm hurt. I'm angry. And the trend has just been getting worse and worse with every venue. I want the IAOC's heads on a platter (preferably an inexpensive, disposable platter, like maybe the lid off an old pizza box) for signing us up to this venue. And I want a travel budget no larger than mine for the people we send to future meetings. If we can't find a reasonably inexpensive place to have a meeting, DON'T HAVE THE MEETING! -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Hi - From: Murray S. Kucherawy m...@cloudmark.com To: IETF discussion list ietf@ietf.org Sent: Wednesday, August 31, 2011 11:00 AM Subject: RE: 2119bis -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hector Sent: Wednesday, August 31, 2011 10:57 AM Cc: IETF discussion list Subject: Re: 2119bis But I don't think there's anything wrong with the definitions as we have them; I think they've served us well for the last fourteen years. Correct and by far, most deployments have use SHOULD = OPTION with an documented right to IGNORE - so be it written so be it followed. This sentence is self-contradictory. SHOULD is, by definition, not OPTIONAL. I disagree with the claim that there is a contradiction there, but I also think IGNORE is incorrect. The only difference between SHOULD and MAY is that the implementor / deployer needs a good excuse to not implement / employ a SHOULD. That's not the same as IGNORE. However, looking at an implementation from a conformance testing perspective, these are indistinguishable. If the conditions under which the feature may be omitted are well-defined, then an if not x MUST y structure would be much more appropriate, and this can be easily handled with the existing keywords. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, August 31, 2011 11:31 AM To: IETF discussion list Subject: Re: 2119bis This sentence is self-contradictory. SHOULD is, by definition, not OPTIONAL. I disagree with the claim that there is a contradiction there, but I also think IGNORE is incorrect. What was said is SHOULD = OPTION, but RFC2119 says OPTIONAL is the same as MAY. That's the contradiction. The only difference between SHOULD and MAY is that the implementor / deployer needs a good excuse to not implement / employ a SHOULD. That's not the same as IGNORE. But that's a big difference. I think some people are being cavalier about the good excuse part, and that's where I have a problem. RFC2119 is not unclear on this point. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Murray S. Kucherawy wrote: The only difference between SHOULD and MAY is that the implementor / deployer needs a good excuse to not implement / employ a SHOULD. That's not the same as IGNORE. But that's a big difference. I think some people are being cavalier about the good excuse part, and that's where I have a problem. RFC2119 is not unclear on this point. Correct again, it is not unclear. It says it very clear. I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation: SHOULD, RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. There is no possibility to interpret SHOULD as nothing else as an optional implementation and thus can be ignored. Of course, the presumptions are: - Faith in your engineering peers, - Due Diligence decision to decide to ignore it, and - understanding if it was implemented, it could be ignored by consumers. If that is not enough, we have a huge deployment history where SHOULDs was ignored and implemented as an option for operators, and we have history where a SHOULD was changed to a MUST and it caused problems. If your interpretation was correct, this change would not have been necessary. IMV, the evidence is quite clear that SHOULD has no MUST-IMPLEMENT concept and never had. If people read it that way, it probably did not cause a problem. So no big deal. But if they expected others to MUST-IMPLEMENT a SHOULD and broke down because of that expectation, then I suggest they didn't read RFC2119 correctly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
Hi, Sometimes the drafts says that something SHOULD be done, but the justification is unclear to the reader, so it can be difficult to interpret the meaning correctly. So, I think it would cause less confusion if drafts made a better job of describing WHY something is a SHOULD, or MUST. Something like SHOULDBECAUSE :) Regards, Christer From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Hector [sant9...@gmail.com] Sent: Wednesday, August 31, 2011 10:07 PM Cc: IETF discussion list Subject: Re: 2119bis Murray S. Kucherawy wrote: The only difference between SHOULD and MAY is that the implementor / deployer needs a good excuse to not implement / employ a SHOULD. That's not the same as IGNORE. But that's a big difference. I think some people are being cavalier about the good excuse part, and that's where I have a problem. RFC2119 is not unclear on this point. Correct again, it is not unclear. It says it very clear. I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation: SHOULD, RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. There is no possibility to interpret SHOULD as nothing else as an optional implementation and thus can be ignored. Of course, the presumptions are: - Faith in your engineering peers, - Due Diligence decision to decide to ignore it, and - understanding if it was implemented, it could be ignored by consumers. If that is not enough, we have a huge deployment history where SHOULDs was ignored and implemented as an option for operators, and we have history where a SHOULD was changed to a MUST and it caused problems. If your interpretation was correct, this change would not have been necessary. IMV, the evidence is quite clear that SHOULD has no MUST-IMPLEMENT concept and never had. If people read it that way, it probably did not cause a problem. So no big deal. But if they expected others to MUST-IMPLEMENT a SHOULD and broke down because of that expectation, then I suggest they didn't read RFC2119 correctly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Randy Presuhn wrote: Murray stated: This sentence is self-contradictory. SHOULD is, by definition, not OPTIONAL. I disagree with the claim that there is a contradiction there, but I also think IGNORE is incorrect. That's a good point because if a good-faith decision was made to not implement a SHOULD, then there was no intent to ignore, there was no negligence and there is technical or protocol liability in that decision. -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 31, 2011, at 3:07 PM, Hector wrote: Murray S. Kucherawy wrote: The only difference between SHOULD and MAY is that the implementor / deployer needs a good excuse to not implement / employ a SHOULD. That's not the same as IGNORE. But that's a big difference. I think some people are being cavalier about the good excuse part, and that's where I have a problem. RFC2119 is not unclear on this point. Correct again, it is not unclear. It says it very clear. I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation: SHOULD, RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding. Adding additional text and documents inherently increases the burden on readers. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 08/31/2011 11:14 AM, Keith Moore wrote: When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding. Adding additional text and documents inherently increases the burden on readers. This seems pretty clear to me, and perhaps it's been the only clear thing in this discussion so far. 2119 was published in 1997 and aside from a typo (that does not seem to have caused confusion, for whatever that's worth) there haven't been a lot of complaints. Thumbs up on correcting typos, and both thumbs down on using the process of correcting a typo to reopen a SHOULD/MAY rathole, or even a NOT RECOMMENDED rathole. I'd rather let the typo stand. I don't think the putative benefits of revising 2119 justify the effort. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Keith Moore wrote: Correct again, it is not unclear. It says it very clear. I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation: SHOULD, RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding. Adding additional text and documents inherently increases the burden on readers. I'm having a hard time understanding why you continue to work on the basis that people fail to read essentially implying stupidity in the process. The Point being that if Tony's I-D has it as it was shown above, then it would be incorrect too in its understanding of RFC2119 because non-normative words are clearly concepts related to a non-required mandate. I suggest we have a huge history of protocol deployment where SHOULDs are ignored and SHOULDs implemented as an option, but in addition, the idea of the possibility that isn't presented as an option to operators was solely an implementator decision to enforce it and not make an optional feature for the operator to play with. It is really up to the author to describe what the intent is for a particular SHOULD because its not an universal idea that SHOULD is always implemented. Anyway, I think that's it for me on this. :) -- HLS ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: you can't force people to write well, was 2119bis
When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding. Adding additional text and documents inherently increases the burden on readers. Having done my share of writing, and also having hired people to write for me, I entirely agree. You can't force people to write well by adding ever more detailed and nitpicky rules. If the problem is that RFCs aren't clear, or that they use words in misleading ways, the burden should be on the WGs that produce the drafts to fix them so that they say what they're trying to say better. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On Aug 31, 2011, at 3:44 PM, Hector wrote: I'm having a hard time understanding why you continue to work on the basis that people fail to read essentially implying stupidity in the process. I work on the basis of fail to read because I've seen countless examples of it. And stupidity is not the same thing as lack of diligence. The Point being that if Tony's I-D has it as it was shown above, then it would be incorrect too in its understanding of RFC2119 because non-normative words are clearly concepts related to a non-required mandate. As far as I'm concerned, Tony's I-D is a nonstarter, and therefore irrelevant. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 2119bis
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Keith Moore Sent: Wednesday, August 31, 2011 12:51 PM To: Hector Cc: IETF discussion list Subject: Re: 2119bis On Aug 31, 2011, at 3:44 PM, Hector wrote: I'm having a hard time understanding why you continue to work on the basis that people fail to read essentially implying stupidity in the process. I work on the basis of fail to read because I've seen countless examples of it. And stupidity is not the same thing as lack of diligence. Ditto. And I also see a lot of creative interpretation. There's little we can do to thwart any of those problems; some people read what they want to read and do so in a vacuum. As far as I'm concerned, Tony's I-D is a nonstarter, and therefore irrelevant. I certainly agree that it's irrelevant to this discussion, plus it's only an I-D at this point anyway. We're talking about a published BCP here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 8/31/2011 3:14 PM, Keith Moore wrote: On Aug 31, 2011, at 3:07 PM, Hector wrote: RFC2119 is not unclear on this point. Correct again, it is not unclear. It says it very clear. I don't know why you wish to ignore Tony's I-D reinforcing this concept and optional implementation: SHOULD, RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. When the text in 2119 is already clearly written, but people fail to read it, I don't understand why adding more text in yet another document is likely to improve understanding. Adding additional text and documents inherently increases the burden on readers. context check. The purview of the non2119-nonkeywords doc is to suggest wording to use when *NOT* in the 2119 context. Perhaps the paragraph in the non2119-nonkeywords docs should read: *instead* of SHOULD or RECOMMENDED: The words ought, encouraged and suggest strongly can be used to connote something that is strongly urged. Tony ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
On 08/31/2011 12:09 PM, Tony Hansen wrote: context check. The purview of the non2119-nonkeywords doc is to suggest wording to use when *NOT* in the 2119 context. Personally, I'm okay with an ambiguous, informal may. I'm even okay with an ambiguous, informal must. I'm less okay with the IETF publishing a thesaurus. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
Keith Moore wrote: The Point being that if Tony's I-D has it as it was shown above, then it would be incorrect too in its understanding of RFC2119 because the non-normative words are clearly concepts related to a non-required mandate. As far as I'm concerned, Tony's I-D is a nonstarter, and therefore irrelevant. Oh the irony in the Failure to Read labeling category, the art of selective synergism, :) if only to acknowledge the rich IETF-MAN-YEARS behind the production of this I-D and its obvious relationship to RFC2119 and any future consideration for a RFC2119BIS. :) Thanks ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
If the author is disciplined enough to use them in that manner, sure. I haven't come across many. On 01/09/2011, at 1:43 AM, Jari Arkko wrote: Unless of course one considers us the Protocol Nanny's(tm) - if do not do a SHOULD, we will send you to bed without your treacle! I.e., there IS NO DISTINCTION BETWEEN A BARE SHOULD AND A MAY. Of course there is. Its the distinction between - Qualified SHOULD) Here lie dragons. Take the recommended route, unless you know how to fight them. Unqualified SHOULD) Here lie some dangers. Check with someone who knows, or take the recommended route. MAY) Here's an area. You could go there. Of course, the first and last pieces of text are preferred. But sometimes no one was brave enough to explore the area, so we don't actually know what dangers there are, they cannot be listed. Jari -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 2119bis
This highlights an interesting issue as an RFC goes from PS to IS. I would offer that most SHOULDs in a document will, if there are real implementations out there, migrate to MUST or MUST NOT. On Aug 31, 2011, at 9:57 AM, hector wrote: I think you are speaking of long term operations where an SHOULD is so widely adopted, it inherently because a MUST have in all new implementations. So that vain, sure, eventually the better options naturally become part of the protocol to the extent the options might be even remove to simplify things. We also have the opposite where a SHOULD is implemented but no one users it so eventually, it may be remove as an option. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-behave-v4v6-bih-06.txt (Dual Stack Hosts Using Bump-in-the-Host (BIH)) to Proposed Standard
The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Dual Stack Hosts Using Bump-in-the-Host (BIH)' draft-ietf-behave-v4v6-bih-06.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 substantive comments to the i...@ietf.org mailing lists by 2011-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol translation mechanism that allows a class of IPv4-only applications that work through NATs to communicate with IPv6-only peers. The host on which applications are running may be connected to IPv6-only or dual-stack access networks. BIH hides IPv6 and makes the IPv4-only applications think they are talking with IPv4 peers by local synthesis of IPv4 addresses. This draft obsoletes RFC 2767 and RFC 3338. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Call for Comment on Report from the 'Interconnecting Smart Objects with the Internet' Workshop
This is an IETF-wide Call for Comment on Report from the 'Interconnecting Smart Objects with the Internet' Workshop. The document is available for inspection here: http://tools.ietf.org/html/draft-iab-smart-object-workshop The Call for Comment will last until October 7, 2011. Please send comments to i...@iab.org, or submit them via TRAC (see below). The document is being considered for publication as an Informational RFC within the IAB stream. As noted in RFC 4845 Section 2, workshop reports are meant to represent a faithful report of the proceedings, and do not necessarily represent the opinion of the IAB: For certain documents, it may not be appropriate for the IAB to take responsibility for technical correctness. For example, where the IAB has sponsored a workshop in which not all the participants were members of the IAB and/or not all the members of the IAB were present, approval by the IAB of a report of the workshop is used only to assert that the report is a faithful report of the proceedings of the workshop and that the matter is of interest to the community. Submitting Comments via TRAC 1. To submit an issue in TRAC, you first need to login to the IAB site on the tools server: http://tools.ietf.org/wg/iab/ http://tools.ietf.org/wg/iab/trac/login trac/login 2. If you don't already have a login ID, you can obtain one by navigating to this site: http:// http://trac.tools.ietf.org/newlogin trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http:// http://trac.tools.ietf.org/wg/iab/trac/newticket trac.tools.ietf.org/wg/iab/trac/newticket 4. When opening an issue: a. The Type: field should be set to defect for an issue with the current document text, or enhancement for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically minor or trivial. c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing the issue on. e. The Version: field should be set to 1.0. f.The Severity: field should be set to based on the status of the document (e.g. In WG Last Call for a document in IAB last call) g.The Keywords: and CC: fields can be left blank unless inspiration seizes you. h. The Assign To: field is generally filled in with the email address of the editor. 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select I have files to attach to this ticket. 6. If you want to preview your Issue, click on the Preview button. When you're ready to submit the issue, click on the Create Ticket button. 7. If you want to update an issue, go to the View Tickets page: http:// http://trac.tools.ietf.org/wg/iab/trac/report/1 trac.tools.ietf.org/wg/iab/trac/report/1 Click on the ticket # you want to update, and then modify the ticket fields as required ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6309 on IANA Rules for MIKEY (Multimedia Internet KEYing)
A new Request for Comments is now available in online RFC libraries. RFC 6309 Title: IANA Rules for MIKEY (Multimedia Internet KEYing) Author: J. Arkko, A. Keranen, J. Mattsson Status: Standards Track Stream: IETF Date: August 2011 Mailbox:jari.ar...@piuha.net, ari.kera...@ericsson.com, john.matts...@ericsson.com Pages: 6 Characters: 10706 Obsoletes: RFC4909 Updates:RFC3830, RFC4563, RFC5410, RFC6043 I-D Tag:draft-arkko-mikey-iana-01.txt URL:http://www.rfc-editor.org/rfc/rfc6309.txt This document clarifies and relaxes the IANA rules for Multimedia Internet KEYing (MIKEY). This document updates RFCs 3830, 4563, 5410, and 6043; it obsoletes RFC 4909. [STANDARDS-TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
BCP 165, RFC 6335 on Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry
A new Request for Comments is now available in online RFC libraries. BCP 165 RFC 6335 Title: Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Author: M. Cotton, L. Eggert, J. Touch, M. Westerlund, S. Cheshire Status: Best Current Practice Stream: IETF Date: August 2011 Mailbox:michelle.cot...@icann.org, lars.egg...@nokia.com, to...@isi.edu, magnus.westerl...@ericsson.com, chesh...@apple.com Pages: 33 Characters: 79088 Updates:RFC2780, RFC2782, RFC3828, RFC4340, RFC4960, RFC5595 See Also: BCP0165 I-D Tag:draft-ietf-tsvwg-iana-ports-10.txt URL:http://www.rfc-editor.org/rfc/rfc6335.txt This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice. This document is a product of the Transport Area Working Group Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6366 on Requirements for an Internet Audio Codec
A new Request for Comments is now available in online RFC libraries. RFC 6366 Title: Requirements for an Internet Audio Codec Author: J. Valin, K. Vos Status: Informational Stream: IETF Date: August 2011 Mailbox:jmva...@jmvalin.ca, koen@skype.net Pages: 17 Characters: 39355 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-codec-requirements-05.txt URL:http://www.rfc-editor.org/rfc/rfc6366.txt This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet-loss robustness, as well as other desirable properties. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Wideband Audio Codec Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'Moving RFC 4693 to Historic' to Informational RFC (draft-yevstifeyev-ion-report-07.txt)
The IESG has approved the following document: - 'Moving RFC 4693 to Historic' (draft-yevstifeyev-ion-report-07.txt) as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-yevstifeyev-ion-report/ Technical Summary This document requests RFC 4693 [RFC4693] to be moved to Historic status. It also obsoletes that document. Working Group Summary This document is not the product of any IETF WG. Issues covered by this document have been widely discussed on the IETF mailing list. Document Quality The document was reviewed by Russ Housley for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'IETF Operational Notes' (RFC 4693) to Historic RFC
The IESG has approved the following document: - 'IETF Operational Notes' RFC 4693 as a Historic RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this RFC is: https://datatracker.ietf.org/doc/rfc4693/ Technical Summary This document describes a new document series (IONs) intended for use as a repository for IETF operations documents, which should be more ephemeral than RFCs, but more referenceable than internet-drafts, and with more clear handling procedures than a random Web page. It proposes to establish this series as an RFC 3933 process experiment. Working Group Summary During IETF Last Call, concern was expressed that ION documents must not be used to change matters of IETF process that require IETF consensus. This experiment doesn't change the IESG's authority, but it creates a systematic way to document procedural decisions. Text was added to clarify that IONs cannot override BCPs. The disposition of ION documents if the experiment is deemed a failure was clarified, as were other points questioned during Last Call. Finally, the IESG needs to affirm its support for the experiment. Protocol Quality Reviewed by Brian Carpenter ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6357 on Design Considerations for Session Initiation Protocol (SIP) Overload Control
A new Request for Comments is now available in online RFC libraries. RFC 6357 Title: Design Considerations for Session Initiation Protocol (SIP) Overload Control Author: V. Hilt, E. Noel, C. Shen, A. Abdelal Status: Informational Stream: IETF Date: August 2011 Mailbox:volker.h...@alcatel-lucent.com, eric.n...@att.com, char...@cs.columbia.edu, aabde...@sonusnet.com Pages: 25 Characters: 64252 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-soc-overload-design-08.txt URL:http://www.rfc-editor.org/rfc/rfc6357.txt Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the SIP Overload Control Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6350 on vCard Format Specification
A new Request for Comments is now available in online RFC libraries. RFC 6350 Title: vCard Format Specification Author: S. Perreault Status: Standards Track Stream: IETF Date: August 2011 Mailbox:simon.perrea...@viagenie.ca Pages: 74 Characters: 139895 Obsoletes: RFC2425, RFC2426, RFC4770 Updates:RFC2739 I-D Tag:draft-ietf-vcarddav-vcardrev-22.txt URL:http://www.rfc-editor.org/rfc/rfc6350.txt This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.). This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739. [STANDARDS-TRACK] This document is a product of the vCard and CardDAV Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6351 on xCard: vCard XML Representation
A new Request for Comments is now available in online RFC libraries. RFC 6351 Title: xCard: vCard XML Representation Author: S. Perreault Status: Standards Track Stream: IETF Date: August 2011 Mailbox:simon.perrea...@viagenie.ca Pages: 22 Characters: 34086 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-vcarddav-vcardxml-11.txt URL:http://www.rfc-editor.org/rfc/rfc6351.txt This document defines the XML schema of the vCard data format. [STANDARDS-TRACK] This document is a product of the vCard and CardDAV Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6352 on CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)
A new Request for Comments is now available in online RFC libraries. RFC 6352 Title: CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV) Author: C. Daboo Status: Standards Track Stream: IETF Date: August 2011 Mailbox:cy...@daboo.name Pages: 48 Characters: 98548 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-vcarddav-carddav-10.txt URL:http://www.rfc-editor.org/rfc/rfc6352.txt This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing contact information based on the vCard format. [STANDARDS-TRACK] This document is a product of the vCard and CardDAV Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
