Re: IANA considerations and IETF Consensus
I also have the experience that a too strict policy can be harmful. I could cite numerous examples... On the other hand, Thomas and Pasi are also right that too loose policy can be harmful. You have to remember that interoperability can be hurt or improved in many ways. Secret code allocations, private specifications, etc. are indeed a problem. But so are incompatible extensions, multiple ways of doing the same thing, etc. My experience of the current number system is that it is actually working fairly well. There are exceptions, but by and large numbers are allocated and used as they should be. I know we do not have the IEPF (Internet Engineering Police Force) to send when someone uses a number against our approved RFCs, but at least in my experience in Internet layer matters such allocations are relatively rare. I would be interested in actual data about this, if anyone has some, however. I would like to see a model that has an appropriate level of strictness... and I have a model in mind. I do not like the idea of wholesale redefinition of who can allocate numbers or what the various RFC 2434 phrases mean. The different number spaces are different, and we need to apply different criteria for allocations in them. For instance, its a completely different thing to create new optional-to-recognize data attributes than new message types; IP protocol numbers are a scarce resource whereas some other resources are not, etc. And, appropriately, authors and working groups have been laying out the rules in the IANA Considerations section for years and years about what allocation policies are right. I think we need to respect the wisdom of the WG to decide on a policy issue in their protocol. We should continue to give the power to the working groups on this issue. At the same we need to recognize that we've made mistakes in this space in the past, either in the WGs or through IESG or AD requirements. In many cases, policies have been too strict. In some cases they have been not defined well enough to actually work. In yet other cases they have been too loose. Or silly, such as the policy in RFC 2780 about IPv4 protocol number allocations involving NDAs. So here's my proposal: 1) Design new protocols in a way that mere field size is not an issue. I think we've been mostly doing this since mid-90s. 2) Make sure WGs think hard about the various interoperability tradeoffs and other issues when they write their IANA considerations sections. 3) Involve the WG chairs and ADs in following what is happening in the real world, and to take action if what is deployed out there starts to differ too much from what either the IANA registry or the IETF RFCs describe. For instance, we had this situation in EAP WG a couple of years ago, and started a program to make sure all EAP methods were in the IANA table and described in RFCs, created a new WG, AD sponsored some specifications, offered reviewers and IESG support if people took their specifications to the RFC Editor, etc. 4) Make sure there is ample space for experimentation and research. Often there isn't. Consider publishing an update to make this happen. We did this for many IP layer numbers in RFC 4727, for instance. 5) Add sufficient mechanisms for vendor-specific or private numbers. 6) Periodically review the existing IANA rules for your protocols and consider revising them for the right balance. Again, all-strict and free-for-all are probably the wrong policies; different numbers need different treatment. Getting the balance right may not always be easy, but its worthwhile. Taking another example from EAP, we went from free-for-all to no-allocations-until- wg-revises-base-spec to expert-review in the EAP method space. The expert review model has worked well for this particular purposes, because it does not block allocation or make unreasonable requests, but it does ensure there's documentation about the method and that the documentation answers the right questions. 7) Keep relatively strict rules on number spaces that are scarce. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA considerations and IETF Consensus
At 12:25 PM -0700 6/12/07, Thomas Narten wrote: Some general comments on this thread. I understand the argument that some make that we should just give out code points in all cases, because otherwise we invite squatting. That is one reason to give out code points liberally, but not the only one. The reason that both John Klensin and I gave (and I think Dave Crocker echoed) is that giving out code points liberally increases interoperability. It gives developers stronger confidence that the registry is both correct (no overlapping values due to registration race conditions gated on RFC publication) and complete (no squatting). On the other hand, I do believe that withholding code points does prevent (in some, but not all cases) use of extensions that are potentially problematical. As one concrete example, other SDOs are generally hesitant to endorse/use protocols that have not been properly granted code points. This has been a carrot/stick in the past to get those SDOs to come to the IETF with the work rather than just having them embrace and extend our protocols. Doing so inherently causes lack of interoperability during the carrot-stick dance, and often for a long time after the dance is over. That probably helps the IETF leadership but hurts developers of our protocols. Do you think this is not useful/necessary or that it can be done in other ways? It is probably not necessary but it is probalby useful nonetheless. A different way to achieve the carrot-stick goal might be to use the registry to list the IETF's perceived soundness of the codepoint's registration. Stanards-track RFC, Informational RFC, Outside spec; see URL, Outside spec; believed to be unstable by the IESG on mm/dd/yy, Outside spec; believed to have serious technical issues; see http://www.iesg.org/comments/, and so on. Also, if one thinks that code points should just be given out in all cases, how do we deal with stuff like RFC 3427? That's a straw-man; no one on this thread said in all cases. There are at least two cases where liberal registration are not good: - A limited-size namespace (usually protocols written pre-1995) - A namespace where the names have significant semantic value (microsoft, better-auth, ...) And, does this also mean, for example, that anyone should be granted ICMP code points? Are you really calling for essentially granting code points to anyone who asks? No. In order to achieve interoperability, stable documentation of the definition of the codepoint should always be required. Additional commentary from the IESG and/or IAB might also be useful. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Brian E Carpenter wrote: I'm hesitant to relaunch this thread, but there are a number of points that incite me to comment. Since there's been a fair amount of repetition, may I ask people only to chime in with new thoughts? ... Joe Touch wrote: ... [re a mandatory section in all drafts] The goal of putting it in the template is to encourage it be addressed, rather than forgotten altogether. However, I'm not at all in favor of requirements to IDs that are added ad-hoc; until this actually makes it into an RFC as a formal requirement, it won't be in the word template I manage. I don't agree that all operational requirements need to be in process RFCs as formal requirements. We need to give the IESG of the day some freedom to adapt requirements to current conditions. I felt that the requirement for IANA Considerations was a fine idea when it was introduced, and certainly nothing that needed to be BCPized. Well, all other requirements for IDs and RFCs are described as formal requirements in RFC 2223. Your assertion goes to the whole issue of process, and how much leeway the IESG is given to develop - and then enforce - process changes without input from the IETF. I don't accept kings, even those on the IESG. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Bruce Lilly [EMAIL PROTECTED] writes: Unless I misunderstood your earlier comments, Ned, you suggested that the requirement should be dropped. Which would presumably mean that the idnits check against that requirement would be dropped, and then there would be the very real possibility, nay probability, that a draft with no IANA considerations section would get through review even if there is something that should be addressed by IANA. Actually, the original reason for adding this was to avoid the observed-in-practice behavior on IESG telechats: Q: Does this document have an IANA issues? A: um, I dunno, I can't remember now (since this is one of many documents) A non-existant IANA Considerations section is taken as a flag that maybe there are, but they haven't been called out. Sure, in some cases, it's obvious there are no IANA issues, and the IESG would just approve the document. But for any half-way long technical document, making such determinations is non-trivial. Really! So, if one leaves out the IANA considerations section, authors run the risk that their document will be delayed in the IESG while clarification is obtained about whether there are IANA issues. I continue to be mystified by the overall thrust of much of this thread when the implication of not having an IANA considerations section is an increased probability of needless delay, something I thought the community wanted to avoid. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Brian E Carpenter [EMAIL PROTECTED] writes: I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. All implementation-necessary constants should be in the RFC. That is a given. But they typically already will be even if the IANA considerations is effectively: This document makes no new IANA registrations. (i.e., when publishing an revised/updated Proposed Standard) I'm somewhat torn on how much to leave in the final RFC, especially if a statement (like the above) seems to contain little information. But from experience, I'll point out that anyone that has ever tried to reconstruct the history for a particular registry by looking at RFCs knows this can be extremely challenging. Including explicit notes that say seemingly little can speed up this process. Unfortunately, even with good IANA web pages, its sometimes necessary to go back through the RFC trail to figure out what is really going on. And, at the end of the day, RFCs are our archival history. So that is the logical place to be archiving such things. (We don't currently have any other way.) Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Mon, 11 Jul 2005, Paul Hoffman wrote: At 8:15 PM +0200 7/11/05, Brian E Carpenter wrote: Paul Hoffman wrote: At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. But neither does a section that says there are no new values registered. The presence of a null section only says this document didn't cause any new registrations by its publication. A section that says here are the IANA registries that are relevant to this document would be useful to that implementer. We have never tried that, and I suspect it would take a lot of energy and thinking to do so. When this issue came up in the context of review guidelines for MIB documents, the MIB Doctors attempted to craft recommendations that would achieve precisely this. The results are in Section 3.5 of draft-ietf-ops-mib-review-guidelines-04.txt, which is now in the RFC Editor's queue awaiting publication as a BCP. Maybe this can serve as a running code template of what to do in other cases. On Tue, 12 Jul 2005, Thomas Narten wrote: All implementation-necessary constants should be in the RFC. That is a given. But they typically already will be even if the IANA considerations is effectively: This document makes no new IANA registrations. (i.e., when publishing an revised/updated Proposed Standard) I'm somewhat torn on how much to leave in the final RFC, especially if a statement (like the above) seems to contain little information. For the record, I am strongly opposed to such statements remaining in published RFCs, and it will be noted that the text in Section 3.5.3 of draft-ietf-ops-mib-review-guidelines-04.txt specifically recomments that such statements be included in drafts as editor's notes that are to be removed upon publication. However, the guidelines also recommend that text describing the IANA-registered values used (with the names of the registries where they reside) remain in the final published document. Continuing to quote from Thomas Narten's message of Tue, 12 Jul 2005: But from experience, I'll point out that anyone that has ever tried to reconstruct the history for a particular registry by looking at RFCs knows this can be extremely challenging. Including explicit notes that say seemingly little can speed up this process. Unfortunately, even with good IANA web pages, its sometimes necessary to go back through the RFC trail to figure out what is really going on. One question of this nature did arise in the first practical application of the recommendations in Section 3.5.3 of draft-ietf-ops-mib-review-guidelines-04.txt, viz.: % The IANA has reviewed the following Internet-Draft which is in % Last Call: draft-ietf-adslmib-gshdslbis-10.txt, and has the % following with regards to the publication of this document: % % We understand this document to not request any NEW IANA Action. % Should the reference for transmission number 48 for % hdsl2ShdslMIB be changed to become this document or should the % reference remain [RFC3276]? After some discussion the policy that the MIB Doctors recommended that the original reference be retained (i.e., no change to current practice). The reasoning was that this is less work for the IANA than making an update, and if the registries consistently point to the the document responsible for the _initial_ assignment, one can always work through the chain of RFC updates if there is a need to reconstruct the history (this assumes of course that the RFCs state what parameters they use and in which registries they can be found). Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
I'm hesitant to relaunch this thread, but there are a number of points that incite me to comment. Since there's been a fair amount of repetition, may I ask people only to chime in with new thoughts? Paul Hoffman wrote: At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. C. M. Heard wrote: ... RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In what venue will this discussion take place? I think it has to be this list, absent a relevant WG. Joe Touch wrote: ... [re a mandatory section in all drafts] The goal of putting it in the template is to encourage it be addressed, rather than forgotten altogether. However, I'm not at all in favor of requirements to IDs that are added ad-hoc; until this actually makes it into an RFC as a formal requirement, it won't be in the word template I manage. I don't agree that all operational requirements need to be in process RFCs as formal requirements. We need to give the IESG of the day some freedom to adapt requirements to current conditions. I felt that the requirement for IANA Considerations was a fine idea when it was introduced, and certainly nothing that needed to be BCPized. Ned Freed wrote: ... I also predicted that two things would happen: (1) A draft containing IANA considerations and an empty IANA considertions section would be approved and (2) That this section would take on the status of boilerplate in some draft templates. Both predictions have now come to pass. If true, (1) means that a mistake was made by several successive layers of review. (2) is beside the point. But... Bruce Lilly wrote: ... You can make it three: mine says: This memo adds no new IANA considerations. The presence of this template text indicates that the author/editor has not actually reviewed IANA considerations. Yes. Great idea. I updated my own XML template similarly. Ned Freed wrote: ... As I expect you know, the IANA checks all documents at Last Call time, and the RFC Editor checks them before publication, for missing missed IANA actions. However, redundancy does not seem to me to be a bad idea. Of course I know this. But the tendency will be for the text to be believed and for the review to be less thorough. Ditto if it becomes known that the *next* reviewer's check list includes check for overlooked IANA issues: Y/N You're fighting human nature here, and you're gonna lose. Always. The question is, what's the least bad compromise? Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jul 11, 2005, at 11:15 AM, Brian E Carpenter wrote: I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. Personally, I never wonder whether there are any IANA-defined values in a specification. I do wonder from time to time what numbers are appropriate for various uses (gee, this is the IP protocol, and I want to say that the interior header is TCP. How does one say that?), and when I want to get a new number I wonder how to go about getting one. Once it is assigned, I'm afraid I don't much care who assigned it or by what process. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
At 8:15 PM +0200 7/11/05, Brian E Carpenter wrote: Paul Hoffman wrote: At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. I respectfully disagree. I think that someone implementing or deploying a given specification may well wonder whether any IANA-assigned values are relevant, and the absence of a null section in an RFC doesn't help with that. But neither does a section that says there are no new values registered. The presence of a null section only says this document didn't cause any new registrations by its publication. A section that says here are the IANA registries that are relevant to this document would be useful to that implementer. We have never tried that, and I suspect it would take a lot of energy and thinking to do so. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Thu, 7 Jul 2005, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. Right. The requirement for null IANA Considerations sections first appeared in the May 2004 version of http://www.ietf.org/ID-Checklist.html, without prior notice to the community. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In what venue will this discussion take place? While I can understand the value (to the IANA) of a null IANA Considerations section in an Internet Draft, I'm strongly opposed to having them appear in published documents. Mike Heard ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA considerations
John Klensin wrote: That said, I think we should be paying careful attention to Bruce's implied suggestion about how template boilerplate-generators should be constructed. Some clarification: 1. In the specific case of the troff/nroff rfc macros and template, Ned's characterization of the text as boilerplate is inaccurate. True boilerplate (IPR boilerplate, Copyright notices, Status of this Memo, RFC-Editor funding Acknowledgment, even the canned versions of IESG notes) are contained in the macro package, not visible in an author/editor's source document and not emitted until the document is formatted. The template is provided as a convenience for authors/editors, and has some template text corresponding to the basic recommended RFC structure, some hints on how to do things such as include text that is present in a draft but disappears in RFC form (e.g. a draft change history), etc. An author/editor is of course free to ignore the template completely, using the macros with a source document created from scratch, or modified from another source document. The case might well be different for other means of generating drafts and RFCs, where a boilerplate characterization might be apropos, but it is not in this instance. Placeholder would be a suitable term. 2. I posted what I had put in the template; others are of course free to do nothing at all, to do something completely different, to do something similar, or even to use the same text verbatim (it is not copyrighted). I added the ...presence of this template text... part about 3 weeks ago during early parts of this discussion. I thought it was a reasonable thing to do at the time, and I still think so (if anything, I might be inclined to remove or comment out the no IANA considerations text, which is in fact suggested wording for that specific case and it appears on a single source line with the other text (so failure to edit gets the whole thing, and explicit action is required to make any change, whether that's to remove the warning or to substitute real considerations). I'm not presuming to suggest that others should do likewise. They are free to do so, but to the extent that some people think that I'm some sort of whacko, they might be inclined to do something contrary, and they are of course also free so to do. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Date: 2005-07-06 21:12 From: Bill Strahm [EMAIL PROTECTED] I actually would prefer IANA Considerations This section left intentionally blank That contains at least one certain inaccuracy: it's there, which contradicts left ... blank. Unless you have a bulletproof way of ascertaining intentions (as opposed to apathy, petulance, and/or laziness), it may contain an additional inaccuracy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Date: 2005-07-06 14:43 From: Ned Freed [EMAIL PROTECTED] This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. I can't speak for others, but 1. if a draft has no IANA considerations section, idnits will so indicate (but see below), and that's a warning sign to check -- if idnits is run. Of course, one would expect conscientious authors/editors to a) abide by the guidelines (which is where the MUST include an IANA considerations section is specified) b) check against the I-D Checklist c) run idnits but obviously some authors/editors do not do so, and not all reviewers check vs. the Checklist and/or run idnits 2. if a draft has a no IANA considerations text, that certainly prompts this reviewer to check that statement for accuracy At the moment (see below), that means that if there is no IANA considerations section at all, idnits will flag that fact and if there is such a section it will be reviewed; either way *seems* to result in review of the draft w.r.t. IANA considerations. I suppose. That said, if IANA considerations was *not* built into the boilerplate, it would have a high likelihood of being omitted. Which would then be noted on checklist review, causing a fairly careful check to be made to see if there really aren't any considerations to be listed in such a section. Unless I misunderstood your earlier comments, Ned, you suggested that the requirement should be dropped. Which would presumably mean that the idnits check against that requirement would be dropped, and then there would be the very real possibility, nay probability, that a draft with no IANA considerations section would get through review even if there is something that should be addressed by IANA. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
I suppose. That said, if IANA considerations was *not* built into the boilerplate, it would have a high likelihood of being omitted. Which would then be noted on checklist review, causing a fairly careful check to be made to see if there really aren't any considerations to be listed in such a section. Unless I misunderstood your earlier comments, Ned, you suggested that the requirement should be dropped. I have never suggested that the requirment for an IANA considerations section in documents that contain IANA considerations be dropped. Nor have I ever suggested that review for IANA considerations be dropped. On the contrary, such review is essential. Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. and then there would be the very real possibility, nay probability, that a draft with no IANA considerations section would get through review even if there is something that should be addressed by IANA. Doesn't follow. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). I disagree. I think it will over time come to have exactly the opposite effect. Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. Sigh. More boilerplate BS, more unnecessary nonsense, more disincentives for authors, less and lower quality review, and fewer and poorer documents. This is absolutely the wrong path for us to be on. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Thu July 7 2005 15:32, Ned Freed wrote: I have never suggested that the requirment for an IANA considerations section in documents that contain IANA considerations be dropped. The specific requirement is for the presence of a section in an I-D presented for publication as an RFC even in the case that there are no IANA actions. Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. idnits generates a warning because there is a requirement for such a section. I don't think it is reasonable to expect that an automated tool will be able to determine whether or not IANA actions would be required; it is easy to determine whether or not a section is present. Which is all that should be done. If the unconditional requirement for a section goes away, I would expect the test to go away, or to at least require some non-default option to be specified to enable it. Otherwise it will appear when there are in fact no IANA actions and then it will be treated as noise, like the fabled boy who cried wolf. Then by all means only issue the warning when in let's find out what needs to be reviewed mode. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). I disagree. I think it will over time come to have exactly the opposite effect. The only way to tell for sure is to let the experiment run its course. Early indications are that it is already having the opposite effect. Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. Sigh. More boilerplate BS, more unnecessary nonsense, more disincentives for authors, less and lower quality review, and fewer and poorer documents. Not boilerplate, a reminder for authors/editors to consider the issue, and the remainder simply don't follow. I disagree completely. And I believe that further disucssion of this is pointless, so this will be my final note on the topic. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Thu July 7 2005 15:32, Ned Freed wrote: I have never suggested that the requirment for an IANA considerations section in documents that contain IANA considerations be dropped. The specific requirement is for the presence of a section in an I-D presented for publication as an RFC even in the case that there are no IANA actions. Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. idnits generates a warning because there is a requirement for such a section. I don't think it is reasonable to expect that an automated tool will be able to determine whether or not IANA actions would be required; it is easy to determine whether or not a section is present. If the unconditional requirement for a section goes away, I would expect the test to go away, or to at least require some non-default option to be specified to enable it. Otherwise it will appear when there are in fact no IANA actions and then it will be treated as noise, like the fabled boy who cried wolf. And that is precisely why several people have been advocating the rule, namely that it prompts review of the issue (whether or not a particular author/editor adheres to the rule). I disagree. I think it will over time come to have exactly the opposite effect. The only way to tell for sure is to let the experiment run its course. Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section, many documents do not include one even where internationalization is an issue. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. That is another matter, as is whether or not a published RFC should contain a null internationalization considerations section. Sigh. More boilerplate BS, more unnecessary nonsense, more disincentives for authors, less and lower quality review, and fewer and poorer documents. Not boilerplate, a reminder for authors/editors to consider the issue, and the remainder simply don't follow. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Commenting only on the idnits specific issue here: On 2005-07-07 22:08 Bruce Lilly said the following: On Thu July 7 2005 15:32, Ned Freed wrote: [...] Which would presumably mean that the idnits check against that requirement would be dropped, On the contrary, it is important that automated tools warn that such sections are missing. This warning should not prevent a document from being last called, however. idnits generates a warning because there is a requirement for such a section. I don't think it is reasonable to expect that an automated tool will be able to determine whether or not IANA actions would be required; it is easy to determine whether or not a section is present. Right. If the unconditional requirement for a section goes away, I would expect the test to go away, or to at least require some non-default option to be specified to enable it. Otherwise it will appear when there are in fact no IANA actions and then it will be treated as noise, like the fabled boy who cried wolf. Yes. When http://www.ietf.org/ID-Checklist.html changes, idnits is updated to match. Otherwise, the tool would swiftly become useless. Henrik ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Bruce Lilly wrote: BCP 18 (RFC 2277, Frank) recommends an internationalization considerations section Oh, that beast, a MUST UTF-8, not less. Didn't make it into RfC 3912, can I declare it broken by design and return to RfC 954, please ? It took me hours to find RfC 1032 for RFCI. While we're at it, did you see draft-hoffman-utf8-rfcs-00.txt ? OTOH Paul saw no problem to submit some I-Ds without a dummy IANA section - and for gopher I even asked, after all there is this IANA URI scheme registry, they might wish to update it. If the IETF feels that internationalization is an important issue, a similar guideline prompting authors/editors to include, and reviewers to review such a section might be worth adding. Maybe. OTOH it wouldn't be polite to write SMTP error texts are i-default US-ASCII, stupid, so that's what you put in an SPF exp= explanation, for more I18N you could use a http URL. Thinking about IANA doesn't upset me, it's rather harmless, just one of the dozens of nits distributed in at least three obscure texts, none of them an RfC. The IPR boilerplate makes me mad, but unfortunately the authors of xml2rfc didn't adopt my ipr=fullmeep or ipr=fulleula proposals. Insert four-letter word for meep. At most three lines pointing to a creative commons BY SA license should be good enough for most I-Ds. Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed wrote: Can anyone suggest where I could find the requirement for IANA Considerations? There is no requirement that such sections appear in published RFCs. This debate has never been about what's required in RFCs, but rather what's required in drafts submitted to the IESG. RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. Brian I found it on the website, but it's not listed in any RFC (just in an expired ID, one that even mentions that empty IANA Considerations sections may be dropped by the RFC Editor upon RFC publication). The requirement on the website is what we've been discussing. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed wrote: Can anyone suggest where I could find the requirement for IANA Considerations? There is no requirement that such sections appear in published RFCs. This debate has never been about what's required in RFCs, but rather what's required in drafts submitted to the IESG. Why are there additional, _unpublished_ requirements to IDs? I found it on the website, but it's not listed in any RFC (just in an expired ID, one that even mentions that empty IANA Considerations sections may be dropped by the RFC Editor upon RFC publication). The requirement on the website is what we've been discussing. Ned Why is the website inconsistent with the published requirements? I t seems like the need for the IANA Considerations section should be withheld until it is actually formally issued as a requirement. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Brian E Carpenter wrote: Ned Freed wrote: Can anyone suggest where I could find the requirement for IANA Considerations? There is no requirement that such sections appear in published RFCs. This debate has never been about what's required in RFCs, but rather what's required in drafts submitted to the IESG. RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. Brian It seems like such considerations are, by definition, relevant only for standards-track RFCs. It is not useful to require it for other documents. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
In message [EMAIL PROTECTED], Joe Touch writes: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) It seems like such considerations are, by definition, relevant only for standards-track RFCs. It is not useful to require it for other documents. Not at all -- code points can be assigned by non-standards track RFCs. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Joe, It seems like such [IANA] considerations are, by definition, relevant only for standards-track RFCs. It is not useful to require it for other documents. I think you're correct in general but this is not always the case. Consider URI schemes. I think they're often informational, and in general I see no reason to be otherwise. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jul 6, 2005, at 8:15 AM, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In my new internet draft template, I have some stock text, which I change in the event that I actually need to assign a number to something or create a registry. It reads: section anchor=IANA title=IANA Considerations tThis document makes no request of the IANA./t tNote to RFC Editor: in the process assigning numbers and building IANA registries prior to publication, this section will have served its purpose. It may therefore be removed upon publication as an RFC./t /section Personally, I can't imagine why we need anything more complex or legal-in-form than that. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. I don't see any discussion of the RFC Editor retaining null IANA sections in RFC2434bis, which is good. It is a completely silly idea. An RFC should contain useful, long-lasting information. The fact that a particular document didn't require IANA action is not useful unless it is surprising, and if it is surprising, the section should not be null. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jul 6, 2005, at 11:20 AM, Ned Freed wrote: This is exactly what I predicted would happen - the IANA considerations section has now become part of the boilerplate in at least one I-D template. (Actually make that two - I put in in my own equivalent template some time back.) This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. I suppose. That said, if IANA considerations was *not* built into the boilerplate, it would have a high likelihood of being omitted. This argument is a little like saying that the Security considerations is part of the boilerplate and therefore Security will not be considered even if the document says it was considered. Good grief. The purpose of the IANA section is to make IANA's job easier - if there is something to allocate, they have to read the relevant parts of the document anyway, but if there is nothing for them to consider, they can be told that up front. Given all the work we put into reviews, is it really likely that this will not be reviewed? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jul 6, 2005, at 8:15 AM, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In my new internet draft template, I have some stock text, which I change in the event that I actually need to assign a number to something or create a registry. It reads: section anchor=IANA title=IANA Considerations tThis document makes no request of the IANA./t tNote to RFC Editor: in the process assigning numbers and building IANA registries prior to publication, this section will have served its purpose. It may therefore be removed upon publication as an RFC./t /section This is exactly what I predicted would happen - the IANA considerations section has now become part of the boilerplate in at least one I-D template. (Actually make that two - I put in in my own equivalent template some time back.) This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. Personally, I can't imagine why we need anything more complex or legal-in-form than that. What's require is already way too much. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jul 6, 2005, at 11:20 AM, Ned Freed wrote: This is exactly what I predicted would happen - the IANA considerations section has now become part of the boilerplate in at least one I-D template. (Actually make that two - I put in in my own equivalent template some time back.) This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. I suppose. That said, if IANA considerations was *not* built into the boilerplate, it would have a high likelihood of being omitted. Which would then be noted on checklist review, causing a fairly careful check to be made to see if there really aren't any considerations to be listed in such a section. This argument is a little like saying that the Security considerations is part of the boilerplate and therefore Security will not be considered even if the document says it was considered. Good grief. On the contrary, the cases could not be more different. We believe that is the rare and exceptional document that doesn't have security considerations to discuss. As such, either the presence of a section saying there are no security considerations is a big red flag that immediately triggers a careful security review to make sure there really aren't any. Documents without any IANA considerations, on the other hand, are qutie common and perfectly legitimate. The purpose of the IANA section is to make IANA's job easier - if there is something to allocate, they have to read the relevant parts of the document anyway, but if there is nothing for them to consider, they can be told that up front. Given all the work we put into reviews, is it really likely that this will not be reviewed? Not only is it likely, we have actual running code: draft-ietf-lemonade-mms-mapping-04.txt, recently approved by the IESG (and now the subject of an appeal) contains IANA considerations and an IANA considerations section saying there aren't any. And this happened while this requirement was new and people were still paying attention to some extent. What do you think things will be like a couple of years from now when this whole discussion has been forgotten? I note in passing that all this has been said in previous messages. The only thing new here is the fact that I-D templates are now being constructed containing boilerplate IANA considerations sections, just as I predicted. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Freed wrote: On Jul 6, 2005, at 8:15 AM, Brian E Carpenter wrote: RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis does discuss them, and we will need to form consensus about whether the RFC Editor is required to retain them, as we discuss RFC2434bis. Which we need to do fairly soon. In my new internet draft template, I have some stock text, which I change in the event that I actually need to assign a number to something or create a registry. It reads: section anchor=IANA title=IANA Considerations tThis document makes no request of the IANA./t tNote to RFC Editor: in the process assigning numbers and building IANA registries prior to publication, this section will have served its purpose. It may therefore be removed upon publication as an RFC./t /section This is exactly what I predicted would happen - the IANA considerations section has now become part of the boilerplate in at least one I-D template. (Actually make that two - I put in in my own equivalent template some time back.) This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. The goal of putting it in the template is to encourage it be addressed, rather than forgotten altogether. However, I'm not at all in favor of requirements to IDs that are added ad-hoc; until this actually makes it into an RFC as a formal requirement, it won't be in the word template I manage. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzDwAE5f5cImnZrsRAhwkAJ49KjDTN3ATzGNvm5EtmvKL6fB1qwCeMWp5 py3O+Dbud7Ic9tGUnNECs58= =P6UI -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. The goal of putting it in the template is to encourage it be addressed, rather than forgotten altogether. I am well aware of what the goal is, and have been from the beginning of this discussion. There has never been disagreement as to the goal, only as to the best means to achieve it. I have asserted that requiring IANA considerations sections in drafts submitted for publication is at best useless and potentially quite harmful, and that the best way to insure coverage of IANA issues is to have an explicit check for such things as part of our review process. I also predicted that two things would happen: (1) A draft containing IANA considerations and an empty IANA considertions section would be approved and (2) That this section would take on the status of boilerplate in some draft templates. Both predictions have now come to pass. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ned Freed wrote: This opens the door to the author forgetting to check and the various reviewers assuming the prsence of the sections means a check was done. The goal of putting it in the template is to encourage it be addressed, rather than forgotten altogether. I am well aware of what the goal is, and have been from the beginning of this discussion. There has never been disagreement as to the goal, only as to the best means to achieve it. I have asserted that requiring IANA considerations sections in drafts submitted for publication is at best useless and potentially quite harmful, and that the best way to insure coverage of IANA issues is to have an explicit check for such things as part of our review process. I also predicted that two things would happen: (1) A draft containing IANA considerations and an empty IANA considertions section would be approved and (2) That this section would take on the status of boilerplate in some draft templates. Both predictions have now come to pass. Ned Boilerplate doesn't necessarily include the default text per se; the template I manage has no default, but allows choice of predefined text where available. The default text is selected only by deliberate choice. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCzEH4E5f5cImnZrsRAgqjAJ9/S2Vg+hO7Y4eSNYdQ1Q2xTxHGYgCgkNBQ pDg6eyzGUEeaUlYJPRJom0M= =fbmi -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
* harmful, and that the best way to insure coverage of IANA issues is to have an * explicit check for such things as part of our review process. * Ned, As I expect you know, the IANA checks all documents at Last Call time, and the RFC Editor checks them before publication, for missing missed IANA actions. However, redundancy does not seem to me to be a bad idea. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jul 6, 2005, at 2:19 PM, Bruce Lilly wrote: This memo adds no new IANA considerations. The presence of this template text indicates that the author/editor has not actually reviewed IANA considerations. I like it. Consider my template to have changed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
* harmful, and that the best way to insure coverage of IANA issues is to have an * explicit check for such things as part of our review process. * As I expect you know, the IANA checks all documents at Last Call time, and the RFC Editor checks them before publication, for missing missed IANA actions. However, redundancy does not seem to me to be a bad idea. Of course I know this. But the tendency will be for the text to be believed and for the review to be less thorough. You're fighting human nature here, and you're gonna lose. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
--On Wednesday, 06 July, 2005 15:23 -0700 Bob Braden [EMAIL PROTECTED] wrote: * harmful, and that the best way to insure coverage of IANA issues is to have an * explicit check for such things as part of our review process. Ned, As I expect you know, the IANA checks all documents at Last Call time, and the RFC Editor checks them before publication, for missing missed IANA actions. However, redundancy does not seem to me to be a bad idea. Bob, as I expect you know, the IANA no longer has the staff skills to perform an in-depth analysis of a document to determine whether there are issues IANA needs to deal with. Yes, I think they try, but the whole purpose of this section was to move toward providing them better instructions and hints than go do your own detective work. I'm grateful that the RFC Editor continues to make those checks, but it is in everyone's interest that the IANA actions be understood much earlier in the process, leaving the RFC Editor review as the safety net of last resort. That said, I think we should be paying careful attention to Bruce's implied suggestion about how template boilerplate-generators should be constructed. In terms of the checking process Ned asks for (and which I still believe is the right solution) there is a world of difference between a template that generates: IANA Considerations Nothing for IANA to do and one that generates IANA Considerations If you see this text, the author hasn't gotten around to thinking about this issue. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Date: 2005-07-06 16:16 From: Joe Touch [EMAIL PROTECTED] Ned Freed wrote: This is exactly what I predicted would happen - the IANA considerations section has now become part of the boilerplate in at least one I-D template. (Actually make that two - I put in in my own equivalent template some time back.) You can make it three: mine says: This memo adds no new IANA considerations. The presence of this template text indicates that the author/editor has not actually reviewed IANA considerations. and there's similar text for internationalization and security. This helps a lot less than you'd think. Lots of documents start out with no IANA considerations. Then somewhere along the way they acquire some. The tendency is going to be to change the text to say no considerations the very first thing, and after that not bother to check. I suspect this is what happen in the case of the MMS document, as a matter of fact - the header registry came online between the time the document was first written and when it was approved, which changed the situation from one where there weren't IANA considerations to one where there were some. People aren't machines, and it is mistake to expect them to behave like machines. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
John C Klensin wrote: --On Wednesday, 06 July, 2005 15:23 -0700 Bob Braden [EMAIL PROTECTED] wrote: * harmful, and that the best way to insure coverage of IANA issues is to have an * explicit check for such things as part of our review process. Ned, As I expect you know, the IANA checks all documents at Last Call time, and the RFC Editor checks them before publication, for missing missed IANA actions. However, redundancy does not seem to me to be a bad idea. Bob, as I expect you know, the IANA no longer has the staff skills to perform an in-depth analysis of a document to determine whether there are issues IANA needs to deal with. Yes, I think they try, but the whole purpose of this section was to move toward providing them better instructions and hints than go do your own detective work. I'm grateful that the RFC Editor continues to make those checks, but it is in everyone's interest that the IANA actions be understood much earlier in the process, leaving the RFC Editor review as the safety net of last resort. That said, I think we should be paying careful attention to Bruce's implied suggestion about how template boilerplate-generators should be constructed. In terms of the checking process Ned asks for (and which I still believe is the right solution) there is a world of difference between a template that generates: IANA Considerations Nothing for IANA to do and one that generates IANA Considerations If you see this text, the author hasn't gotten around to thinking about this issue. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf I actually would prefer IANA Considerations This section left intentionally blank Reminds me of some wonderful manuals back in the day (and frankly currently as well) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
That said, I think we should be paying careful attention to Bruce's implied suggestion about how template boilerplate-generators should be constructed. In terms of the checking process Ned asks for (and which I still believe is the right solution) there is a world of difference between a template that generates: IANA Considerations Nothing for IANA to do and one that generates IANA Considerations If you see this text, the author hasn't gotten around to thinking about this issue. As I said in a previous response, this may help a little, but not nearly as much as it might first appear. However, it actually suggests an alternative approach: FORBID the inclusion of an IANA considerations section until the document is ready for general public review, then REQUIRE that one be inserted as part of the review. The problem with this approach is that it isn't really compatible with our processes - there are various paths documents take and various review points, making the selection of the right time for this to happen rather difficult. But perhaps this is just another facet of our more general problem that all too often documents end up in front of the IESG without having undergone sufficient review. If we fix that, we might well make this whole require empty IANA considerations nonsense moot. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Bruce Lilly wrote: Date: 2005-07-06 16:16 From: Joe Touch [EMAIL PROTECTED] ... However, I'm not at all in favor of requirements to IDs that are added ad-hoc; until this actually makes it into an RFC as a formal requirement, it won't be in the word template I manage. I wouldn't call it ad-hoc; it's part of an IESG-generated document on the official IETF web site, Which, as far as process is concerned, isn't quite worth the disk space it occupies ;-) and it also has been documented for quite some time in the draft successor to RFC 2223 also known as instructions2authors. 2223bis is still an ID. Until it's an RFC, this is just a *proposed* change to process, and should be treated as such. Joe signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can anyone suggest where I could find the requirement for IANA Considerations? I found it on the website, but it's not listed in any RFC (just in an expired ID, one that even mentions that empty IANA Considerations sections may be dropped by the RFC Editor upon RFC publication). Joe Ned Freed wrote: Ned Unfortunately so is the presence of an empty IANA Ned considerations section - you cannot tell the difference Ned between such a section that was arrived as as a result of Ned careful review of the draft and one that was simply created Ned as a form of boilerplate. It's actually been my experience that the rate of null IANA considerations sections that should have contained content appears to be significantly lower than the set of missing IANA considerations sections when one should have been included. Based on my perceptions I do think this requirement is triggering some level of review. Hardly a ringing endorsement... And this requirement is quite new. It would be unprecedented if it hadn't triggered some level of initial review in these very early days. But wait a couple of years for the new to wear off and people being people will start to handle it as more boilerplate. Thus as an individual I support the requirement. I do not have rigorous data to support my assertion. Useful data won't be available for several years at least. Which is why it so surprising - and ominous - that the problem has already arisen in at least one document. Ned\ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCyyxmE5f5cImnZrsRAugvAKCFcjok6mX79hNM6b4Pi5T/L59wowCg84H+ TZC5Ht0ELSkrKcJ/SKeieOo= =LkEl -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Can anyone suggest where I could find the requirement for IANA Considerations? There is no requirement that such sections appear in published RFCs. This debate has never been about what's required in RFCs, but rather what's required in drafts submitted to the IESG. I found it on the website, but it's not listed in any RFC (just in an expired ID, one that even mentions that empty IANA Considerations sections may be dropped by the RFC Editor upon RFC publication). The requirement on the website is what we've been discussing. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Dave Crocker wrote: And this requirement is quite new. It would be unprecedented if it hadn't triggered some level of initial review in these very early days. But wait a couple of years for the new to wear off and people being people will start to handle it as more boilerplate. For anyone who was sleeping during the relevant Psych 101 lecture, this is called the Hawthorne effect. Doing anything at all gets folk's attention. Whether the thing, itself, has a real effect is a very separate issue. The IANA Considerations form requirement creates attention on the matter of IANA. But that does not mean that it carries any long-term focus on real IANA issues, any more than the original, vacuous requirement for a Security Considerations section resulted in good security considerations. What improved the security considerations work was requiring that it be real. Indeed. And by analogy, that's why we need to update RFC 2434, which is almost 7 years old. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
At 00:04 26/06/2005, Brian E Carpenter wrote: Indeed. And by analogy, that's why we need to update RFC 2434, which is almost 7 years old. I suggest that all the IANA parts of RFCs are compiled in a parallel document, may be with a reference number to be discussed for a IANA logical classification. They would make the IANA permanent orders everyone could consult. It would probably help standarding the IANA ways what would be usueful to everyone - probably showing initially the complexity of the IANA task to translate the IANA consideration parts as they are often written. But it would probably improve quickly if a IANA Registry management tool/system resulted from it. Maybe in relation with ISO 11179? jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
And this requirement is quite new. It would be unprecedented if it hadn't triggered some level of initial review in these very early days. But wait a couple of years for the new to wear off and people being people will start to handle it as more boilerplate. For anyone who was sleeping during the relevant Psych 101 lecture, this is called the Hawthorne effect. Doing anything at all gets folk's attention. Whether the thing, itself, has a real effect is a very separate issue. The IANA Considerations form requirement creates attention on the matter of IANA. But that does not mean that it carries any long-term focus on real IANA issues, any more than the original, vacuous requirement for a Security Considerations section resulted in good security considerations. What improved the security considerations work was requiring that it be real. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
And this requirement is quite new. It would be unprecedented if it hadn't triggered some level of initial review in these very early days. But wait a couple of years for the new to wear off and people being people will start to handle it as more boilerplate. For anyone who was sleeping during the relevant Psych 101 lecture, this is called the Hawthorne effect. Damn. I knew there was a famous study that identified this effect, but I couldn't remember the name. Doing anything at all gets folk's attention. Whether the thing, itself, has a real effect is a very separate issue. The IANA Considerations form requirement creates attention on the matter of IANA. But that does not mean that it carries any long-term focus on real IANA issues, any more than the original, vacuous requirement for a Security Considerations section resulted in good security considerations. What improved the security considerations work was requiring that it be real. Which in turn works because there are always security considerations - the closest thing to valid empty security considerations section we have is one that says this entire document is about security. A section that simply says there are no security considerations here is invalid on its face and indicates insufficient review has been done. The same isn't true of IANA considerations. It is perfectly valid for a document not to have any, and in fact common. And that completely changes the dynamics of the situation. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Date: 2005-06-23 12:45 From: Ned Freed [EMAIL PROTECTED] Which in turn works because there are always security considerations - the closest thing to valid empty security considerations section we have is one that says this entire document is about security. A section that simply says there are no security considerations here is invalid on its face and indicates insufficient review has been done. Possible counterexamples: RFC 2234: Security is truly believed to be irrelevant to this document. RFC 3935: Considering security is one of the core principles of sound network engineering for the Internet. Apart from that, it's not relevant to this memo. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Jeffrey Hutzelman wrote: On Monday, June 13, 2005 08:25:38 PM -0400 Ralph Droms [EMAIL PROTECTED] wrote: Better yet would be late binding: INSERT LATEST IETF STANDARD FIXED BOILERPLATE. Has anyone actually _read_ the boilerplate in drafts you are submitting? Much of that text affects what rights you have, what rights you grant to the IETF, and what responsibilities you have. It's not just a placeholder; it applies at the time of submission of an I-D, not just at RFC publication time. Correct, and that is why the Note Well text is in your face at various points on the IETF site. Those legal sounding words do actually mean something. xml2rfc saves you the bother of manually inserting the boilerplate, of course. It's more or less late binding. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Monday, June 13, 2005 08:25:38 PM -0400 Ralph Droms [EMAIL PROTECTED] wrote: Better yet would be late binding: INSERT LATEST IETF STANDARD FIXED BOILERPLATE. Has anyone actually _read_ the boilerplate in drafts you are submitting? Much of that text affects what rights you have, what rights you grant to the IETF, and what responsibilities you have. It's not just a placeholder; it applies at the time of submission of an I-D, not just at RFC publication time. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed wrote: On Fri, 10 Jun 2005, Ned Freed wrote: What exactly is it that you think should be done (in addition to careful reviews) that would help reduce the odds that the careful review find issues with the IANA instructions (or lack thereof)? Simple: The requirement that an IANA considerations section be included in RFC not containing any IANA actions needs to be dropped. I have been extremely clear ahout this. It's good, because this is already the case. Even if you're required to add a null IANA considerations section in the internet-drafts when being sent to the IESG, the RFC-editor removes the IANA considerations section completely if it doesn't have any real content. Anything else? It is the requirement that Internet Drafts always contain IANA considerations sections that has to go. Ned, you have not produced any argument for this position, and since the absence of such a section does not imply the absence of IANA considerations, your logic continues to escape me. The argument for the mandatory presence of such a section is that it increases the probability that any IANA considerations have been identified. What the RFC Editor does after document approval is not the issue here. Not for you, maybe, but it is for me. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
It is the requirement that Internet Drafts always contain IANA considerations sections that has to go. Ned, you have not produced any argument for this position, and since the absence of such a section does not imply the absence of IANA considerations, your logic continues to escape me. Repeating for about the fourth time... The argument against it is that requiring the section in the absence of actual IANA considerations simply adds to the amount of required stuff we have in our documents that serves no real purpose. We have way too much of this junk already and attempts to require more need to be resisted. The only reason to have it would as an indicator that a check for IANA considerations was done and none were found. But the problem with that is that there's no way to distinguish between a careful review leading to the prduction of no considerations text and the text being added with little if any review just to make the IESG happy. And we already have at least one example where this appears to have happened. The argument for the mandatory presence of such a section is that it increases the probability that any IANA considerations have been identified. I disagree. I don't think it increases the probability much if at all, and in fact may actually decrease it. And even if it did increase the probability slightly, the benefit of that increase needs to be weighed against the cost, and I don't think it measures up. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned, you have not produced any argument for this position, and since the absence of such a section does not imply the absence of IANA considerations, your logic continues to escape me. Repeating for about the fourth time... Here's my own take: It is empty bureaucracy. It is form, without content. It is additional effort, with no benefit. It is reasonable and necessary to require that documents contain important considerations. This is not accomplished by having pro forma sections lacking content. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Dave, Here's my own take: It is empty bureaucracy. It is form, without content. It is additional effort, with no benefit. It is reasonable and necessary to require that documents contain important considerations. This is not accomplished by having pro forma sections lacking content. I am not a big fan of a lot of the current boiler plate. I would be happy if I could submit drafts with INSERT IETF STANDARD FIXED BOILERPLATE and have it done automatically instead of having to figure out what the boiler plate text to add is. I think the the IANA Considerations section is different as it's contents vary (unlike things like the copyright statement). The argument to requiring it even if there aren't any required IANA actions is similar to why protocols with NACKs don't work. The IANA needs to know in a positive manner that the author considered it. The lack of an IANA considerations section is ambiguous. Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Dave, Here's my own take: It is empty bureaucracy. It is form, without content. It is additional effort, with no benefit. It is reasonable and necessary to require that documents contain important considerations. This is not accomplished by having pro forma sections lacking content. I am not a big fan of a lot of the current boiler plate. I would be happy if I could submit drafts with INSERT IETF STANDARD FIXED BOILERPLATE and have it done automatically instead of having to figure out what the boiler plate text to add is. I think the the IANA Considerations section is different as it's contents vary (unlike things like the copyright statement). The argument to requiring it even if there aren't any required IANA actions is similar to why protocols with NACKs don't work. The IANA needs to know in a positive manner that the author considered it. The lack of an IANA considerations section is ambiguous. Unfortunately so is the presence of an empty IANA considerations section - you cannot tell the difference between such a section that was arrived as as a result of careful review of the draft and one that was simply created as a form of boilerplate. And that's why the costs of requiring null IANA consideratiosn sections outweigh the benefits. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Better yet would be late binding: INSERT LATEST IETF STANDARD FIXED BOILERPLATE. - Ralph On Mon, 2005-06-13 at 15:28 -0700, Bob Hinden wrote: Dave, Here's my own take: It is empty bureaucracy. It is form, without content. It is additional effort, with no benefit. It is reasonable and necessary to require that documents contain important considerations. This is not accomplished by having pro forma sections lacking content. I am not a big fan of a lot of the current boiler plate. I would be happy if I could submit drafts with INSERT IETF STANDARD FIXED BOILERPLATE and have it done automatically instead of having to figure out what the boiler plate text to add is. I think the the IANA Considerations section is different as it's contents vary (unlike things like the copyright statement). The argument to requiring it even if there aren't any required IANA actions is similar to why protocols with NACKs don't work. The IANA needs to know in a positive manner that the author considered it. The lack of an IANA considerations section is ambiguous. Bob ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
from my very humble perspective, it is actually useful to test a -00 draft. The more revisions a draft goes through, the more reticent and author becomes to change it. Getting the test done early makes that job easier. On Jun 10, 2005, at 7:25 AM, Bill Fenner wrote: On 6/9/05, Bruce Lilly [EMAIL PROTECTED] wrote: Conversely, if the IESG does regard the matter as important, it could: 1. direct the IETF Secretariat to enforce the rule Bruce, ID-Checklist is only for I-Ds that are submitted to the IESG for publication. It's not the cost of checking that is a problem, rather, it's useful to allow earlier drafts of I-Ds to not be fully fleshed out (thus they're .. well .. drafts?) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed wrote: ... And in fact there has already been at least one example of this happening. The document draft-ietf-lemonade-mms-mapping-04.txt is now in the RFC Editor's queue. It's IANA considerations section says no IANA actions. Alas, the document defines any number of new header fields that need to be placed in the appropriate header regsitry. And did you send us that as a Last Call comment, with specifics? Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
OK, we can take these comments as inout for the revision of 2434. Brian JFC (Jefsey) Morfin wrote: At 15:38 09/06/2005, Brian E Carpenter wrote: Please see RFC 2434 = BCP 26 Dear Brian, I was probably not clear enough. Bruce quoted RFCs, and others points postdate RFC 2434. Current http://www.iana.org site is not the best documentation site I saw. It said two things: 1. a IANA related obligations registry. Where obligations to IANA, authors, users, etc. would be registered and easily displayed. 2. in the IANA considerations to explicit the way IANA overload will be fought. This last point (with XML registries) is a point under consideration and of concern for those having to fund the IANA as ccTLDs. It might lead to make alternatives being considered earlier than advisable for good transition. For example a daily interruption of IANA registries for an hour or random drops calling for a recall of the requested page, a timer, a copyrigh response first, etc. could be ways to prevent applications designers to call on IANA XML files everytime they need one of their data. jfc Brian JFC (Jefsey) Morfin wrote: Dear Bruce, you know what? I think it would be great to write a IANA obligations RFC. It would say that the IANA MUST maintain a list of all the obligations RFC authors should respect when writting the IANA considerations, and to document whatever additional information IANA may need (for example if a DoS might result from a possible misuse of what they ask and the proposed solutions). jfc At 19:59 08/06/2005, Bruce Lilly wrote: Re: Last Call: 'Email Submission Between Independent Networks' to BCP Date: 2005-06-08 10:50 From: Ned Freed [EMAIL PROTECTED] .. RFC2119, when used, must be a normative reference. Likewise, you'll need to add a null IANA considerations section. Agreed on the RFC 2119 reference. However, I do not believe there is any requirement for null IANA considerations sections. (A scan of recently published standards track RFCs turned up several that don't have such a section - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: The following are REQUIRED sections in all Internet-Drafts: [...] IANA Considerations A Must specify if IANA has to create a new registry or modify rules for an existing registry. B Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434] and in some cases also IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers [RFC2780]. In some case Assigning Experimental and Testing Numbers Considered Useful [RFC3692] may help as well. D If there is no action for IANA, the section should say that, e.g., including something like This document has no actions for IANA. And the RFC-Editor's instructions to RFC Authors (draft successor to RFC 2223, on hold) notes: Current policy (not documented in [IANA98]) is to include an IANA Considerations section always, even if it is null, i.e., even if there are no IANA considerations. This is helpful to IANA. However, the RFC Editor may remove any null IANA considerations sections before publication. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
It's a matter of taste whether http://www.ietf.org/ID-Checklist.html is obscure or not, but it is quite explicit and cites RFC 2434 which is BCP 26. BCP 26 says, among other things: All future RFCs that either explicitly or implicitly rely on the IANA to register or otherwise manage assignments MUST provide guidelines for managing the name space. The IESG operates on this basis. It's true that it isn't enforced at I-D submission time; but it is enforced in IESG review. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On 6/9/05, Bruce Lilly [EMAIL PROTECTED] wrote: Conversely, if the IESG does regard the matter as important, it could: 1. direct the IETF Secretariat to enforce the rule Bruce, ID-Checklist is only for I-Ds that are submitted to the IESG for publication. It's not the cost of checking that is a problem, rather, it's useful to allow earlier drafts of I-Ds to not be fully fleshed out (thus they're .. well .. drafts?) Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed [EMAIL PROTECTED] writes: Like it or not, careful reviews and review checklists, while quited flawed in their own right, are the best tool we have. When I was on the IESG I had my own private review checklist; it was the only thing I found that worked. I agree careful reviews are necessary. What I find surprising is your logic, which seems to say: IANA considerations sections in IDs are not sufficient, therefore they are useless (or worse). Is that really what you are advocating? What exactly is it that you think should be done (in addition to careful reviews) that would help reduce the odds that the careful review find issues with the IANA instructions (or lack thereof)? Note that having IC sections is all about improving the odds that they contain the Right Thing before the document is approved by the IESG. In my mind that means: 1) IANA reviews an (essentially) final version, to be sure what it says is consistent with their understanding of what needs to be carried out. But, IANA does this review during Last Call. Thus, the IC section really needs to be complete _before_ the full IETF review. 2) Well, the Shepherding AD can do the careful review during the AD review phase, but there is already plenty of pressure to skimp on the AD review in order to send a document the WG says is finished to IETF LC ASAP. I.e., to get the IETF LC started and fix any issues that come up later. Plus, in my experience, plenty of IC issues are caught by ADs other than the shepherding AD. So relying on them to catch all such issues is far from ideal. 3) Voila, have a checklist item that alerts WGs to things they should take steps to make sure their documents have already addressed prior to advancing a document out of the WG. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed [EMAIL PROTECTED] writes: Like it or not, careful reviews and review checklists, while quited flawed in their own right, are the best tool we have. When I was on the IESG I had my own private review checklist; it was the only thing I found that worked. I agree careful reviews are necessary. What I find surprising is your logic, which seems to say: IANA considerations sections in IDs are not sufficient, therefore they are useless (or worse). I have never said or even implied that. Is that really what you are advocating? Of course not. What exactly is it that you think should be done (in addition to careful reviews) that would help reduce the odds that the careful review find issues with the IANA instructions (or lack thereof)? Simple: The requirement that an IANA considerations section be included in RFC not containing any IANA actions needs to be dropped. I have been extremely clear ahout this. Note that having IC sections is all about improving the odds that they contain the Right Thing before the document is approved by the IESG. In my mind that means: That may be the intent, but the effect is to substitute boilerplate for review, which won't improve specification quality at all. 1) IANA reviews an (essentially) final version, to be sure what it says is consistent with their understanding of what needs to be carried out. But, IANA does this review during Last Call. Thus, the IC section really needs to be complete _before_ the full IETF review. 2) Well, the Shepherding AD can do the careful review during the AD review phase, but there is already plenty of pressure to skimp on the AD review in order to send a document the WG says is finished to IETF LC ASAP. I.e., to get the IETF LC started and fix any issues that come up later. Plus, in my experience, plenty of IC issues are caught by ADs other than the shepherding AD. So relying on them to catch all such issues is far from ideal. 3) Voila, have a checklist item that alerts WGs to things they should take steps to make sure their documents have already addressed prior to advancing a document out of the WG. This is all very logical, but we're dealing with people here, not perfect logical systems. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Fri, 10 Jun 2005, Ned Freed wrote: What exactly is it that you think should be done (in addition to careful reviews) that would help reduce the odds that the careful review find issues with the IANA instructions (or lack thereof)? Simple: The requirement that an IANA considerations section be included in RFC not containing any IANA actions needs to be dropped. I have been extremely clear ahout this. It's good, because this is already the case. Even if you're required to add a null IANA considerations section in the internet-drafts when being sent to the IESG, the RFC-editor removes the IANA considerations section completely if it doesn't have any real content. Anything else? -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Thomas, I won't attempt to speak for Ned, but I think there is some confusion here about what I, at least, intended by checklist. It is not, for me, tied up with the form of the list or what content it has, but goes back to questions of WG responsibilities (not just authority). The issue isn't whether something is listed somewhere, it is who, if anyone, is taking formal responsibility for asserting that the list has been checked and is correct. When I've talked about a submission checklist, it is less something the WG ought to check before sending something to the IESG or something the IESG checks after receiving something. It is, symmetrically with the WG Charter, an formal assertion by the WG and its Chair(s) that things have been reviewed, checked, and are correct... an assertion on which they are willing to commit their reputations (at least). And that is what has been missing from the picture. It is trivial to check whether an IANA Considerations section (or a Security Considerations section, or an Internationalization Considerations one, or any of the other things that have been asked for) is present. But, if it says none, or contains a collection of words that are irrelevant to the document at hand, checking becomes very hard --independent of whether the words are a section of an I-D or appear on a submission document somewhere. IMO, the key to making progress in this area is not to expect omniscience from the IESG, it is getting the WG Chair to formally sign off that the section has been seriously reviewed by the WG and found to be complete. I'd expect that the responsibility for making that sign off would, itself and by making the responsibilities clear, improve things. I'd also expect that, if problems are later found that the WG should have detected and didn't, or would have found had there been a meaningful review but that review didn't really occur, that the relevant AD would deal with that situation somewhat more sternly than, e.g., a WG missing a benchmark deadline: once the assertion is made that the review occurred and was diligent, a bad or no review is a sin of commission, not omission, and, absent external circumstances, I'd expect intense review of charters, changes of chairs, even closing of the relevant WG... or having the community hold the AD formally responsible for not taking those actions. If that didn't help, we would be in very bad shape indeed. john --On Friday, 10 June, 2005 07:35 -0400 Thomas Narten [EMAIL PROTECTED] wrote: Ned Freed [EMAIL PROTECTED] writes: Like it or not, careful reviews and review checklists, while quited flawed in their own right, are the best tool we have. When I was on the IESG I had my own private review checklist; it was the only thing I found that worked. I agree careful reviews are necessary. What I find surprising is your logic, which seems to say: IANA considerations sections in IDs are not sufficient, therefore they are useless (or worse). Is that really what you are advocating? What exactly is it that you think should be done (in addition to careful reviews) that would help reduce the odds that the careful review find issues with the IANA instructions (or lack thereof)? Note that having IC sections is all about improving the odds that they contain the Right Thing before the document is approved by the IESG. In my mind that means: 1) IANA reviews an (essentially) final version, to be sure what itsays is consistent with their understanding of what needs to becarried out. But, IANA does this review during Last Call. Thus, theIC section really needs to be complete _before_ the full IETFreview. 2) Well, the Shepherding AD can do the careful review during the ADreview phase, but there is already plenty of pressure to skimp onthe AD review in order to send a document the WG says is finishedto IETF LC ASAP. I.e., to get the IETF LC started and fix anyissues that come up later. Plus, in my experience, plenty of ICissues are caught by ADs other than the shepherding AD. So relyingon them to catch all such issues is far from ideal. 3) Voila, have a checklist item that alerts WGs to things they shouldtake steps to make sure their documents have already addressedprior to advancing a document out of the WG. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Fri, 10 Jun 2005, Ned Freed wrote: What exactly is it that you think should be done (in addition to careful reviews) that would help reduce the odds that the careful review find issues with the IANA instructions (or lack thereof)? Simple: The requirement that an IANA considerations section be included in RFC not containing any IANA actions needs to be dropped. I have been extremely clear ahout this. It's good, because this is already the case. Even if you're required to add a null IANA considerations section in the internet-drafts when being sent to the IESG, the RFC-editor removes the IANA considerations section completely if it doesn't have any real content. Anything else? It is the requirement that Internet Drafts always contain IANA considerations sections that has to go. What the RFC Editor does after document approval is not the issue here. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Ned Freed wrote: ... The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: That's most unfortunate. What do we need to do to get this silly and counterproductive requirement removed? Enough context has been removed that I don't know quite what you're objecting to, but the intent of the I-D checklist is to avoid the IESG having to kick back documents for trivia, so you can argue about what should or shouldn't be in the checklist, but you surely can't argue against it being used for its intended purpose. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. There is another purpose IMHO: ensure that future readers (implementers and deployers of the technology) know whether they need to deal with any IANA registration issues. For this reason, I have a strongly held opinion that null IANA Considerations sections should *not* be removed. The problem is that requiring such a section creates no such assurance. I've seen any number of documents with IANA considerations that initially failed to list all the considerations. Yes indeed, and I see a lot of IESG DISCUSSes on exactly this point. And given past experience with security considerations: none sections, there is no reason to believe that requiring such a section will actually result in IANA considerations being properly called out. In fact I'd say there's a good chance it will cause obscure considerations to be missed. I think experience shows otherwise: the fact that reviewers, including the IESG, are paying increasing attention to this section is in fact catching omissions. Like it or not, boilerplate is not now and never will be a useful subsitute for careful review. I agree And as the pile of useless crap we require gets ever-larger it gets harder, not easier, to get that review. I disagree. Actually, the mandatory presence of this section *triggers* review (see above comment). Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. The ID-Nits tool checks it and the future automated submission tool will check a lot more than the Secretariat can do manually. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Dear Bruce, you know what? I think it would be great to write a IANA obligations RFC. It would say that the IANA MUST maintain a list of all the obligations RFC authors should respect when writting the IANA considerations, and to document whatever additional information IANA may need (for example if a DoS might result from a possible misuse of what they ask and the proposed solutions). jfc At 19:59 08/06/2005, Bruce Lilly wrote: Re: Last Call: 'Email Submission Between Independent Networks' to BCP Date: 2005-06-08 10:50 From: Ned Freed [EMAIL PROTECTED] .. RFC2119, when used, must be a normative reference. Likewise, you'll need to add a null IANA considerations section. Agreed on the RFC 2119 reference. However, I do not believe there is any requirement for null IANA considerations sections. (A scan of recently published standards track RFCs turned up several that don't have such a section - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: The following are REQUIRED sections in all Internet-Drafts: [...] IANA Considerations A Must specify if IANA has to create a new registry or modify rules for an existing registry. B Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434] and in some cases also IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers [RFC2780]. In some case Assigning Experimental and Testing Numbers Considered Useful [RFC3692] may help as well. D If there is no action for IANA, the section should say that, e.g., including something like This document has no actions for IANA. And the RFC-Editor's instructions to RFC Authors (draft successor to RFC 2223, on hold) notes: Current policy (not documented in [IANA98]) is to include an IANA Considerations section always, even if it is null, i.e., even if there are no IANA considerations. This is helpful to IANA. However, the RFC Editor may remove any null IANA considerations sections before publication. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Please see RFC 2434 = BCP 26 Brian JFC (Jefsey) Morfin wrote: Dear Bruce, you know what? I think it would be great to write a IANA obligations RFC. It would say that the IANA MUST maintain a list of all the obligations RFC authors should respect when writting the IANA considerations, and to document whatever additional information IANA may need (for example if a DoS might result from a possible misuse of what they ask and the proposed solutions). jfc At 19:59 08/06/2005, Bruce Lilly wrote: Re: Last Call: 'Email Submission Between Independent Networks' to BCP Date: 2005-06-08 10:50 From: Ned Freed [EMAIL PROTECTED] .. RFC2119, when used, must be a normative reference. Likewise, you'll need to add a null IANA considerations section. Agreed on the RFC 2119 reference. However, I do not believe there is any requirement for null IANA considerations sections. (A scan of recently published standards track RFCs turned up several that don't have such a section - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: The following are REQUIRED sections in all Internet-Drafts: [...] IANA Considerations A Must specify if IANA has to create a new registry or modify rules for an existing registry. B Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434] and in some cases also IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers [RFC2780]. In some case Assigning Experimental and Testing Numbers Considered Useful [RFC3692] may help as well. D If there is no action for IANA, the section should say that, e.g., including something like This document has no actions for IANA. And the RFC-Editor's instructions to RFC Authors (draft successor to RFC 2223, on hold) notes: Current policy (not documented in [IANA98]) is to include an IANA Considerations section always, even if it is null, i.e., even if there are no IANA considerations. This is helpful to IANA. However, the RFC Editor may remove any null IANA considerations sections before publication. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Brian, We agree about the desirability of making sure than some things are explicitly documented and explicitly part of what gets reviewed. But I continue to believe, as I have believed for years, that adding more and more mandatory material to RFCs or I-Ds is not the best solution to that particular problem. Perhaps, in line with the PROTO effort (and maybe the ISD discussion), it is time to revisit the other approach: rather than cluttering up I-Ds with materials that can be filled out pro-forma and that the RFC Editor may then remove (or not), migrate at least some of these procedural requirements associated with protocol specifications from the I-D to a submission checklist that a WG or individual would provide to the IESG as part of the request for Last Call and approval action. That document could contain, e.g., an explicit statement as to whether the WG had examined IANA issues and decided that there were none, rather than just providing pro forma text or boilerplate, as well as draft protocol action statements, etc. The IESG gets more information, in clearer form, and we don't end up with a choice between information getting lost and more clutter in RFCs. Of course, if one were doing ISDs, that text and anything else that relates to the process and context for approving a standard, rather than information key to the protocol specification itself, could, when the spec was approved, be reasonably be transposed into the ISD. john --On Thursday, 09 June, 2005 11:06 +0200 Brian E Carpenter [EMAIL PROTECTED] wrote: Ned Freed wrote: ... The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: That's most unfortunate. What do we need to do to get this silly and counterproductive requirement removed? Enough context has been removed that I don't know quite what you're objecting to, but the intent of the I-D checklist is to avoid the IESG having to kick back documents for trivia, so you can argue about what should or shouldn't be in the checklist, but you surely can't argue against it being used for its intended purpose. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. There is another purpose IMHO: ensure that future readers (implementers and deployers of the technology) know whether they need to deal with any IANA registration issues. For this reason, I have a strongly held opinion that null IANA Considerations sections should *not* be removed. The problem is that requiring such a section creates no such assurance. I've seen any number of documents with IANA considerations that initially failed to list all the considerations. Yes indeed, and I see a lot of IESG DISCUSSes on exactly this point. And given past experience with security considerations: none sections, there is no reason to believe that requiring such a section will actually result in IANA considerations being properly called out. In fact I'd say there's a good chance it will cause obscure considerations to be missed. I think experience shows otherwise: the fact that reviewers, including the IESG, are paying increasing attention to this section is in fact catching omissions. Like it or not, boilerplate is not now and never will be a useful subsitute for careful review. I agree And as the pile of useless crap we require gets ever-larger it gets harder, not easier, to get that review. I disagree. Actually, the mandatory presence of this section *triggers* review (see above comment). Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. The ID-Nits tool checks it and the future automated submission tool will check a lot more than the Secretariat can do manually. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
In message [EMAIL PROTECTED], John C Klensin writes: Brian, We agree about the desirability of making sure than some things are explicitly documented and explicitly part of what gets reviewed. But I continue to believe, as I have believed for years, that adding more and more mandatory material to RFCs or I-Ds is not the best solution to that particular problem. From where I sat, the problem was trying to ensure that a WG thought about an issue. Neither mandatory material nor checkoff boxes accomplish that, but I think the former is often more useful because material in an I-D is visible to the entire WG. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
At 15:38 09/06/2005, Brian E Carpenter wrote: Please see RFC 2434 = BCP 26 Dear Brian, I was probably not clear enough. Bruce quoted RFCs, and others points postdate RFC 2434. Current http://www.iana.org site is not the best documentation site I saw. It said two things: 1. a IANA related obligations registry. Where obligations to IANA, authors, users, etc. would be registered and easily displayed. 2. in the IANA considerations to explicit the way IANA overload will be fought. This last point (with XML registries) is a point under consideration and of concern for those having to fund the IANA as ccTLDs. It might lead to make alternatives being considered earlier than advisable for good transition. For example a daily interruption of IANA registries for an hour or random drops calling for a recall of the requested page, a timer, a copyrigh response first, etc. could be ways to prevent applications designers to call on IANA XML files everytime they need one of their data. jfc Brian JFC (Jefsey) Morfin wrote: Dear Bruce, you know what? I think it would be great to write a IANA obligations RFC. It would say that the IANA MUST maintain a list of all the obligations RFC authors should respect when writting the IANA considerations, and to document whatever additional information IANA may need (for example if a DoS might result from a possible misuse of what they ask and the proposed solutions). jfc At 19:59 08/06/2005, Bruce Lilly wrote: Re: Last Call: 'Email Submission Between Independent Networks' to BCP Date: 2005-06-08 10:50 From: Ned Freed [EMAIL PROTECTED] .. RFC2119, when used, must be a normative reference. Likewise, you'll need to add a null IANA considerations section. Agreed on the RFC 2119 reference. However, I do not believe there is any requirement for null IANA considerations sections. (A scan of recently published standards track RFCs turned up several that don't have such a section - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: The following are REQUIRED sections in all Internet-Drafts: [...] IANA Considerations A Must specify if IANA has to create a new registry or modify rules for an existing registry. B Must specify if the document requires IANA to assign or update values in an IANA registry before RFC publication. C See Guidelines for Writing an IANA Considerations Section in RFCs [RFC2434] and in some cases also IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers [RFC2780]. In some case Assigning Experimental and Testing Numbers Considered Useful [RFC3692] may help as well. D If there is no action for IANA, the section should say that, e.g., including something like This document has no actions for IANA. And the RFC-Editor's instructions to RFC Authors (draft successor to RFC 2223, on hold) notes: Current policy (not documented in [IANA98]) is to include an IANA Considerations section always, even if it is null, i.e., even if there are no IANA considerations. This is helpful to IANA. However, the RFC Editor may remove any null IANA considerations sections before publication. I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Wed June 8 2005 14:30, Ned Freed wrote: The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: [IANA Considerations section is REQUIRED] That's most unfortunate. What do we need to do to get this silly and counterproductive requirement removed? (pessimist hat on) Nothing. Just ignore it; everybody does. The rule, such as it is, isn't enforced. (pessimist hat off) I think counterproductive is at best quite a stretch. The problem is that requiring such a section creates no such assurance. Of course. But it does encourage thought (both by authors/editors and reviewers). Surely you're not suggesting that authors, editors, and reviewers should ignore IANA considerations. The problem (N.B. pessimist hat is off) is that we now have the worst of all possible situations: o The rule exists in some random documents buried on some web sites, and the documents have no status as RFC or BCP; as far as I can tell there are no immediate plans to change that (one of the documents is an Internet-Draft which is now nearly 11 months old) o BCP 14 language is used with a normative reference to BCP 14, implying that this is a matter taken seriously; the document using that language comes from the IESG, but as noted above has no standing as BCP o Although it is expressed as REQUIRED, and: i. it is referenced either directly or indirectly from several places ii. there exist tools (e.g. idnits) which quickly and accurately determines if the requirement is met the rule is not enforced (or is at best selectively enforced) These things are at odds (e.g. there is little point in a requirement, expressed in strong terms (but in somewhat obscure documents with no official standing) which is ignored), yet are self-reinforcing (if the rule isn't enforced, it's hardly surprising that authors and editors ignore it, nor is it surprising that some IETFers seem to be unaware of requirements in documents that have no standing and are hidden in obscure places). If the IESG really doesn't care, it could indicate so consistently by: 1. reissuing the guidelines without BCP 14 language and burying the document deeper on the IETF web site; keep the document unofficial, make random changes at random times, and remove all version indications (or further obscure those indications by making the gray text on the gray background in the current HTML-only document even lower contrast and smaller size, and/or use an uglier markup language) 2. keep the 2223bis draft in limbo for a few more years and/or ask the RFC Editor to elide the part about a null IANA Considerations section [obviously, some of the comments immediately above are tongue-in-cheek] Conversely, if the IESG does regard the matter as important, it could: 1. direct the IETF Secretariat to enforce the rule (given the fact that idnits already checks for it, as well as checking for IPR boilerplate issues -- which the Secretariat does enforce with an iron fist -- I don't buy the argument that checking would impose an inordinate cost. In fact I suspect that the incremental cost would be smaller than that of any instrumentation that might be applied to measure that cost) 2. publish the guidelines as BCP and move forward on the 2223bis draft ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
From where I sat, the problem was trying to ensure that a WG thought about an issue. Neither mandatory material nor checkoff boxes accomplish that, but I think the former is often more useful because material in an I-D is visible to the entire WG. I disagree completely and think you have this exactly backwards. Mandatory material would only help if people actually think about what goes in it - which they don't. Rather, they think about it as another something we have to do to get past the IESG and deal with it by spending as little time on it as possible. Even worse, the presence of a section that says these are all the IANA considerations or there are no IANA considerations here is likely to cause reviewers to assume that someone has already checked for IANA actions. This will lead to more omissions, not less. And in fact there has already been at least one example of this happening. The document draft-ietf-lemonade-mms-mapping-04.txt is now in the RFC Editor's queue. It's IANA considerations section says no IANA actions. Alas, the document defines any number of new header fields that need to be placed in the appropriate header regsitry. That IANA considerations section sure helped a lot, didn't it? Like it or not, careful reviews and review checklists, while quited flawed in their own right, are the best tool we have. When I was on the IESG I had my own private review checklist; it was the only thing I found that worked. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Wednesday, June 08, 2005 01:59:19 PM -0400 Bruce Lilly [EMAIL PROTECTED] wrote: Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. Aside from making sure the proper boilerplate is included in documents it publishes (which it pretty much has to do for legal reasons), the IETF secretariat generally does not check submitted I-D's for conformance with standards for submissions. To do otherwise would not only be expensive and slow down the I-D submission process considerably; it would also interfere with the IETF process. Internet-Drafts are works-in-progress; it is not necessary or even desirable that every I-D be in a form suitable for submission to the IESG before being added to the repository. -- Jeffrey T. Hutzelman (N3NHS) [EMAIL PROTECTED] Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
Re: Last Call: 'Email Submission Between Independent Networks' to BCP Date: 2005-06-08 10:50 From: Ned Freed [EMAIL PROTECTED] .. RFC2119, when used, must be a normative reference. Likewise, you'll need to add a null IANA considerations section. Agreed on the RFC 2119 reference. However, I do not believe there is any requirement for null IANA considerations sections. (A scan of recently published standards track RFCs turned up several that don't have such a section - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless boilerplate already without adding yet another useless section to the mix? The IETF Internet-Drafts page notes that All Internet-Drafts that are submitted to the IESG for consideration as RFCs must conform to the requirements specified in the I-D Checklist. The current version of the ID-Checklist clearly states: That's most unfortunate. What do we need to do to get this silly and counterproductive requirement removed? I believe the requirements exist to ensure that draft authors give due consideration to IANA Considerations and that IANA can readily determine if some action is or is not required. The problem is that requiring such a section creates no such assurance. I've seen any number of documents with IANA considerations that initially failed to list all the considerations. And given past experience with security considerations: none sections, there is no reason to believe that requiring such a section will actually result in IANA considerations being properly called out. In fact I'd say there's a good chance it will cause obscure considerations to be missed. Like it or not, boilerplate is not now and never will be a useful subsitute for careful review. And as the pile of useless crap we require gets ever-larger it gets harder, not easier, to get that review. Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. On the contrary, it is fortunate they are not enforcing it. As the RFC Editor removes null sections, you won't find them in published RFCs. But Internet-Drafts are REQUIRED to have them. Making it one more disincentive for contributors. This really needs to stop. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations
On Jun 8, 2005, at 14:23, Jeffrey Hutzelman wrote: On Wednesday, June 08, 2005 01:59:19 PM -0400 Bruce Lilly [EMAIL PROTECTED] wrote: Evidently (and unfortunately) the IETF Secretariat apparently doesn't enforce that part of the ID-Checklist rules. Aside from making sure the proper boilerplate is included in documents it publishes (which it pretty much has to do for legal reasons), the IETF secretariat generally does not check submitted I-D's for conformance with standards for submissions. To do otherwise would not only be expensive and slow down the I-D submission process considerably; it would also interfere with the IETF process. True... but something like has an IANA Considerations section is easy to check, and easy for the author to implement, even if it's just starting with an I-D template that says to be determined or author should fill this in or author promises to take the RFC Editor out for a pancake breakfast if this text is submitted for publication as an RFC. Internet-Drafts are works-in-progress; it is not necessary or even desirable that every I-D be in a form suitable for submission to the IESG before being added to the repository. Also true. But there is a different requirements list for I-Ds than for RFCs. If something shouldn't be required for I-D submission, then it shouldn't be on that list. Evidently someone thought that IANA Considerations should be in every I-D submission. Now, perhaps the requirements list should be changed. I'm inclined to say not, in this case; the null IANA Considerations section (as opposed to not having one, or the pancake-breakfast template above) does imply that the author has actually thought about it and concluded that IANA doesn't need to do anything. Ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IANA Considerations in IDs (was Re: Last Call: DHCP Domain Search Option to Proposed Standard )
At 06:37 AM 9/28/2001, Thomas Narten wrote: usages). This again argues for having the IANA Considerations section be complete during IETF Last Call, so the community as as whole can also review it. (excellent summary, Thomas. many thanks it. in fact, it probably should be included in one of our process documents, perhaps working group guidelines.) In general, IETF work has greatly benefited from moving review by decision-makers earlier. It is extremely costly and frustrating to have a working group haggle and resolve its issues, only to find that a decision-maker in the critical path has major (ie, showstopping) concerns that were not known early in the process. Hence, the trend toward earlier IANA review of the Considerations section is a Very Good Thing. d/ -- Dave Crocker mailto:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com tel +1.408.246.8253; fax +1.408.273.6464
