Re: Call for review of proposed update to ID-Checklist
IETF Chair wrote: From the discussion just prior to the recent appeal by John Klensin, it was clear that the guidance regarding example domain names in IETF documents provided in the ID-Checklist needed to be updated. This point was emphasized further during the discussion of the Klensin appeal. Proposed text is now available. Many thanks to Bert Wijnen for continuing to edit the document. The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The proposed text can be obtained via http://www.ietf.org/Draft-ID-Checklist.html 6 days later, the URL gives me an object not found. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
I beleiev that the IESG approved the 1.8 version for which Russ called for review on the IETF list. Anyway, the 1,8 version (with change) is online as http://www.ietf.org/ID-Checklist.html Meanwhile I am working on revision 1.9 and I am making changes as I have been posting to the ietf list over the last 4-5 days. I am still discussion a few other changes (mainly with IESG) before this one will go online. Bert - Original Message - From: Harald Alvestrand [EMAIL PROTECTED] To: ietf@ietf.org Sent: Wednesday, August 13, 2008 11:55 AM Subject: Re: Call for review of proposed update to ID-Checklist IETF Chair wrote: From the discussion just prior to the recent appeal by John Klensin, it was clear that the guidance regarding example domain names in IETF documents provided in the ID-Checklist needed to be updated. This point was emphasized further during the discussion of the Klensin appeal. Proposed text is now available. Many thanks to Bert Wijnen for continuing to edit the document. The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The proposed text can be obtained via http://www.ietf.org/Draft-ID-Checklist.html 6 days later, the URL gives me an object not found. ___ 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: Call for review of proposed update to ID-Checklist
Bert Wijnen (IETF) wrote: - Original Message - From: Dave Crocker [EMAIL PROTECTED] RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says what isn't. The proble we saw in the IESG (when we started ID_Checklist) was that we saw A LOT OF I-Ds that requested publication and that DID HAVE SPECIFIC IPR claims. So we wanted to make it clear to people that such is NOT TO BE DONE. Just saying that RFC3979 text was to be used seemed not to get through! Bert, One of the likely reasons it didn't get through is that the IESG was inventing a new rule. A good rule, in my opinion, but a new one, since I think that redundancy of specifications invites disparity. To say that something must be in one place is very different from saying that it may not (also) be in another. So the IESG a) invented a more strict, formal rule than had existed before, and b) only documented it in the Checklist. Consider both of these points, please, in terms of your earlier claim: Bert Wijnen (IETF) wrote: I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes are described in formally approved BCP documents. While it is vastly more convenient, for the IESG, to have it take initiative and decide on its own to make a more strict rule and issue it in a document that does not go through public vetting, it isn't the way things are supposed to be done in the IETF. If the IESG is now responsible for inventing IETF policy, that ought to be acknowledged and documented explicitly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Bert Wijnen (IETF) wrote: - Original Message - From: Dave Crocker [EMAIL PROTECTED] RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says what isn't. The proble we saw in the IESG (when we started ID_Checklist) was that we saw A LOT OF I-Ds that requested publication and that DID HAVE SPECIFIC IPR claims. So we wanted to make it clear to people that such is NOT TO BE DONE. Just saying that RFC3979 text was to be used seemed not to get through! Bert, One of the likely reasons it didn't get through is that the IESG was inventing a new rule. A good rule, in my opinion, but a new one, since I think that redundancy of specifications invites disparity. To say that something must be in one place is very different from saying that it may not (also) be in another. So the IESG a) invented a more strict, formal rule than had existed before, and b) only documented it in the Checklist. Consider both of these points, please, in terms of your earlier claim: Bert Wijnen (IETF) wrote: I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes are described in formally approved BCP documents. While it is vastly more convenient, for the IESG, to have it take initiative and decide on its own to make a more strict rule and issue it in a document that does not go through public vetting, it isn't the way things are supposed to be done in the IETF. If the IESG is now responsible for inventing IETF policy, that ought to be acknowledged and documented explicitly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Hi, Dave, While it is vastly more convenient, for the IESG, to have it take initiative and decide on its own to make a more strict rule and issue it in a document that does not go through public vetting, it isn't the way things are supposed to be done in the IETF. Just to ring one of the changes here... I'm actually OK with the process that Dave is not OK with, because I'm assuming that public vetting can also be retroactive - as long as the IESG announces rules publicly, I trust the community to point out problematic rules with great enthusiasm, and trust that the IESG will not go into because we said so mode when someone does point out that a new rule is problematic. If my trust is misplaced, we have bigger problems than process changes, I think. If the IESG is now responsible for inventing IETF policy, that ought to be acknowledged and documented explicitly. One of the many contortions we went through on process change was trying to distinguish between policy and procedure. Our current(?) process BCPs don't make this distinction well. I'm totally good with the IESG inventing IETF *procedures*, and that's what I think most of the ID checklist is. I would not be good with the IESG inventing IETF *policy* without community involvement, but that's not what I think is on the block. Unannounced rules (double SECRET probation) would be a problem, but I don't see anyone arguing in favor of undocumented late-surprise barriers. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Date:Wed, 13 Aug 2008 13:13:46 -0500 From:Spencer Dawkins [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | I'm actually OK with the process that Dave is not OK with, because I'm | assuming that public vetting can also be retroactive - as long as the | IESG announces rules publicly, I'm not. The big difference is what consensus is needed to achieve what. In the cases of even mildly controversial changes, and isn't everything, the question is whether it requires (rough) consensus to make the change, or requires (rough) consensus to overturn the change. Personally, I believe we need to achieve some form of agreement before any changes, and not fall into the trap of: it's done, and some (enough) people believe it is OK, so there's no consensus to not do it. For what it's worth, on the issue that has been under discussion, I see no harm at all in having documents list IPR claims they're aware of, so long as they don't pretend to claim that those are the only possible IPR claims. For example, in the early 90's, it would have been entirely reasonable for a doc proposing use of RSA public key technology to note the patent status, in the doc. Requiring that such information be only on the web page is just plain absurd. So, for example, in this case, I wouldn't like anything to be pretending to say that IPR claims are not allowed in docs, unless we first achieve a consensus doc that says that. Similarly no claims that only the domain names in 2606 can be (even just usually used as example in docs, unless we have a consensus doc that says that.) I have no problem with pointing out things that are common (or even just seen more than once) errors, that no-one would rationally ever do deliberately (like using ABNF, or anything else, and failing to reference its definition) - that is, helping people remember to check for the things that are easy to overlook. But no new rules, for everything that isn't just noise, you need to be able to cite the precise text in some standards track RFC, or BCP that justifies exactly what you're planning on requiring. No matter how rational you, or anyone, believes the proposed rule is. If that doesn't exist, it needs to be made to happen, first. kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
I am working on a solution for this with the Secretariat. It is one aspect of the web site redesign project. I do not think that an Internet-Draft is needed. Russ At 11:40 AM 8/9/2008, Bert Wijnen \(IETF\) wrote: (1) Archive older versions in a plain text format as forI-Ds (for use with various IETF tools working on I-Ds) I can generate I-Ds if that helps. I can even submit those. Russ, do you want me to do that? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Russ Housley wrote: I do not think that an Internet-Draft is needed. The source is already a variant of xml2rfc input, from there it's easy to arrive at plain text output for the ordinary diff tools. Adding version numbers for archiving working with the diff tool could be as simple as use name-NN.txt for version NN. Frank Russ At 11:40 AM 8/9/2008, Bert Wijnen \(IETF\) wrote: (1) Archive older versions in a plain text format as forI-Ds (for use with various IETF tools working on I-Ds) I can generate I-Ds if that helps. I can even submit those. Russ, do you want me to do that? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Hi, On 2008-8-11, at 2:32, ext John C Klensin wrote: --On Sunday, August 10, 2008 6:03 PM +0200 Julian Reschke [EMAIL PROTECTED] wrote: - check that if the document obsoletes or updates another document, that one appear in the references section, and make sure that the document actually says what's going on with respect to the other documents (such as Normative Changes from RFC ) Of course, if one does this, the automated nits checker complains about a reference to an obsolete RFC :-( you only get an (incorrect) warning if the referenced RFC has _already_ been obsoleted by another document. For the normal case - document B obsoleting document A - there is no warning when B references A, because A's status changes to obsolete only after B is IESG-approved. And as Brian correctly points out, idnits warnings/errors are sometimes bogus, which is where think mode comes in. Lars ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Hi John,
On 2008-08-11 01:46 John C Klensin said the following:
--On Monday, August 11, 2008 12:54 AM +0200 Henrik Levkowetz
[EMAIL PROTECTED] wrote:
...
If you're referring to idnits, it does no test the number of
authors
in any way or form. I haven't checked whether the current,
soon-to
be replaced submission tool tries to check this, but idnits
does most emphatically not.
I apologize to idnits. I have seen documents rejected by some
process because they had more than five authors, but I don't
remember whether it was the submission tool or someone
overzealous at the (present or past) Secretariat.
Ok. Which leaves establishing the desired behaviour of the draft
submission mechanisms.
My personal viewpoint is that it would be inappropriate to strictly
enforce a limit of 5 authors. The use of 'should' in section 2.2,
item 2 of the current document ('There should not be more than 5
authors/editors') seems appropriate given the current RFC Editor
policy, and tools-wise this would then be implemented as a note or
warning at the most, but should never cause a refusal to accept a draft
submission.
Henrik
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ID desires and TOOLS stuff [was: Re: Call for review of proposed update to ID-Checklist]
All, PLEASE change the subject line if you change the topic to be discussed. I do NOT think that the below has anything to do with my editing (or the Call for review) of the ID_Checklist. The below list seems like a new set of desires that some people have w.r.t. Internet Drafts (and resulting RFCs). The listed items may all be things for authors/editors to consider. They may also be things that some TOOL could possibly detect and warn about. But they are not (and in my view should not be) topics of the ID_Checklist. So I am not considering the below (and follow up discussions) as part of my current editing cycle of ID-Checklist. Bert Editor for ID_Checklist. - Original Message - From: Julian Reschke [EMAIL PROTECTED] To: ietf@ietf.org Sent: Sunday, August 10, 2008 6:03 PM Subject: Re: Call for review of proposed update to ID-Checklist Hi, things I'd like to see done in IDs more consistently: In an Editorial Note on the front page: - state on which mailing list discussions should take place (include mailing list archive and subscription links) - point to issues lists when available References: - check that if the document obsoletes or updates another document, that one appear in the references section, and make sure that the document actually says what's going on with respect to the other documents (such as Normative Changes from RFC ) - use symbolic references - when quoting RFCs, consider calling out a specific section in the referenced document (it's preferable that the author does it once, instead of the readers having to figure it out; also, it helps revising the document when the referenced document was revised) Code: - when using xml2rfc, add type parameters to artwork so that things like ABNF can be automatically extracted and checked Versioning: - (this probably is controversial :-) - keep an appendix that gives a short overview of what changed compared to previous drafts BR, Julian ___ 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: Call for review of proposed update to ID-Checklist
I personally very much like this statement from Brian Carpenter: I'd like to say that both as an author and as a reviewer, I have always found both the ID checklist and the IDnits checker to be of immense pragmatic value. Obviously, if the checklist or the checker complains about something that isn't obviously a bug, the author, shepherd, AD or reviewer will have to enter think mode or even negotiate mode. I agree that it's a good idea to be clear about that. Brian I am checking with the IESG if they also agree with that Bert Editor for the ID_Checklist ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Henrik Levkowetz wrote:
...
Ok. Which leaves establishing the desired behaviour of the draft
submission mechanisms.
My personal viewpoint is that it would be inappropriate to strictly
enforce a limit of 5 authors. The use of 'should' in section 2.2,
item 2 of the current document ('There should not be more than 5
authors/editors') seems appropriate given the current RFC Editor
policy, and tools-wise this would then be implemented as a note or
warning at the most, but should never cause a refusal to accept a draft
submission.
...
+1
BR, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
inline - Original Message - From: Dave Crocker [EMAIL PROTECTED] To: Bert Wijnen (IETF) [EMAIL PROTECTED] Cc: Brian E Carpenter [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] Sent: Sunday, August 10, 2008 6:14 PM Subject: Re: Call for review of proposed update to ID-Checklist Bert, Bert Wijnen (IETF) wrote: As you all can see, the ID-Checklist in fact DOES refer to the rfc2223bis at many places. Yes, but... 1. draft-rfc-editor-rfc2223bis is expired. I know. and the RFC-Editor has givem me a pointer to http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt which replaces rfc2223bis and this will be in the next revision (1.9) as I had already stated in an earlier posting. 2. While the citations that are included mostly do include the specific section to look in, some do not. (See the first example, below.) Hence, some of the citations are too broad. 3. Much of the document's direction is offered without citation. From the July 4 http://www.ietf.org/ID-Checklist.html... 2.2. Required sections - all I-Ds ... List of authors/editors There should not be more than 5 authors/editors (see http://www.rfc-editor.org/policy.html) The Policy document is about 10 pages long. I thought the specific information would be in Authors vs. Contributors but it wasn't. One has to search awhile to find Item #1 under an interestingly named section Author Overload, to find the basis for the should in the checklist. And note that the normative should language in the Checklist, here, might be considered stronger than what is actually said in the RFC Editor's policy document. (One can debate this, but then, that debate is exactly what we ought to have, based on hard data like this. My own opinion is that the should is appropriate here, in terms of actual practice, and it's long been what I advise folk writing drafts.) I can change the pointer to http://www.rfc-editor.org/policy.html#policy.authlist if that helps. Again, a lower case should is certainly not nromative in the sense you seem to interpret it. Let me also say that this point became part of the ID_Checklist after the RFC-Editor was exposed to I-Ds that had 15 or so people on the front page and then when the AUTH48 phase was entered it was enourmously time-comsuming and nearly impossible to reach (and get a response) from all the umpteen people on the front-page. 1. Introduction ... As a suggestion for productivity improvement, it is strongly RECOMMENDED to use XML2RFC The capitalization appears intended to offer essentially normative guidance but, of course, that's probably not what is meant. wow... some of you seem to jump to RED-Alert when you see a capitalized term. It is there as strong advise. I personally have no problem changing that to lower case. I am checking with IESG on that. 2.2. Required sections - all I-Ds The following are REQUIRED sections in all Internet-Drafts: What is the basis for asserting that this list is *required* (and, by the way, is required meant as a normative term; the caps suggest yes)? Again, please note that I'm not claiming the list is wrong, but that its provenance is absent. So your view that Our processes are described in formally approved BCP documents might be at risk. I can live with making it lowercase (I am checking with IESG). The first MUST in point 1 in sect 2.2 is certainly based on a real thing. But even if we make all the capitalized MUST/SHOULD/RECOMMENDED lower case, even then the ID_Checklist is very usefull. 3. Content issues ... B. no citations While I happen to think this is quite good advice, I have no idea a) where it comes from, or b) whether it is guidance or requirement. comes from RFC-Editor. See last para in http://www.rfc-editor.org/policy.html#policy.abstract I can add the pointer if that helps. The one before it, Should be meaningful to someone not versed in the technology also lacks basis. Further, as guidance, it's reasonable, but entirely lacking in substance to help an author know how to satisfy it. It came from rfc2223bis or at least how I (and the IESG at the time of first ID_Checklist revision) interpreted: The Abstract section should provide a concise and comprehensive overview of the purpose and contents of the entire document, to give a technically knowledgeable reader a general overview of the function of the document. In addition to its function in the RFC itself, the Abstract section text will appear in publication announcements and in the online index of RFCs. I think the intent is that the reader of an abstract of course should be somewhat technically knowledgebale, but that he/she should not have to be an expert in the technology described in the document. I.e. the abstract is intended for technically knowledgeable people that have not participated in the production of the RFC (or the technology described in the RFC).
Re: Call for review of proposed update to ID-Checklist
Henrik Levkowetz wrote:
My personal viewpoint is that it would be inappropriate to strictly
enforce a limit of 5 authors. The use of 'should' in section 2.2,
item 2 of the current document ('There should not be more than 5
authors/editors') seems appropriate given the current RFC Editor
policy, and tools-wise this would then be implemented as a note or
warning at the most, but should never cause a refusal to accept a draft
submission.
1. enforce a limit moves a should to a must.
2. The RFC Editor's policy document does not use language that is as strong as a
should.
Hence, the ID Checklist is making a normative statement stronger than the RFC
Editor and the proposal for the checker to 'enforce' is even stronger than that.
By contrast, last sentence suggesting simply printing a notice that there are
more authors than preferred captures the RFC Editor policy's statement.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Bert Wijnen (IETF) wrote: I can change the pointer to http://www.rfc-editor.org/policy.html#policy.authlist if that helps. It gets the reader to the right sections, so yes, it helps quite a bit. Again, a lower case should is certainly not nromative in the sense you This semantic distinction between upper and lower case that folks keep making is not supported by RFC 2119. The RFC's these words are often capitalized does not mean these words must always be capitalized in order to mean that they are normative. Case distinction for semantics also goes against normal rules for English. seem to interpret it. Let me also say that this point became part of the ID_Checklist after the RFC-Editor was exposed to I-Ds that had 15 or so people on the front page and then when the AUTH48 phase was entered it was enourmously time-comsuming and nearly impossible to reach (and get a response) from all the umpteen people on the front-page. And yet the RFC Editor has not yet stated that this is a hard limit, nor has the IETF consensus process imposed it. So it makes no sense to have the Checklist mechanism enforce such a limit. What we also have here is the usual debate problem with citing an extreme outlier (15 authors) as demonstrating a pervasive problem, while ignoring reasonable exceptions (6 authors) that can and do occur. We really need to get out of the habit of attempting to stop (or impose) change by citing only one side of the issue -- and and extreme version of that side. There are problems with change and with no change. The choice between them should consider the *balance* of cost and benefit of the change and the cost and benefit of no change. 1. Introduction ... As a suggestion for productivity improvement, it is strongly RECOMMENDED to use XML2RFC The capitalization appears intended to offer essentially normative guidance but, of course, that's probably not what is meant. wow... some of you seem to jump to RED-Alert when you see a capitalized term. Bert, now I am completely confused. Above you stated lower case 'should' is certainly not normative and yet here you take exception to the interpretation of a capitalized term as implying that it is normative. It is there as strong advise. I personally have no problem changing that to lower case. I am checking with IESG on that. How is the reader to know what is required and what is merely advise? We are in the specification business. Where is the distinction specified? I can live with making it lowercase (I am checking with IESG). The first MUST in point 1 in sect 2.2 is certainly based on a real thing. But even if we make all the capitalized MUST/SHOULD/RECOMMENDED lower case, even then the ID_Checklist is very usefull. I don't recall anyone suggesting that the checklist or the checker weren't useful. I thought that the discussion was how to make the *more* useful. 3. Content issues ... B. no citations While I happen to think this is quite good advice, I have no idea a) where it comes from, or b) whether it is guidance or requirement. comes from RFC-Editor. See last para in http://www.rfc-editor.org/policy.html#policy.abstract I can add the pointer if that helps. Yup. Tnx. The one before it, Should be meaningful to someone not versed in the technology also lacks basis. It came from rfc2223bis or at least how I (and the IESG at the time of first ID_Checklist revision) interpreted: The important point is that by having a citation, then we get to compare the authoritative statement with the synthesis that made it into the checklist. For the moment, it is really secondary as to whether that synthesis retained or lost the useful information. (FWIW, in terms of offering anything useful for the user of the Checklist, I think it lost it. Note the massive difference in detailed guidance, such as for 2.1 Formatting, versus this entirely generic Should be meaningful to someone not versed in the technology. While not versed in the technology is a somewhat useful tidbit, the Checklist text provides none of the affirmative, semantic content guidance in the RFC Editor document.) Specific IPR (e.g., patent claims terms) must not be in an RFC The must is interesting. What BCP documents this (entirely reasonable, IMO) requirement? Does not point 4 4. Specific IPR (e.g., patent claims terms) must not be in an RFC (or Internet-Draft). Any claims must go to the IETF IPR web page and notice that there is some IPR claim. The mandatory IPR Notice from [RFC3979] (Bradner, S., Intellectual Property Rights in IETF Technology, March 2005.) section 5 points readers to the IETF IPR web page. clealry point you to the basis (RFC3979) ??? The point was/is that some people put one specific IPR claim in the RFC. And such is useless, after the RFC is Bert, once again, I'm not suggesting the guidance is wrong, but that it is without substantiation. It asserts a *requirement*
Re: Call for review of proposed update to ID-Checklist
Hi Dave,
On 2008-08-11 16:35 Dave Crocker said the following:
Henrik Levkowetz wrote:
My personal viewpoint is that it would be inappropriate to strictly
enforce a limit of 5 authors. The use of 'should' in section 2.2,
item 2 of the current document ('There should not be more than 5
authors/editors') seems appropriate given the current RFC Editor
policy, and tools-wise this would then be implemented as a note or
warning at the most, but should never cause a refusal to accept a draft
submission.
1. enforce a limit moves a should to a must.
Yes, but nobody is arguing that this should be done...
2. The RFC Editor's policy document does not use language that is as strong as a
should.
Hence, the ID Checklist is making a normative statement stronger than the RFC
Editor and the proposal for the checker to 'enforce' is even stronger than that.
Repeating myself in a new context: Umm??
I didn't propose that the checker enforce such a limit, and I'm not aware of
anyone else proposing it, thus I don't understand why you seem to argue against
a proposal nobody seems to have made. Have I misunderstood what you seem to
be saying immediately above, or have you misunderstood my position?
By contrast, last sentence suggesting simply printing a notice that there are
more authors than preferred captures the RFC Editor policy's statement.
I think you are saying that this makes sense? If so, I think we're in
agreement.
Henrik
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
At 11:52 AM 8/9/2008, Bert Wijnen \(IETF\) wrote: I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes aredescribed in formally approved BCP documents. [snip] Pls do not consider this ID-Checklist as part of our BCP approved process documents. That is not the intention of it and I think it would be bad to try and make it part of our set of BCPs that describe our (IETF) process. The IESG pointed to the ID-Checklist in its response to an appeal. If the intention is not to have the ID-Checklist as part of the approved process documents, it shouldn't be used as a formally approved document. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
W.r.t. - Original Message - From: Dave Crocker [EMAIL PROTECTED] To: Bert Wijnen (IETF) [EMAIL PROTECTED] Cc: ietf@ietf.org; [EMAIL PROTECTED] Sent: Monday, August 11, 2008 6:01 PM Subject: Re: Call for review of proposed update to ID-Checklist ... snip a lot .. Specific IPR (e.g., patent claims terms) must not be in an RFC The must is interesting. What BCP documents this (entirely reasonable, IMO) requirement? Does not point 4 4. Specific IPR (e.g., patent claims terms) must not be in an RFC (or Internet-Draft). Any claims must go to the IETF IPR web page and notice that there is some IPR claim. The mandatory IPR Notice from [RFC3979] (Bradner, S., Intellectual Property Rights in IETF Technology, March 2005.) section 5 points readers to the IETF IPR web page. clealry point you to the basis (RFC3979) ??? The point was/is that some people put one specific IPR claim in the RFC. And such is useless, after the RFC is Bert, once again, I'm not suggesting the guidance is wrong, but that it is without substantiation. It asserts a *requirement* that it seems to have invented. RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says what isn't. The proble we saw in the IESG (when we started ID_Checklist) was that we saw A LOT OF I-Ds that requested publication and that DID HAVE SPECIFIC IPR claims. So we wanted to make it clear to people that such is NOT TO BE DONE. Just saying that RFC3979 text was to be used seemed not to get through! And so on. Pls point out all the issues/concerns you have (if you want a personal email I did that: Each and every assertion that says or implies anything more than it can be helpful to do this needs to provide a narrow citation for its basis. I means and so on. If there are more, pls point them out. Bert d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Mixed case (was: Call for review of proposed update to ID-Checklist)
Dave Crocker wrote: This semantic distinction between upper and lower case that folks keep making is not supported by RFC 2119. As far as I'm concerned it is perfectly supported by RFC 2119: The capitalized forms of the keywords have the defined meaning. Other forms can have a different meaning. And where they have the same meaning they should be capitalized to avoid confusion. RFC 2119 itself uses lower case may, must, must not, and should in several places where the precise meaning of the capitalized words, i.e. the keywords, would not match. It is of course allowed to avoid mixed uses, but not required. Case distinction for semantics also goes against normal rules for English. THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Do you all have a lif? [was: Re: Call for review of proposed update to ID-Checklist (resend)]
Sorry for the off-topic discussion, but Martin started it. (I dropped the IESG, they probably see ietf list as well.) Of course I do have a life. ANd a good one too! Some people work early on workday mornings, others work late at night, yet others work on a saturday when iot is raining but take off when the sun shines during the week. That is the benefit of Internet collaboration. People can work when it fits their own schedule. And it allows us to better weave our work/personal life in way that suits us. Enjoy the Sunday. It is still raining here, but now I am going to a birthday party. That also means I may sleep late tomorrow morning ;-) Bert - Original Message - From: DOLLY, MARTIN C, ATTLABS [EMAIL PROTECTED] To: Bert Wijnen (IETF) [EMAIL PROTECTED]; Pete Resnick [EMAIL PROTECTED]; IETF Discussion ietf@ietf.org; IESG [EMAIL PROTECTED] Sent: Sunday, August 10, 2008 4:28 AM Subject: RE: Call for review of proposed update to ID-Checklist (resend) Do you all have a life. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
An additional check should be added to the list: all URLs that are meant to be able to be resolved must actually resolve at the time of submission. For example, the first URL in the ID-Checklist document does not resolve... --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Bert Wijnen (IETF) wrote: I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes are described in formally approved BCP documents. Bert, I am trying to distinguish between what the Checklist is intended to be from the competing views of what it actually is, as discussed in this thread 8-11 July. That thread made clear that a variety of serious and thoughtful people have very different views on the actuality. This sort of debate is never resolved by abstract exchanges. It needs hard data. I think your previous note correctly listed what the document was (and probably is) *intended* to be. I think the thread made clear there is a strong case that the document has become more than that. I think it also made clear that the basis for its becoming more is fuzzy. So my suggestion is not seeking to directly resolve the matter, but rather to provide a tool for discussion. Simply put, it adds an audit trail to the document's content that should help folks by providing some relatively objective information that makes clear what is and is not based on rules defined elsewhere. Hence, I am hoping that detailed attention to John's note following-up my own suggestion comes later, since I read it as possibly seeking to resolve things directly. More probably, he was merely trying to help make the case for why the document needs substantiation of its particulars. I suggested that you perform the audit exercise partly because you are the one modifying the document and partly because you are friendly to the document's current form. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Hi, things I'd like to see done in IDs more consistently: In an Editorial Note on the front page: - state on which mailing list discussions should take place (include mailing list archive and subscription links) - point to issues lists when available References: - check that if the document obsoletes or updates another document, that one appear in the references section, and make sure that the document actually says what's going on with respect to the other documents (such as Normative Changes from RFC ) - use symbolic references - when quoting RFCs, consider calling out a specific section in the referenced document (it's preferable that the author does it once, instead of the readers having to figure it out; also, it helps revising the document when the referenced document was revised) Code: - when using xml2rfc, add type parameters to artwork so that things like ABNF can be automatically extracted and checked Versioning: - (this probably is controversial :-) - keep an appendix that gives a short overview of what changed compared to previous drafts BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Bert, Bert Wijnen (IETF) wrote: As you all can see, the ID-Checklist in fact DOES refer to the rfc2223bis at many places. Yes, but... 1. draft-rfc-editor-rfc2223bis is expired. 2. While the citations that are included mostly do include the specific section to look in, some do not. (See the first example, below.) Hence, some of the citations are too broad. 3. Much of the document's direction is offered without citation. From the July 4 http://www.ietf.org/ID-Checklist.html... 2.2. Required sections - all I-Ds ... List of authors/editors There should not be more than 5 authors/editors (see http://www.rfc-editor.org/policy.html) The Policy document is about 10 pages long. I thought the specific information would be in Authors vs. Contributors but it wasn't. One has to search awhile to find Item #1 under an interestingly named section Author Overload, to find the basis for the should in the checklist. And note that the normative should language in the Checklist, here, might be considered stronger than what is actually said in the RFC Editor's policy document. (One can debate this, but then, that debate is exactly what we ought to have, based on hard data like this. My own opinion is that the should is appropriate here, in terms of actual practice, and it's long been what I advise folk writing drafts.) 1. Introduction ... As a suggestion for productivity improvement, it is strongly RECOMMENDED to use XML2RFC The capitalization appears intended to offer essentially normative guidance but, of course, that's probably not what is meant. 2.2. Required sections - all I-Ds The following are REQUIRED sections in all Internet-Drafts: What is the basis for asserting that this list is *required* (and, by the way, is required meant as a normative term; the caps suggest yes)? Again, please note that I'm not claiming the list is wrong, but that its provenance is absent. So your view that Our processes are described in formally approved BCP documents might be at risk. 3. Content issues ... B. no citations While I happen to think this is quite good advice, I have no idea a) where it comes from, or b) whether it is guidance or requirement. The one before it, Should be meaningful to someone not versed in the technology also lacks basis. Further, as guidance, it's reasonable, but entirely lacking in substance to help an author know how to satisfy it. and also from that section: Specific IPR (e.g., patent claims terms) must not be in an RFC The must is interesting. What BCP documents this (entirely reasonable, IMO) requirement? And so on. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Sunday, August 10, 2008 9:14 AM -0700 Dave Crocker [EMAIL PROTECTED] wrote: ... 2.2. Required sections - all I-Ds ... List of authors/editors There should not be more than 5 authors/editors (see http://www.rfc-editor.org/policy.html) ... And note that the normative should language in the Checklist, here, might be considered stronger than what is actually said in the RFC Editor's policy document. (One can debate this, but then, that debate is exactly what we ought to have, based on hard data like this. My own opinion is that the should is appropriate here, in terms of actual practice, and it's long been what I advise folk writing drafts.) And this is precisely one of the examples to which I was referring, because, in exceptional circumstances, the RFC Editor has been willing to negotiate that limit. However, if my memory is correct, the nits checker, which draws its authority from the Checklist, gets sufficiently annoyed about more than five authors to prevent posting of I-Ds. 1. Introduction ... As a suggestion for productivity improvement, it is strongly RECOMMENDED to use XML2RFC The capitalization appears intended to offer essentially normative guidance but, of course, that's probably not what is meant. And, the last I checked, there were MSWord tools that are considered as productive as xml2rfc (even if they are not to the personal taste of some of us). ... john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Hi John, On 2008-08-10 23:32 John C Klensin said the following: --On Sunday, August 10, 2008 9:14 AM -0700 Dave Crocker ... And note that the normative should language in the Checklist, here, might be considered stronger than what is actually said in the RFC Editor's policy document. (One can debate this, but then, that debate is exactly what we ought to have, based on hard data like this. My own opinion is that the should is appropriate here, in terms of actual practice, and it's long been what I advise folk writing drafts.) And this is precisely one of the examples to which I was referring, because, in exceptional circumstances, the RFC Editor has been willing to negotiate that limit. However, if my memory is correct, the nits checker, which draws its authority from the Checklist, gets sufficiently annoyed about more than five authors to prevent posting of I-Ds. Umm??? If you're referring to idnits, it does no test the number of authors in any way or form. I haven't checked whether the current, soon-to be replaced submission tool tries to check this, but idnits does most emphatically not. Henrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
On 2008-08-10 07:58, John C Klensin wrote: --On Saturday, 09 August, 2008 20:52 +0200 Bert Wijnen \\(IETF\\) [EMAIL PROTECTED] wrote: John and Dave, I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes aredescribed in formally approved BCP documents. The ID-Checklist is intended (or at least that is how it started, and as far as I am concerned that is still the intention) to help in a few areas: Bert, We are in complete and utter agreement with each other about the appropriate role of the ID_Checklist. For better or worse, the IESG apparently does not agree, as evidenced most recently in their response to my appeal about turning a suggestion from the original version of the Checklist into a firm rule without having that explicitly confirmed by the community. We also agree that revising the Checklist into a document that is suitable for use as part of a package of firm rules is a rather different job than updating it while being consistent with its original purpose. So I withdraw my suggestion and comments but strongly suggest that you make sure that your intentions for the document and those of the IESG are in synch before proceeding much further. I'd like to say that both as an author and as a reviewer, I have always found both the ID checklist and the IDnits checker to be of immense pragmatic value. Obviously, if the checklist or the checker complains about something that isn't obviously a bug, the author, shepherd, AD or reviewer will have to enter think mode or even negotiate mode. I agree that it's a good idea to be clear about that. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Sunday, August 10, 2008 6:03 PM +0200 Julian Reschke [EMAIL PROTECTED] wrote: Hi, things I'd like to see done in IDs more consistently: In an Editorial Note on the front page: - state on which mailing list discussions should take place (include mailing list archive and subscription links) - point to issues lists when available References: - check that if the document obsoletes or updates another document, that one appear in the references section, and make sure that the document actually says what's going on with respect to the other documents (such as Normative Changes from RFC ) Of course, if one does this, the automated nits checker complains about a reference to an obsolete RFC :-( - use symbolic references The RFC Editor is still flexible about this, IMO for good reason. It should not be the prerogative of this document, or even the IESG, to change the preference to a rule. ... Code: - when using xml2rfc, add type parameters to artwork so that things like ABNF can be automatically extracted and checked FWIW, I continue to believe, based on experience with a few fairly large and complex documents (most recently rfc2821bis) that the xml2rfc approach of treating ABNF as a special type of artwork is seriously broken for at least two reasons: (1) It effectively forces the author to do formatting on a line by line basis, which is not what generic markup is supposed to be all about and is pathological for pretty-print applications (including HTML and Postscript output) because it prevents taking advantage of different line length and wrapping options. That problem gets more severe if productions extend over several lines and/or contain comments. (2) It prevents indexing and use of XML elements to identify and organize portions of the ABNF (e.g., distinguishing rule names (LHS) from definitions (RHS) and comments). For both of these, use of hanging list elements can actually work better than the artwork model even those that option has more than its share of disadvantages as well. While I understand that this is a sufficiently large change to xml2rfc that I should not hold my breath, I think it would be very unfortunate to use the Checklist and/or its automatic instantiation to aggressively push a sometimes-unfortunate practice. Versioning: - (this probably is controversial :-) - keep an appendix that gives a short overview of what changed compared to previous drafts Yep, it is controversial. Good idea sometimes, bad idea others, hence probably a poor checklist guideline beyond, perhaps, please consider keeping best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Monday, August 11, 2008 12:54 AM +0200 Henrik Levkowetz [EMAIL PROTECTED] wrote: And this is precisely one of the examples to which I was referring, because, in exceptional circumstances, the RFC Editor has been willing to negotiate that limit. However, if my memory is correct, the nits checker, which draws its authority from the Checklist, gets sufficiently annoyed about more than five authors to prevent posting of I-Ds. Umm??? If you're referring to idnits, it does no test the number of authors in any way or form. I haven't checked whether the current, soon-to be replaced submission tool tries to check this, but idnits does most emphatically not. I apologize to idnits. I have seen documents rejected by some process because they had more than five authors, but I don't remember whether it was the submission tool or someone overzealous at the (present or past) Secretariat. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Monday, August 11, 2008 11:07 AM +1200 Brian E Carpenter [EMAIL PROTECTED] wrote: So I withdraw my suggestion and comments but strongly suggest that you make sure that your intentions for the document and those of the IESG are in synch before proceeding much further. I'd like to say that both as an author and as a reviewer, I have always found both the ID checklist and the IDnits checker to be of immense pragmatic value. I agree. I've just had a painful recent experience (not the first one) in which some overzealous person has assumed that some provision of one or the other is actually a firm rule and proceeded to try to enforce it in some draconian fashion. I don't believe that is wise, appropriate, or healthy. So I'm trying to be sure that the Checklist is clear about both its overall intent and the strength of any guidelines it presents in the hope of preventing that sort of behavior in the future. Obviously, if the checklist or the checker complains about something that isn't obviously a bug, the author, shepherd, AD or reviewer will have to enter think mode or even negotiate mode. I agree that it's a good idea to be clear about that. Either think mode or negotiate mode would be a considerable improvement over what has appeared to be this is a rule, it is immutable, change your document. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
John C Klensin wrote: ... References: - check that if the document obsoletes or updates another document, that one appear in the references section, and make sure that the document actually says what's going on with respect to the other documents (such as Normative Changes from RFC ) Of course, if one does this, the automated nits checker complains about a reference to an obsolete RFC :-( ... It's only a warning if it is an informative reference... ... Code: - when using xml2rfc, add type parameters to artwork so that things like ABNF can be automatically extracted and checked FWIW, I continue to believe, based on experience with a few fairly large and complex documents (most recently rfc2821bis) that the xml2rfc approach of treating ABNF as a special type of artwork is seriously broken for at least two reasons: I do agree that the approach of either it is prose or it is artwork does not work well for things lik e BNF, example mssages and so on... (1) It effectively forces the author to do formatting on a line by line basis, which is not what generic markup is supposed to be all about and is pathological for pretty-print applications (including HTML and Postscript output) because it prevents taking advantage of different line length and wrapping options. That problem gets more severe if productions extend over several lines and/or contain comments. That sounds a bit like the problem is more related to the RFC line length, and the ABNF comment placement rules. If there's something that can be done in xml2rfc, I'd be interested to discuss this further (preferably on the xml2rfc mailing list). (2) It prevents indexing and use of XML elements to identify and organize portions of the ABNF (e.g., distinguishing rule names (LHS) from definitions (RHS) and comments). I'm working around that by using custom extensions in rfc2629.xslt, and by translating these extensions into something xml2rfc understands (example: http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-03.html). For both of these, use of hanging list elements can actually work better than the artwork model even those that option has more than its share of disadvantages as well. While I understand that this is a sufficiently large change to xml2rfc that I should not hold my breath, I think it would be very unfortunate to use the Checklist and/or its automatic instantiation to aggressively push a sometimes-unfortunate practice. Sounds like we need better tools. If automatic line wrapping for BNF is the issue, maybe a preprocessor would be sufficient. ... BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
I have started to updatre the document based on feedback. My approach is to clearly make those changes that are straight forward, simple end editorial. For other changes, I need to hear (I guess from Russ) that there is consensus to make such a change. It may take a little more time before I have checked and evaluated all comments. Inline - Original Message - From: Frank Ellermann [EMAIL PROTECTED] To: ietf@ietf.org Sent: Wednesday, July 09, 2008 8:51 AM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistIETF Chair wrote: http://www.ietf.org/Draft-ID-Checklist.html Nits: (1) Archive older versions in a plain text format as for I-Ds (for use with various IETF tools working on I-Ds) I can generate I-Ds if that helps. I can even submit those. Russ, do you want me to do that? (2) s/2434/5226/ (3) s/2780/2780 + 5237/ above 2 are done in my new copy (4) I-D.bellovin expired months ago with three DISCUSSes, please resolve that by time-out ABSTAINs (or similar) There is a new rev dated Aug 03 2008. That will now get picked up by the xml2rfc tool. I will not comment on the time-out on ABSTAINs, that is an IESG issue, not one that relates to teh ID-Checklist document. (5) s/4181/4181 + 4841/ (6) s/4234/5234/ The above 2 have been updated in new copy (7) Please add RFC 5137 (BCP 137) to section 4 as item 5 I do not feel confident to add that unless Russ tells me that this is consensus and should be added. (8) I-D.2223bis expired 3.5 years ago, and is flagged as DEAD since May 2008 I know. I have communicated with Russ and RFC-Editor about this. We will replace it with a reference to http://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt Bert Editor of ID-Checklist Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
This suggests to allow more gTLDs for use as examples. It seems to me that that would mean an update to RFC2606, an I consider that out of scope for the ID-Checklist document. So I will ignore all discussion on this for the current updates. If an updated 2606 ever occurs, I will accept to update ID-Checklist accordingly. Bert Editor of ID-Checklist - Original Message - From: Bill McQuillan [EMAIL PROTECTED] To: IETF Discussion ietf@ietf.org Sent: Wednesday, July 09, 2008 6:37 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-Checklist On Wed, 2008-07-09, Spencer Dawkins wrote: If an example describes a complex network topology, it could be appropriate to use a variety of names, IP addresses or prefixes that are easily disambiguated, so that the reader might follow the example more easily. I wonder if it would make it easier to use example DNS names if, in addition to the verbose and clumsy: *.example, IMHO, we reserved gTLDs like *.foo, *.bar, *.bat, *.baz, as well as the one used quite frequently on this list lately: *.tld, for use as example DNS names. Or do we assume that economic concerns would triumph here? -- Bill McQuillan [EMAIL PROTECTED] ___ 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: Call for review of proposed update to ID-Checklist
Bert Wijnen (IETF) wrote: My approach is to clearly make those changes that are straight forward, simple end editorial. For other changes, I need to hear (I guess from Russ) that there is consensus to make such a change. Bert, et al, Something that might help further discussions quite a bit is considering annotation and re-organization of the document, to clarify some basic distinctions. For example, labeling the bits that are based on IETF standards rules versus the bits that are based on IESG requirements? Equally, what pertains to documentation standards versus what pertains to technical/protocol issues? The document has evolved into a possibly disorganized mixture of these and last month's discussions was challenged to separate issues, I think. This kind of change would not be modification of the Checklist semantics, but would add clarity to what is currently there. Any serious effort to clarify the document in this way is likely to engender more focused discussion than was possibly earlier, if only by offering some specific and relevant categorical distinctions. That discussion is then more likely to produce the kind of input that will help Russ make those consensus assessments. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Bert, I want to reinforce Dave's comments and perhaps carry them a bit further. If the ID-checklist were just the general guidance that I believe it started out to be, the distinctions I suggest below would probably be unnecessary. But we've seen recently that there are very few steps between having a list and having everything on that list become rigid, mechanically-applied, requirements. --On Saturday, 09 August, 2008 09:20 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Bert, et al, Something that might help further discussions quite a bit is considering annotation and re-organization of the document, to clarify some basic distinctions. For example, labeling the bits that are based on IETF standards rules versus the bits that are based on IESG requirements? Equally, what pertains to documentation standards versus what pertains to technical/protocol issues? Many of the bits that pertain to documentation requirements are IESG interpretations of RFC Editor guidelines. The RFC Editor has traditionally been much more flexible about their rules than recent trends in the IESG have been. Even when the rules come from the IESG, it would be useful to better distinguish between firm requirements (e.g., the IPR boilerplate) and guidance (e.g., things to which one should either conform or expect to have to explain, convincingly, why not). The document has evolved into a possibly disorganized mixture of these and last month's discussions was challenged to separate issues, I think. This kind of change would not be modification of the Checklist semantics, but would add clarity to what is currently there. But it is precisely the semantics that I think are at issue. This is less what is in the checklist because I believe we could agree that everything there is at least good general guidance than about the apparent tendency for entries in the checklist to become rigid rules that will be enforced even if specific circumstances suggest otherwise. Any serious effort to clarify the document in this way is likely to engender more focused discussion than was possibly earlier, if only by offering some specific and relevant categorical distinctions. And, in the case of the distinctions I'm suggesting, permit meaningful community consideration of whether there is consensus about particular rules, which may be different from consensus about general guidance. regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
John and Dave, I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes aredescribed in formally approved BCP documents. The ID-Checklist is intended (or at least that is how it started, and as far as I am concerned that is still the intention) to help in a few areas: - Make document authors/editors and WG chairs (and reviewers) aware of the many little things we found as ADs and IESG when reviewing documents that came out of WGs. Those mistakes always later caused confusion and delay in the further process. - Reduce the document-time of AD, IESG, IETF LC-reviewers, RFC-Editor by reducing extra steps to fix little and simple things. - All those simple things were (and still are) documented in other RFCs or in the RFC-Editor Style manual, and so it is/was not a new set of rules or requirements - Authors/Editors SHOULD know all these little things, but they often did/do not know exactly what they are or where to find them. The ID_Checklist is intended to help find these things. - By documenting these things, it became easier/quicker to point to them (both if found at AD or IESG review and earlier) - By documenting them, the WG-Chair (document shepherd) can do a lot of these checks, so that they can not slip through later in the process or delay the process afetr IESG approves. - I believe that the ID-Checklist also helped Henrik write the id-nits tool that will do a check for most of the checlist items that can (reasonably) be checked by software I remember that before we had the ID-Checklist, we often wasted a lot of time on this simple things (be it by taking a DISCUSS, by interacting with the authors, by adding RFC-Editor notes, By later checking if things were fixed, By later discussing aith editors/authos why such little fixes were made etc etc ect). So I believe it has served its purpose very well. And I also believe that the intended purpose is still served very well with the current version, albeit that some clarifications an dupdates to ptrs and citations/references are in order. Pls do not consider this ID-Checklist as part of our BCP approved process documents. That is not the intention of it and I think it would be bad to try and make it part of our set of BCPs that describe our (IETF) process. So I am not prepared yet to take on a massige reorg and as a result probably a long discussion and wordtsmitting effort. If Russ (or the IESG) tells me that they DO want a complete re-org I will re-consider. But that was/is not the task I was asked to do (I believe). I hope you understand Bert Editor of the ID_Checklist. - Original Message - From: John C Klensin [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Bert Wijnen (IETF) [EMAIL PROTECTED] Cc: IETF Discussion ietf@ietf.org Sent: Saturday, August 09, 2008 8:30 PM Subject: Re: Call for review of proposed update to ID-Checklist Bert, I want to reinforce Dave's comments and perhaps carry them a bit further. If the ID-checklist were just the general guidance that I believe it started out to be, the distinctions I suggest below would probably be unnecessary. But we've seen recently that there are very few steps between having a list and having everything on that list become rigid, mechanically-applied, requirements. --On Saturday, 09 August, 2008 09:20 -0700 Dave Crocker [EMAIL PROTECTED] wrote: Bert, et al, Something that might help further discussions quite a bit is considering annotation and re-organization of the document, to clarify some basic distinctions. For example, labeling the bits that are based on IETF standards rules versus the bits that are based on IESG requirements? Equally, what pertains to documentation standards versus what pertains to technical/protocol issues? Many of the bits that pertain to documentation requirements are IESG interpretations of RFC Editor guidelines. The RFC Editor has traditionally been much more flexible about their rules than recent trends in the IESG have been. Even when the rules come from the IESG, it would be useful to better distinguish between firm requirements (e.g., the IPR boilerplate) and guidance (e.g., things to which one should either conform or expect to have to explain, convincingly, why not). The document has evolved into a possibly disorganized mixture of these and last month's discussions was challenged to separate issues, I think. This kind of change would not be modification of the Checklist semantics, but would add clarity to what is currently there. But it is precisely the semantics that I think are at issue. This is less what is in the checklist because I believe we could agree that everything there is at least good general guidance than about the apparent tendency for entries in the checklist to become rigid rules that will be enforced even if specific circumstances suggest otherwise. Any serious effort to clarify the document in this way is likely
Re: Call for review of proposed update to ID-Checklist
--On Saturday, 09 August, 2008 20:52 +0200 Bert Wijnen \\(IETF\\) [EMAIL PROTECTED] wrote: John and Dave, I think that both of you (and some others) arwe looking at the ID_Checklist too much as if it is part of our (rigid) process. Our processes aredescribed in formally approved BCP documents. The ID-Checklist is intended (or at least that is how it started, and as far as I am concerned that is still the intention) to help in a few areas: Bert, We are in complete and utter agreement with each other about the appropriate role of the ID_Checklist. For better or worse, the IESG apparently does not agree, as evidenced most recently in their response to my appeal about turning a suggestion from the original version of the Checklist into a firm rule without having that explicitly confirmed by the community. We also agree that revising the Checklist into a document that is suitable for use as part of a package of firm rules is a rather different job than updating it while being consistent with its original purpose. So I withdraw my suggestion and comments but strongly suggest that you make sure that your intentions for the document and those of the IESG are in synch before proceeding much further. regards, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Ted, a glib response would be: We can ask the RC-Editor to fix everything that is broken But do we (IETF/ISOC) really want to spend a lot of real money on payed RFC-Editor to fix up things that authors/editors can easily do, specifically with a ID-Checklist in hand that points out the many simple things-to-fix that we often found in many submitted I-Ds? My take is that we should put that responsibility with the authors/editors and the WG chairs. That is what the document does, and that is also what a WG chair is asked to check when they fill out the questionaire in RFC4848 in section 3.1, The shepherd (often WG chair) is asked to confirm that he did check the document to meet the ID-Checklist (see question 1.g on page 6). And that SAVES a lot of time on already overloaded ADs/IESG and also SAVES real dollars in the RFC-Editor cycle. Bert Editor for ID_Checklist - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: Pete Resnick [EMAIL PROTECTED] Cc: IETF Chair [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 11:35 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistOn Tue, Jul 08, 2008 at 02:27:41PM -0500, Pete Resnick wrote: The document says: If ABNF is used, you MUST include a normative reference to RFC 4234. To quote two fine radio personalities here in the states, this one seems boogus. Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. Stupid question isn't this specific thing something we should allow the secretariat to fix as part of the RFC publishing process, and in fact give them instructions to add the reference if they find it missing? They do things like fix/update references IIRC, and this is only a minor step beyond that, and should be well within their capabilities, I would think. Sure, we can ask document editors to add the reference to RFC 4234, and maybe we can even do things like include a reference to RFC 4234 in an RFC template file with a note to remove if the standard ends up not using ABNF, but there must be a class of things which could be streamlined to save time on both the document editors, reviewers, and AD's time. Regards, - Ted ___ 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: Call for review of proposed update to ID-Checklist
As you all can see, the ID-Checklist in fact DOES refer to the rfc2223bis at many places. It has now been updated (in my copy) to point to the RFC-Editor-Style Manual. Specifically section 2 discusses this, and sect 2.1 starts out by stating: In principle, the RFC-Editor can take care of a few small formatting errors. And if there are only a few, then they will do so. However, if many errors exist, the document will be returned to the author(s)/editor(s)/WG for fixes. In any event, please realize that not following the formatting rules will most probably delay publication and does consume time that can be spend on other work. It could be made clearer that the ID-Checklist is specifically intended for final I-Ds that are submitted to an AD, i.e. a request for publication to the AD/IESG. The first Note in the Introduction section does say so. But to be more clear, I have changed the fuirst sentence of sect 1. from All Internet Drafts which are offered for publication as RFCs into All Internet Drafts which are offered to an AD or the IESG with a request for publication as RFC I hope that clarifies. Bert Editor for ID_checklist - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: ietf@ietf.org; [EMAIL PROTECTED] Sent: Wednesday, July 09, 2008 2:13 AM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistOn 2008-07-09 07:08, Dave Crocker wrote: ... Small point of confusion: I thought the RFC document series was managed with some independence of the IETF. As such, I'm not clear how the IETF (nevermind the IESG) can set the rules for RFC format and style. I view the id-checklist as a gating factor for IESG review, not as instructions to the RFC Editor. Of course it should be consistent with the RFC Editor's practice, as a matter of common sense. The introduction should make this clear, perhaps. Brian ___ 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: Call for review of proposed update to ID-Checklist
Bert Wijnen wrote: I believe that the ID-Checklist also helped Henrik write the id-nits tool that will do a check for most of the checlist items that can (reasonably) be checked by software [...] FWIW I consider your checklist as very helpful especially for new authors, for all the reasons you have stated. That things can get interesting when authors feel the need to explore exceptions from a SHOULD is as it is, your checklist can't go into all possible details. The 2821bis case was one of those interesting things, we could talk about it for hours, but this doesn't belong into the checklist. New authors hopefully know that not following a SHOULD needs a good excuse, and other authors certainly know it, but might still disagree about some details of good enough excuses. RFCs that will be so popular that everybody and his dog will take their clues from these RFCs and not a relatively obscure IETF-internal checklist are rare. I've proposed to add RFC 5137, but if you or Russ think that this is no good idea it is no problem. John proposed some tweaks, I hope you'll look at his proposals. I believe it has served its purpose very well. Yes. Of course it's overwhelming what potential authors will find when they look for advice, but again I think that is as it is, there can't be one authoritative rule saying it all... For starters folks here would disagree about the authority. And it won't suprise anybody here when I admit that one major point in the 2606bis drafts is to confirm RFC 2606 as it was, a recommendation wrt examples. Not more and not less. FWIW I could even provide an example where not following this recommendation triggered a DISCUSS, later solved by a good excuse. I'd not support to twist this 2606 recommendation into mustard. Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fw: Call for review of proposed update to ID-Checklist (resend)
Oops, used wrong from address - Original Message - From: Bert Wijnen [EMAIL PROTECTED] To: Pete Resnick [EMAIL PROTECTED]; ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Saturday, August 09, 2008 9:29 PM Subject: Re: Call for review of proposed update to ID-Checklist Pete Again, this was included in the ID-Checklist, because many many documents did use ABNF without a citation/reference. As stated before: the ID-Checklist does not (intend) to introduce any new requirements that were/are not documented elsewhere in our approved procedures/documents. So in that light, the ID-Checklist might as well be abolished. Practice/experience has however shown that many authors/editors of I-Ds do not follow our procedures very well (not a big surprise, it is not easy to find them all) and so the ID-Checklist tries to help them have the pointers in one place. Bert Editor of the ID-Checklist - Original Message - From: Pete Resnick [EMAIL PROTECTED] To: ietf@ietf.org Cc: IETF Chair [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 9:27 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistThe document says: If ABNF is used, you MUST include a normative reference to RFC 4234. To quote two fine radio personalities here in the states, this one seems boogus. Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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
Fw: Call for review of proposed update to ID-Checklist (resend)
Oops, used wrong from address - Original Message - From: Bert Wijnen [EMAIL PROTECTED] To: Pete Resnick [EMAIL PROTECTED]; ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Saturday, August 09, 2008 9:25 PM Subject: Re: Call for review of proposed update to ID-Checklist Pete, I am not sure how this helps. I thought that ID authors/editors DO know what MUST/SHOULD means. If not, then as far as I am concerned, we can change the capitalized words into lower case. The front of the document shows (into with notes) clearly waht the intent is. And is states that ADs will not accept a request for publication and will not put it on the IESG agenda. Is that not clear enough? See also my response to Klensin and Crocker about the intent of the document. That said, if Russ agrees, I can certainly add more boilerplate text as you suggest below. I doubt it will make the document any more useful. Bert Editor of ID_Checklist - Original Message - From: Pete Resnick [EMAIL PROTECTED] To: ietf@ietf.org Cc: IETF Chair [EMAIL PROTECTED]; ietf@ietf.org; IETF Announcement list [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 9:17 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistOn 7/8/08 at 11:44 AM -0700, IETF Chair wrote: The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Insert in the Introduction, before or at the beginning of Notes: - This memo uses the terms MUST, REQUIRED, SHOULD, and RECOMMENDED, similarly to the use of these terms in RFC 2119. In particular, when they appear in ALL CAPS in this memo: -MUST or REQUIRED means that if you do not do this in your I-D, the IESG will not accept the I-D for any review until the item is complete. - SHOULD or RECOMMENDED means that there may be valid reasons to ignore the item, but an explanation must be given, either in the text of the document or as part of the submission to the IESG, as to why the item is being ignored. Otherwise, the IESG may not accept the I-D for review. - This text both (a) puts draft authors on notice as to what the hard requirements are in order to avoid late surprises, and (b) puts reviewers of this memo on notice so that consensus can be reached on what are or are not real showstoppers for IESG review. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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: Call for review of proposed update to ID-Checklist (resend)
Do you all have a life. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bert Wijnen (IETF) Sent: Saturday, August 09, 2008 4:12 PM To: Pete Resnick; IETF Discussion; IESG Subject: Fw: Call for review of proposed update to ID-Checklist (resend) Oops, used wrong from address - Original Message - From: Bert Wijnen [EMAIL PROTECTED] To: Pete Resnick [EMAIL PROTECTED]; ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Saturday, August 09, 2008 9:25 PM Subject: Re: Call for review of proposed update to ID-Checklist Pete, I am not sure how this helps. I thought that ID authors/editors DO know what MUST/SHOULD means. If not, then as far as I am concerned, we can change the capitalized words into lower case. The front of the document shows (into with notes) clearly waht the intent is. And is states that ADs will not accept a request for publication and will not put it on the IESG agenda. Is that not clear enough? See also my response to Klensin and Crocker about the intent of the document. That said, if Russ agrees, I can certainly add more boilerplate text as you suggest below. I doubt it will make the document any more useful. Bert Editor of ID_Checklist - Original Message - From: Pete Resnick [EMAIL PROTECTED] To: ietf@ietf.org Cc: IETF Chair [EMAIL PROTECTED]; ietf@ietf.org; IETF Announcement list [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 08, 2008 9:17 PM Subject: Re: Call for review of proposed update to ID-Checklist Re: Call for review of proposed update to ID-ChecklistOn 7/8/08 at 11:44 AM -0700, IETF Chair wrote: The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Insert in the Introduction, before or at the beginning of Notes: - This memo uses the terms MUST, REQUIRED, SHOULD, and RECOMMENDED, similarly to the use of these terms in RFC 2119. In particular, when they appear in ALL CAPS in this memo: -MUST or REQUIRED means that if you do not do this in your I-D, the IESG will not accept the I-D for any review until the item is complete. - SHOULD or RECOMMENDED means that there may be valid reasons to ignore the item, but an explanation must be given, either in the text of the document or as part of the submission to the IESG, as to why the item is being ignored. Otherwise, the IESG may not accept the I-D for review. - This text both (a) puts draft authors on notice as to what the hard requirements are in order to avoid late surprises, and (b) puts reviewers of this memo on notice so that consensus can be reached on what are or are not real showstoppers for IESG review. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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: Call for review of proposed update to ID-Checklist
Bob, This contradicts Section 2.1 of RFDC 1123, which says an application SHOULD support literal addresses (and of course DNS support is a MUST) -- Section 6.1.1.) Within the application space, which is what we were talking about with RFC 1123, I'd have to say that the times have changed. Back in 1989 DNS was still relatively unproven, failures were common, and there was a need to be able to get around DNS. Remember that even as late as two years prior, one had to edit SunOS binaries to gain access to DNS. Worse, use of literals in applications leads to their being placed in configuration files, and that's just bad juju in a dynamic world. I'm not saying that DNS is perfect by any stretch, but the alternative is worse. Still, I don't think John is suggesting that we prohibit applications from supporting literals. I personally just think we shouldn't highlight such examples. As I recall, John was in the room, by the way, when that text was discussed. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Eliot Lear wrote: Bob, This contradicts Section 2.1 of RFDC 1123, which says an application SHOULD support literal addresses (and of course DNS support is a MUST) -- Section 6.1.1.) Within the application space, which is what we were talking about with RFC 1123, I'd have to say that the times have changed. Back in 1989 DNS was still relatively unproven, failures were common, and there was a need to be able to get around DNS. In my experience, DNS failures are still common. Most of those failures are probably due to misconfiguration of some sort or another (e.g. failure to decrease TTLs in advance of an address change, particularly when that address is in an NS record). But to the application, it still looks like a DNS failure. Worse, use of literals in applications leads to their being placed in configuration files, and that's just bad juju in a dynamic world. We're a LONG way from getting rid of literals in configuration files. We're a LONG way from a world where IP addresses can change at a whim. I'm not saying that DNS is perfect by any stretch, but the alternative is worse. Still, I don't think John is suggesting that we prohibit applications from supporting literals. I personally just think we shouldn't highlight such examples. I think examples involving literals are fine, as long as we state that they're expected to be used only in exceptional cases. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Friday, 11 July, 2008 09:48 -0400 Keith Moore [EMAIL PROTECTED] wrote: Eliot Lear wrote: Bob, This contradicts Section 2.1 of RFDC 1123, which says an application SHOULD support literal addresses (and of course DNS support is a MUST) -- Section 6.1.1.) Within the application space, which is what we were talking about with RFC 1123, I'd have to say that the times have changed. Back in 1989 DNS was still relatively unproven, failures were common, and there was a need to be able to get around DNS. In my experience, DNS failures are still common. Most of those failures are probably due to misconfiguration of some sort or another (e.g. failure to decrease TTLs in advance of an address change, particularly when that address is in an NS record). But to the application, it still looks like a DNS failure. This is an important consideration. But it is an important consideration in designing protocols and table formats and for configuring systems. As Eliot points out (and as I tried to point out to Bob earlier) no one is suggesting (at least in this Checklist context) prohibiting a protocol specification from supporting literals -- this is just about choices of examples. Even the question of describing the tradeoffs between the use of domain names versus literals in a particular protocol, while important, has little to do with the examples in most cases. ... I'm not saying that DNS is perfect by any stretch, but the alternative is worse. Still, I don't think John is suggesting that we prohibit applications from supporting literals. I personally just think we shouldn't highlight such examples. I think examples involving literals are fine, as long as we state that they're expected to be used only in exceptional cases. But that is exactly what the proposed text (in its virtual revised form) would require, e.g. (illustrative, not a proposal for final text), One SHOULD avoid use of literals in examples. In the exception cases, one should note why they were used so that reviewers can understand the reasoning. The DNS is too unstable or otherwise inappropriate for many of the real-world cases so it was important to illustrate the syntax when a literal is used as the common case would be, IMO, a perfectly good statement of a reason. Whether or not the community would accept that as a reason would, I assume depend on the case-by-case specifics of the protocol or context involved. That is, IMO, as it should be. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
John C Klensin wrote: Better text is welcome if we can agree on the principle. It may also be that, if we are going to permit addresses, some words in the Checklist about preferences for IPv4, IPv6, or parallel examples would be in order. The principle should be stay away from IP literals when you can in practice. The hypothetical specification could quote the scream in RFC 822: | Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. After that's clear some examples with domain literals are no problem, they are actually desperately needed, because the syntax differs depending on the context: Sometimes square brackets are required, sometimes they are not allowed, sometimes this depends on IPv4 vs. IPv6. When square brackets are required they are typically used as is, but in URIs + IRIs outside of host and ihost they have to be percent-encoded. A mailto: specification without example for domain literals would be irresponsible, no matter what an ID-checklist says. IMO the SHOULD about using FQDNs instead of IPs in examples is nonsense. The ID-Checklist is the wrong place to tell authors that FQDNs are better than IPs; they are supposed to know this. I think that is supposed to be what we all want around here, isn't it? Yes, your new MUSTard is fine. The old SHOULD about FQDNs vs. domain literals in examples is utter dubious. Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
* * John C Klensin wrote: * * (iii) The IETF has indicated enough times that domain * names, not literal addresses, should be used in both * protocols and documents that doing anything else should * reasonably require clear and strong justification. * John, This contradicts Section 2.1 of RFDC 1123, which says an application SHOULD support literal addresses (and of course DNS support is a MUST) -- Section 6.1.1.) Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Thursday, 10 July, 2008 08:50 -0700 Bob Braden [EMAIL PROTECTED] wrote: * * John C Klensin wrote: * * (iii) The IETF has indicated enough times that domain * names, not literal addresses, should be used in both * protocols and documents that doing anything else should * reasonably require clear and strong justification. John, This contradicts Section 2.1 of RFDC 1123, which says an application SHOULD support literal addresses (and of course DNS support is a MUST) -- Section 6.1.1.) Yes. Independent of the text in 1123, several others have pointed out that as strong a rule as I suggested, worded that way, would be a bad idea. Several notes in this thread have pointed that out, offered specific examples, and proposed text that was better than mine. Of course, there has never been a requirement that a specification exhibit every one of its capabilities in examples. The examples should be chosen should, IMO, represent likely common practice rather than obscure features. Sometimes that will point to the use of IP addresses (see a note from Ted Hardie for an example) but often it will suggest DNS names instead. However, since IPv6 came over the horizon, there _have_ been a number of statements made that prefer domain names over literal addresses for reasons that were not relevant when 1123 was written. I think those arguments are strong enough that asking an editor who chooses to use examples with address literals in it to explain that choice is entirely in order. Again, the goal of my proposal is to move the rationale for decisions to use anything but 2606 names into the document flow for consideration during discussions of the document and Last Call, with the IESG interpreting community consensus (as with everything else). The alternative, it appears, is a guessing game about IESG intentions and flexibility post-last-call and an invitation to private negotiations between the IESG and authors. We generally claim those are a bad idea even if we don't always act consistently with that claim. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
IETF Chair wrote: http://www.ietf.org/Draft-ID-Checklist.html Nits: (1) Archive older versions in a plain text format as for I-Ds (for use with various IETF tools working on I-Ds) (2) s/2434/5226/ (3) s/2780/2780 + 5237/ (4) I-D.bellovin expired months ago with three DISCUSSes, please resolve that by time-out ABSTAINs (or similar) (5) s/4181/4181 + 4841/ (6) s/4234/5234/ (7) Please add RFC 5137 (BCP 137) to section 4 as item 5 (8) I-D.2223bis expired 3.5 years ago, and is flagged as DEAD since May 2008 Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
John C Klensin [EMAIL PROTECTED] writes: While I agree, I believe that it would be of great help if the IESG gave indications of the situations in which an exception to a SHOULD would be appropriate. Yes. And on the particular question of example DNS names: 6. Addresses used in examples SHOULD use fully qualified domain names instead of literal IP addresses, and SHOULD use example fqdn's such as foo.example.com instead of real-world fqdn's. See [RFC2606] (Eastlake, D. and A. Panitz, Reserved Top Level DNS Names, June 1999.) for example domain names that can be used. Why the SHOULD? Presumably, because you don't want naive folk to take the examples in the RFC and use them in local config files and such, causing problems or other undesirable effects when they (unexpectedly) get used in the real world.. But in cases where this really is not a concern, there is also presumably not a need to _require_ use of the example names. Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Dear IESG, From the discussion just prior to the recent appeal by John Klensin, it was clear that the guidance regarding example domain names in IETF documents provided in the ID-Checklist needed to be updated. This point was emphasized further during the discussion of the Klensin appeal. Proposed text is now available. Many thanks to Bert Wijnen for continuing to edit the document. The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I agree with moving the 2606 check to SHOULD. It is often helpful to provide guidance about when SHOULDs might not be appropriate, when we have at least some experience where this is the case. Were I to propose text, I think we have some experience that's popped up during the appeal discussion, as follows: Addresses used in examples SHOULD use fully qualified domain names instead of literal IP addresses, and SHOULD use example fqdn's such as foo.example.com instead of real-world fqdn's. See [RFC2606] (Eastlake, D. and A. Panitz, Reserved Top Level DNS Names, June 1999.) for example domain names that can be used. The use of reserved example FQDNs, IP addresses or network prefixes may not be appropriate in all cases, including these (which have come up in practice): o If an example describes a complex network topology, it could be appropriate to use a variety of names, IP addresses or prefixes that are easily disambiguated, so that the reader might follow the example more easily. o If a standards-track document that does not use example names is advancing, it could be appropriate to minimize text changes as the document advances (the names used in the document have already been published, so the question should be whether there is additional damage that would result from the second publication on the standards track). Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
At 9:37 AM -0700 7/9/08, Bill McQuillan wrote: I wonder if it would make it easier to use example DNS names if, in addition to the verbose and clumsy: *.example, IMHO, we reserved gTLDs like *.foo, *.bar, *.bat, *.baz, as well as the one used quite frequently on this list lately: *.tld, for use as example DNS names. foo and bar seem fine for nerdy IETF examples. bat would pose similar security issues as com :-). baz seems awfully close to the ever-so-popular biz TLD. tld seems like an excellent suggestion. Not much like any current TLDs; it's well-known in the field of use; it is unlikely that there is much commercial value to it; it's nearly impossible to pronounce without spelling out the acronym. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
More example TLDs in 2606bis? (was: Call for review of proposed update to ID-Checklist)
Bill McQuillan wrote: I wonder if it would make it easier to use example DNS names if, in addition to the verbose and clumsy: *.example, IMHO, we reserved gTLDs like *.foo, *.bar, *.bat, *.baz, as well as the one used quite frequently on this list lately: *.tld, for use as example DNS names. Or do we assume that economic concerns would triumph here? After about 100 articles with 2606 in the subject finally a note which really is about 2606, even if not in the subject :-) There is certainly a tradition to use *.tld in examples, and we could say that we want this officially reserved. While at it we could also grab the 11 IDN example labels used together with the 11 IDN test TLDs in the (running) IDN test. That would give us 13 example TLDs, plus three known *.example.cno. IMO more than enough, otherwise we could add *.lit to the set. But the keyword is grab as in domain grabbing. Without a clear technical demand for this it could upset folks with an interest and the money to buy TLD .tld for dubious purposes. So far the support to grab those 11 IDN example labels as TLDs was not overhelming, otherwise you would already see it in the 2606bis draft (idnabis-test-tlds). Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Wednesday, 09 July, 2008 10:19 -0400 Thomas Narten [EMAIL PROTECTED] wrote: And on the particular question of example DNS names: 6. Addresses used in examples SHOULD use fully qualified domain names instead of literal IP addresses, and SHOULD use example fqdn's such as foo.example.com instead of real-world fqdn's. See [RFC2606] (Eastlake, D. and A. Panitz, Reserved Top Level DNS Names, June 1999.) for example domain names that can be used. Why the SHOULD? Presumably, because you don't want naive folk to take the examples in the RFC and use them in local config files and such, causing problems or other undesirable effects when they (unexpectedly) get used in the real world.. But in cases where this really is not a concern, there is also presumably not a need to _require_ use of the example names. Well, I agree, but, based on the response to the 2821bis appeal and the proposed RFC Editor note on that document, the IESG apparently sees actual harm (rather than, e.g., impolite behavior) where some of the rest of us do not. In the interest of being constructive, reducing ambiguity, surprises and post-last-call quibbling, of focusing on the areas where I think there is consensus about harm, and of being specific, I propose the following as alternative text: 6. Addresses used in I-Ds SHOULD use fully qualified domain names (FQDNs) instead of literal IP addresses. Working Groups or authors seeing exemptions from that rule MUST supply the rationale for IP address use with inline comments (e.g., Editor's note: or Note in Draft: that can be evaluated by the IESG and the community along with the rest of the document. Domain names in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). It is generally desirable for domain names used in other I-D discussion contexts to be drawn from BCP32 as well, if only as an act of politeness toward those who might be using the domains for other purposes at the time of publication or subsequently. Working groups or editors who are convinced that different names are required MUST be prepared to explain and justify their choices and SHOULD do so with explicit inline comments such as those described above. Now, that is somewhat longer and more complicated, but it would seem to satisfy the criteria that have been discussed on the IETF list, not just since the ID-Checklist update draft was posted, but over the last six weeks or so. In particular: (i) I believe that there actually is consensus that use of non-2606 names in places where they are likely to be copied into production code (even if only by the lazy or careless) is likely to be harmful as well as a terrible idea. (ii) There is, at best, much less consensus that use of non-2606 names in narrative or illustrative examples is likely to be harmful. There may be consensus that it is impolite (or, to quote some recent IESG comments, rude) but that is, IMO, a rather different matter. (iii) The IETF has indicated enough times that domain names, not literal addresses, should be used in both protocols and documents that doing anything else should reasonably require clear and strong justification. (iv) If someone wants to use non-2606 names, it is entirely reasonable to expect them to explain why and to do so in public. If that drives editors and WGs to take the path of least resistance and use the 2606 names, I think it should be fine with all of us. FWIW, please note the philosophical similarity between the above and RFC 4897. In both cases, we move away from incentives for elaborate procedures and private negotiations between the IESG and authors (and the consequent late-stage guessing about what is likely to happen). Instead, we get the issues and justifications up front as part of document processing or in the document itself so that the community can address them as part of Last Call. The IESG can then make decisions based on evidence of community consensus (or community indifference, as the case may be). I think that is supposed to be what we all want around here, isn't it? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
At 2:03 PM -0700 7/9/08, John C Klensin wrote: I propose the following as alternative text: A nit with this: 6. Addresses used in I-Ds SHOULD use fully qualified domain names (FQDNs) instead of literal IP addresses. Working Groups or authors seeing exemptions from that rule MUST supply the rationale for IP address use with inline comments (e.g., Editor's note: or Note in Draft: that can be evaluated by the IESG and the community along with the rest of the document. Domain names in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). I believe that this must say Example domains in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). Without that, it might be read to force things like the domains in XML namespaces to fit this rule. Those are, after all, things that might be partially or entirely copied into code. It is generally desirable for domain names used in other I-D discussion contexts to be drawn from BCP32 as well, if only as an act of politeness toward those who might be using the domains for other purposes at the time of publication or subsequently. Working groups or editors who are convinced that different names are required MUST be prepared to explain and justify their choices and SHOULD do so with explicit inline comments such as those described above. Now, that is somewhat longer and more complicated, but it would seem to satisfy the criteria that have been discussed on the IETF list, not just since the ID-Checklist update draft was posted, but over the last six weeks or so. In particular: (i) I believe that there actually is consensus that use of non-2606 names in places where they are likely to be copied into production code (even if only by the lazy or careless) is likely to be harmful as well as a terrible idea. See above. There are places where it will be required. (ii) There is, at best, much less consensus that use of non-2606 names in narrative or illustrative examples is likely to be harmful. There may be consensus that it is impolite (or, to quote some recent IESG comments, rude) but that is, IMO, a rather different matter. (iii) The IETF has indicated enough times that domain names, not literal addresses, should be used in both protocols and documents that doing anything else should reasonably require clear and strong justification. I'm not sure that this is a reasonable statement of the consensus, even of the weak consensus. I think we normally like to have examples cover common cases; if literals are common in the actual protocol use, forcing the examples to use FQDNs is unhelpful. We could use FQDNs in SDP examples, to take one common case, but the reality is that these usually use IP addresses. The relevant ABNF is: unicast-address = IP4-address / IP6-address / FQDN / extn-addr from RFC 4566, so FQDNs could clearly be used in SDP examples. But doing so is no favor to the actual implementors that might read the docs. (iv) If someone wants to use non-2606 names, it is entirely reasonable to expect them to explain why and to do so in public. If that drives editors and WGs to take the path of least resistance and use the 2606 names, I think it should be fine with all of us. FWIW, please note the philosophical similarity between the above and RFC 4897. In both cases, we move away from incentives for elaborate procedures and private negotiations between the IESG and authors (and the consequent late-stage guessing about what is likely to happen). Instead, we get the issues and justifications up front as part of document processing or in the document itself so that the community can address them as part of Last Call. The IESG can then make decisions based on evidence of community consensus (or community indifference, as the case may be). I think that is supposed to be what we all want around here, isn't it? I certainly share your goals: avoiding elaborate procedures and private negotiations between the IESG and the authors. I remain concerned, though, that this formulation still looks like justify yourself to the IESG rather than satisfy the relevant community you know what you're doing, and the IESG will approve unless the larger
Re: Call for review of proposed update to ID-Checklist
John C Klensin wrote: (iii) The IETF has indicated enough times that domain names, not literal addresses, should be used in both protocols and documents that doing anything else should reasonably require clear and strong justification. I take issue with that as a general statement. There are plenty of applications where the ability to use literal addresses on an occasional basis is quite useful - e.g. for diagnostic purposes (of various kinds) or in a pinch when DNS is broken or not set up correctly. Furthermore addresses are precise where domain names are not. To remove the capability to use address literals is to cripple our protocols. (your other three points seemed fine to me) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
--On Wednesday, 09 July, 2008 14:25 -0700 Ted Hardie [EMAIL PROTECTED] wrote: At 2:03 PM -0700 7/9/08, John C Klensin wrote: I propose the following as alternative text: A nit with this: 6. Addresses used in I-Ds SHOULD use fully qualified domain names (FQDNs) instead of literal IP addresses. Working Groups or authors seeing exemptions from that rule MUST supply the rationale for IP address use with inline comments (e.g., Editor's note: or Note in Draft: that can be evaluated by the IESG and the community along with the rest of the document. Domain names in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). I believe that this must say Example domains in pseudo-code, actual code segments, sample data structures and templates, specifically including MIB definitions and examples that could reasonably be expected to be partially or entirely copied into code, MUST be drawn from the list reserved for documentary use in BCP32 (RFC 2606 or its successors). Without that, it might be read to force things like the domains in XML namespaces to fit this rule. Those are, after all, things that might be partially or entirely copied into code. Amendment gratefully accepted. I meant to say explicitly that I hadn't spent nearly enough time on that text to have any confidence that it was either exactly correct or not in need or wordsmithing and then sent it too soon. I am certain it could be improved by wordsmithing and am not surprised that there were cases I failed to consider. The main point I was trying to make is that it really is possible to parse this issue in a way that separates the read problems/ risk/ harm from matters of taste and that replaces a vague SHOULD (and now you get to guess what will be accepted) into a requirement for explanations and opportunity for community review. A bit more below. It is generally desirable for domain names used in other I-D discussion ... Now, that is somewhat longer and more complicated, but it would seem to satisfy the criteria that have been discussed on the IETF list, not just since the ID-Checklist update draft was posted, but over the last six weeks or so. In particular: (i) I believe that there actually is consensus that use of non-2606 names in places where they are likely to be copied into production code (even if only by the lazy or careless) is likely to be harmful as well as a terrible idea. See above. There are places where it will be required. Yes. I think your correction fixes the problem. ... (iii) The IETF has indicated enough times that domain names, not literal addresses, should be used in both protocols and documents that doing anything else should reasonably require clear and strong justification. I'm not sure that this is a reasonable statement of the consensus, even of the weak consensus. I think we normally like to have examples cover common cases; if literals are common in the actual protocol use, forcing the examples to use FQDNs is unhelpful. We could use FQDNs in SDP examples, to take one common case, but the reality is that these usually use IP addresses. The relevant ABNF is: unicast-address = IP4-address / IP6-address / FQDN / extn-addr from RFC 4566, so FQDNs could clearly be used in SDP examples. But doing so is no favor to the actual implementors that might read the docs. You are right of course. Better text is welcome if we can agree on the principle. It may also be that, if we are going to permit addresses, some words in the Checklist about preferences for IPv4, IPv6, or parallel examples would be in order. ... I think that is supposed to be what we all want around here, isn't it? I certainly share your goals: avoiding elaborate procedures and private negotiations between the IESG and the authors. I remain concerned, though, that this formulation still looks like justify yourself to the IESG rather than satisfy the relevant community you know what you're doing, and the IESG will approve unless the larger community objects. But that is a much larger issue. I had hoped it would be at least justify yourself to the community and then let the IESG make judgments about community consensus rather than any of the variations on let the IESG reach a decision independent of the community. The question of what the IESG should do (or might be expected or required to do) in the absence of any community consensus is, as you say, a much larger issue. regards, john ___ Ietf mailing
Call for review of proposed update to ID-Checklist
From the discussion just prior to the recent appeal by John Klensin, it was clear that the guidance regarding example domain names in IETF documents provided in the ID-Checklist needed to be updated. This point was emphasized further during the discussion of the Klensin appeal. Proposed text is now available. Many thanks to Bert Wijnen for continuing to edit the document. The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The proposed text can be obtained via http://www.ietf.org/Draft-ID-Checklist.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
IETF Chair wrote: From the discussion just prior to the recent appeal by John Klensin, it was clear that the guidance regarding example domain names in IETF documents provided in the ID-Checklist needed to be updated. This point was emphasized further during the discussion of the Klensin appeal. Proposed text is now available. Many thanks to Bert Wijnen for continuing to edit the document. 1. Document scope and force This isn't a 'nits' or 'checklist' document. It is a formal specification of requirements for RFC format and style, per All Internet Drafts which are offered for publication as RFCs must conform to the following requirements or they will be returned to the author(s)/editor(s) for revision. That's fine, but that reality should be cast clearly, directly and from the start, including the Abstract. It also suggests that the document needs to receive a full IETF consensus approval. Small point of confusion: I thought the RFC document series was managed with some independence of the IETF. As such, I'm not clear how the IETF (nevermind the IESG) can set the rules for RFC format and style. Please note that this is not meant to challenge the benefit of having clear and precise formal statement of RFC format and style. It's just that it would be helpful to be clear about who is in charge, what the scope is, and whether the formal rules for decision-making are being followed. 2. Normative language The document uses normative language, some is in upper case and some is not. The document needs a careful pass for its use of normative language, to make it consistent and unambiguous. An interesting current example is 3.1.A: most abbreviations must be expanded on first use. Semantically, I believe this means abbreviations SHOULD be expanded on first use. Simpler, clearer... 3. Confusion of goals The document includes advice that might be quite a good idea, but it has nothing to do with RFC format or 'style' in the sense that a nits program can check. For example Avoid IPv4 specificity. sounds reasonable but is a massively generic suggestion. Does it really belong in something supposedly getting at formatting issues? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
On 7/8/08 at 11:44 AM -0700, IETF Chair wrote: The IESG solicits comments on this proposed update. The IESG plans to make a decision on this proposed text on 2008-07-17. Please send substantive comments to the ietf@ietf.org mailing lists by 2008-07-16. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Insert in the Introduction, before or at the beginning of Notes: - This memo uses the terms MUST, REQUIRED, SHOULD, and RECOMMENDED, similarly to the use of these terms in RFC 2119. In particular, when they appear in ALL CAPS in this memo: -MUST or REQUIRED means that if you do not do this in your I-D, the IESG will not accept the I-D for any review until the item is complete. - SHOULD or RECOMMENDED means that there may be valid reasons to ignore the item, but an explanation must be given, either in the text of the document or as part of the submission to the IESG, as to why the item is being ignored. Otherwise, the IESG may not accept the I-D for review. - This text both (a) puts draft authors on notice as to what the hard requirements are in order to avoid late surprises, and (b) puts reviewers of this memo on notice so that consensus can be reached on what are or are not real showstoppers for IESG review. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
The document says: If ABNF is used, you MUST include a normative reference to RFC 4234. To quote two fine radio personalities here in the states, this one seems boogus. Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Call for review of proposed update to ID-Checklist
Mmm... as editor of the document, maybe I should explain how this document came into existence several years ago. It was back then that the IESG got many many documents that had a lot of these simple (and easy to fix) issues. Some look like showstoppers, others are not so much showstoppers, but they do take extra time (of many people) if they need to be fixed once the document goes into IETF Last Call. So in order to try and make doument authors/editors and also WG chairs aware of what the many little errors were that we as IESG often saw, we composed this document. Hope this helps, Bert Wijnen -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Pete Resnick Verzonden: dinsdag 8 juli 2008 21:28 Aan: ietf@ietf.org CC: IETF Chair; [EMAIL PROTECTED] Onderwerp: Re: Call for review of proposed update to ID-Checklist The document says: If ABNF is used, you MUST include a normative reference to RFC 4234. To quote two fine radio personalities here in the states, this one seems boogus. Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ 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: Call for review of proposed update to ID-Checklist
Hi. I'm likely to have some other comments on this once I get through studying it, but the recent notes from Pete and Dave make a start on some of them. Rather than trying to put together a single long note... --On Tuesday, 08 July, 2008 14:17 -0500 Pete Resnick [EMAIL PROTECTED] wrote: ... Insert in the Introduction, before or at the beginning of Notes: - This memo uses the terms MUST, REQUIRED, SHOULD, and RECOMMENDED, similarly to the use of these terms in RFC 2119. In particular, when they appear in ALL CAPS in this memo: -MUST or REQUIRED means that if you do not do this in your I-D, the IESG will not accept the I-D for any review until the item is complete. - SHOULD or RECOMMENDED means that there may be valid reasons to ignore the item, but an explanation must be given, either in the text of the document or as part of the submission to the IESG, as to why the item is being ignored. Otherwise, the IESG may not accept the I-D for review. - This text both (a) puts draft authors on notice as to what the hard requirements are in order to avoid late surprises, and (b) puts reviewers of this memo on notice so that consensus can be reached on what are or are not real showstoppers for IESG review. While I agree, I believe that it would be of great help if the IESG gave indications of the situations in which an exception to a SHOULD would be appropriate. The last thing the community needs, as a consequence of this document or otherwise, is to expand the basis on which the IESG can block a document for reasons that are essentially non-technical and that come as a surprise to authors. For at least the MUST list, if we are going down this path, it would be good to improve efficiency and reduce AD workload by getting the IESG out of the loop entirely. As an alternative, as Pete suggested about one specific case in a different note, treat a MUST as note and move on, with final approval contingent on getting the issue fixed. In other words, if something is a MUST condition, then either the document shepherd, the secretariat, or both should be able to verify that condition and block or flag the document if it is not met. We should not be wasting AD time that way unless the ADs really have nothing better to do with their time. IMO, the IESG should be spending energy evaluating only those conditions that require judgment as to appropriateness, i.e., the SHOULDs. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
On Tue, Jul 08, 2008 at 02:27:41PM -0500, Pete Resnick wrote: The document says: If ABNF is used, you MUST include a normative reference to RFC 4234. To quote two fine radio personalities here in the states, this one seems boogus. Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. Stupid question isn't this specific thing something we should allow the secretariat to fix as part of the RFC publishing process, and in fact give them instructions to add the reference if they find it missing? They do things like fix/update references IIRC, and this is only a minor step beyond that, and should be well within their capabilities, I would think. Sure, we can ask document editors to add the reference to RFC 4234, and maybe we can even do things like include a reference to RFC 4234 in an RFC template file with a note to remove if the standard ends up not using ABNF, but there must be a class of things which could be streamlined to save time on both the document editors, reviewers, and AD's time. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
On 2008-07-09 07:08, Dave Crocker wrote: ... Small point of confusion: I thought the RFC document series was managed with some independence of the IETF. As such, I'm not clear how the IETF (nevermind the IESG) can set the rules for RFC format and style. I view the id-checklist as a gating factor for IESG review, not as instructions to the RFC Editor. Of course it should be consistent with the RFC Editor's practice, as a matter of common sense. The introduction should make this clear, perhaps. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
Pete Resnick wrote: The document says: If ABNF is used, you MUST include a normative reference to RFC 4234. To quote two fine radio personalities here in the states, this one seems boogus. Yes, any I-D that uses ABNF must include a normative reference to RFC 4234 The ID-Checklist should pass a simple IDnits test, which would point out that RFC 4234 was obsoleted by RFC 5234 six months ago (IIRC). The ID-Checklist should exist in plain text format. The output was obviously created by xml2rfc, which can also create plain text, and plain text can be processed by IDnits. It can be also processed by rfcmarkup to create the simple HTML working with older browsers. It can be also processed by various cute I-D diff tools, allowing reviews of small changes. Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
