Re: Last Call on draft-ietf-pim-registry-03.txt
31.01.2011 22:38, Stig Venaas wrote: I have now submitted version 04 which I believe addresses the last call comments. The changes are as follows: Added the sentence: The message type is a 4-bit integer with possible values from 0 to 15. Listing 11-14 as Unassigned. Stig, Thank you very much for your changes. Now the registry definition seems to be clear. The references are now all Informational (there was a down reference to experimental). Maybe RFC 5226 should be referenced normatively, as well as some docs. connected to PIMv2. Moreover, the reference to IANA registry should read: Internet Assigned Numbers Authority (IANA) Registry, "IGMP Type Numbers", per RFC 3228, as for November 2010> All the best, Mykyta Yevstifeyev There was a comment about expanding the term PIM. PIM has now been added to the list of well-known abbreviations that don't need to be expanded. Hence I chose not to expand it. Stig ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
I have now submitted version 04 which I believe addresses the last call comments. The changes are as follows: Added the sentence: The message type is a 4-bit integer with possible values from 0 to 15. Listing 11-14 as Unassigned. The references are now all Informational (there was a down reference to experimental). There was a comment about expanding the term PIM. PIM has now been added to the list of well-known abbreviations that don't need to be expanded. Hence I chose not to expand it. Stig ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Hello all, Summarizing all LC comments received so far, I'd like to propose the author of draft-ietf-pim-registry-03.txt the following changes to his document: 1. Abstract Explain the abbreviations. 2. Introduction Explain the abbreviations. 3. Add a new section directly after Introduction named '2. Registry Description' with the following content: 2.1. The Name of the Registry The name of created registry is 'Protocol Independent Multicast (PIM) Message Types'. 2.2. The Format of the Registry The 'Protocol Independent Multicast (PIM) Message Types' registry consists of 3 values: Packet Type, Description and Reference. They are described below: Packet Type - an integer; values form 0 to 15 are assigned. Description - a brief decryption of packet type. Reference - the reference document, that defines the packet type. 2.3. Registration Procedures New assignments to 'Protocol Independent Multicast (PIM) Message Types' registry SHALL be made following the 'IETF Consensus' policies. [RFC5226] 2.4. The Initial Contents of the Registry This section contains the initial contents of the 'Protocol Independent Multicast (PIM) Message Types' registry. +-+-+--+ | Type | Description | Reference | ++-+---+ |0 | Hello |[RFC3973] [RFC4601]| |1 | Register|[RFC4601] | |2 | Register Stop |[RFC4601] | |3 | Join/Prune |[RFC3973] [RFC4601]| |4 | Bootstrap |[RFC4601] | |5 | Assert |[RFC3973] [RFC4601]| |6 | Graft |[RFC3973] | |7 | Graft-Ack |[RFC3973] | |8 | Candidate RP Advertisement |[RFC4601] | |9 | State Refresh |[RFC3973] | |10 | DF Election |[RFC5015] | |11-14 | Unassigned |this document | |15 | Reserved|this document | ++-+---+ 2.5. Sub-Registries No sub-registries are currently defined in 'Protocol Independent Multicast (PIM) Message Types' registry. 4. Security Consideration: renumber 5. IANA Considerations: renumber, modify in the following way: IANA is asked to create the Protocol Independent Multicast (PIM) Message Types' registry following Section 2 of this document. 6. Other sections: renumber. I suppose the author will accept my proposal that makes the registry description more clear. All the best, Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 14.01.2011 15:04, Mykyta Yevstifeyev wrote: 13.01.2011 18:19, Julian Reschke wrote: On 13.01.2011 17:14, Mykyta Yevstifeyev wrote: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", **"Unassigned"**, etc. should be *clearly indicated*. <...> Yes. There's still no "MUST" applying to unassigned code points. Note the "In addition" and "should". There is MUST before the list of the criteria for the documents defining the registry. This MUST applies to everything mentioned in this list. ... Well, we can go on repeating this exchange over and over, or just stop. I'll stop. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
13.01.2011 18:19, Julian Reschke wrote: On 13.01.2011 17:14, Mykyta Yevstifeyev wrote: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", **"Unassigned"**, etc. should be *clearly indicated*. <...> Yes. There's still no "MUST" applying to unassigned code points. Note the "In addition" and "should". There is MUST before the list of the criteria for the documents defining the registry. This MUST applies to everything mentioned in this list. Mykyta ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call on draft-ietf-pim-registry-03.txt
RFC 5226 (BCP 26) says IANA must be given a set of guidelines that allow it to make allocation decisions with minimal subjectivity and without requiring any technical expertise with respect to the protocols that make use of a registry. and goes on to discuss categories of unassigned code points (though it does also define the unqualified word Unassigned). We were thus advised, when publishing RFC 5444, to specify this clearly and so we had tables such as +-+---++ | Type | Description | Allocation Policy | +-+---++ | 0-127 | Unassigned| Expert Review | | 128-223 | Message-Type-specific | Reserved, see Table 11 | | 224-255 | Unassigned| Experimental Use | +-+---++ (For the purposes of this discussion I suggest ignoring the 128 to 223 line above.) This seemed to keep everyone (IESG, IANA, RFC Editor) happy. -- Christopher Dearlove Technology Leader, Communications Group Communications and Networks Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Lars Eggert Sent: 14 January 2011 08:23 To: Michelle Cotton Cc: Julian Reschke; s...@cisco.com; Adrian Farrel; 'The IETF' Subject: Re: Last Call on draft-ietf-pim-registry-03.txt Hi, On 2011-1-13, at 22:43, Michelle Cotton wrote: > Many believe it makes it very clear to the users of the registry what is > available for assignment. Something we will be rolling out soon (for those > registries with a finite space) will be small charts showing how much of the > registry space is unassigned, assigned and reserved (utilizing the > unassigned entries). I mentioned in the past that the term "unassigned" to me at least doesn't make it sufficiently clear that IANA assignment is often needed before codepoints may be taken into use. We have several cases (the many different squats on TCP option numbers, for example) were people pick unassigned codepoints during development and only later realize that they should have registered them. If you want to explicitly list unassigned codepoints in the registries, I'm wondering if we can find a short phrase that makes it more clear that an IANA action is normally required - maybe "available for IANA assignment"? Lars This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Hi, On 2011-1-13, at 22:43, Michelle Cotton wrote: > Many believe it makes it very clear to the users of the registry what is > available for assignment. Something we will be rolling out soon (for those > registries with a finite space) will be small charts showing how much of the > registry space is unassigned, assigned and reserved (utilizing the > unassigned entries). I mentioned in the past that the term "unassigned" to me at least doesn't make it sufficiently clear that IANA assignment is often needed before codepoints may be taken into use. We have several cases (the many different squats on TCP option numbers, for example) were people pick unassigned codepoints during development and only later realize that they should have registered them. If you want to explicitly list unassigned codepoints in the registries, I'm wondering if we can find a short phrase that makes it more clear that an IANA action is normally required - maybe "available for IANA assignment"? Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 21:43, Michelle Cotton wrote: Many believe it makes it very clear to the users of the registry what is available for assignment. Something we will be rolling out soon (for those registries with a finite space) will be small charts showing how much of the registry space is unassigned, assigned and reserved (utilizing the unassigned entries). --Michelle ... Exactly my point -- we should distinguish between the actual registry contents (assigned / reserved), and how it's presented. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Many believe it makes it very clear to the users of the registry what is available for assignment. Something we will be rolling out soon (for those registries with a finite space) will be small charts showing how much of the registry space is unassigned, assigned and reserved (utilizing the unassigned entries). --Michelle On 1/12/11 6:35 AM, "Julian Reschke" wrote: > On 12.01.2011 15:22, Adrian Farrel wrote: >> Entirely at random I clicked on: >> >> http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml >> http://www.iana.org/assignments/calipso/calipso.xhtml >> http://www.iana.org/assignments/lmp-parameters >> >> Looks like IANA tries to fill up all the blanks with markers of "unassigned". >> >> Is that harmful? > > Minimally, it's redundant. Also, it only makes sense on certain types of > registries. > > I just checked the XML version of the first registry, and, indeed, it > contains entries for unassigned values. /me shakes head in disbelief. > > What *should* be done is computing the unassigned ranges for > *presentation*; that is, they should not be part of the actual registry. > The way it's done currently defeats one of the reasons of having a > machine-readable registry (consumers will have to hard-wire knowledge of > the specific "unassigned" entry to make sense of the registry). > > Best regards, Julian > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 17:14, Mykyta Yevstifeyev wrote: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", **"Unassigned"**, etc. should be *clearly indicated*. <...> Yes. There's still no "MUST" applying to unassigned code points. Note the "In addition" and "should". ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
13.01.2011 18:10, Julian Reschke wrote: On 13.01.2011 17:08, Mykyta Yevstifeyev wrote: 13.01.2011 17:58, Julian Reschke wrote: On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". I meant in the previous message. Please cite where the spec says "must" or "MUST". That is a citation of RFC 5226 <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", **"Unassigned"**, etc. should be *clearly indicated*. <...> ... The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. That, IMO, was the mistake of authors of RFC 5226 that didn't take the text registries into considerations. We have no way to correct that now. ... We can raise errata, and have the authors and the IESG approve them. We can also use common sense, and note that IANA apparently doesn't enforce these rules when they do not make sense. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 17:08, Mykyta Yevstifeyev wrote: 13.01.2011 17:58, Julian Reschke wrote: On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". I meant in the previous message. Please cite where the spec says "must" or "MUST". ... The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. That, IMO, was the mistake of authors of RFC 5226 that didn't take the text registries into considerations. We have no way to correct that now. ... We can raise errata, and have the authors and the IESG approve them. We can also use common sense, and note that IANA apparently doesn't enforce these rules when they do not make sense. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
13.01.2011 17:58, Julian Reschke wrote: On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". I meant in the previous message. This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. See below. Even further? :-) The same. There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. That, IMO, was the mistake of authors of RFC 5226 that didn't take the text registries into considerations. We have no way to correct that now. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 16:51, Mykyta Yevstifeyev wrote: ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. I do not see a citation "below". This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. See below. Even further? :-) There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. The strings registries are rather exceptions from the rule I cited above. Well, we have many of them. The rules should takes those into account. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
13.01.2011 13:31, Julian Reschke wrote: On 13.01.2011 10:21, Mykyta Yevstifeyev wrote: Hello all, Let me cite RFC 5226, that says: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", *"Unassigned"*, etc. should be *clearly indicated*. <...> ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. Yes, that is a type of error, but the meaning is that unassigned and reserved values MUST (yes, must, that is in RFC 5226; see citation below) be mentioned. This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. See below. There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. The strings registries are rather exceptions from the rule I cited above. Mykyta Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 10:21, Mykyta Yevstifeyev wrote: Hello all, Let me cite RFC 5226, that says: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", *"Unassigned"*, etc. should be *clearly indicated*. <...> ... That sounds like an editorial error to me. "any ranges to be *reserved* for "Unassigned"..." doesn't make any sense at all. They are not reserved. This should probably be raised as erratum. So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. No. should != must. There are tons of registries where this is not the case; namely all or most of those where the values are strings, not numbers. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Hello all, Let me cite RFC 5226, that says: <...> Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions *MUST* include: <...> 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", *"Unassigned"*, etc. should be *clearly indicated*. <...> So the document specifying the regsitry MUST mention what are Unassigned. Moreover, IMO, it would be useful to assign one value for Experimentation. Mykyta 2011/1/13, Julian Reschke : > On 13.01.2011 03:56, Doug Ewell wrote: >> Donald Eastlake wrote: >> >>> Almost all registries I'm familiar with explicitly list unassigned >>> ranges. >> >> The IANA Language Subtag Registry doesn't: >> >> http://www.iana.org/assignments/language-subtag-registry > > Obviously it depends on the datatype whether saying what's unassigned is > useful or feasible. > > Back to ma point: for registries where it *can* be done, the unassigned > values can be *computed*. Thus, they shouldn't be part of the registry > data, but simply be displayed as such. That would ensure that the > information always is up-to-date. > > Best regards, Julian > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 13.01.2011 03:56, Doug Ewell wrote: Donald Eastlake wrote: Almost all registries I'm familiar with explicitly list unassigned ranges. The IANA Language Subtag Registry doesn't: http://www.iana.org/assignments/language-subtag-registry Obviously it depends on the datatype whether saying what's unassigned is useful or feasible. Back to ma point: for registries where it *can* be done, the unassigned values can be *computed*. Thus, they shouldn't be part of the registry data, but simply be displayed as such. That would ensure that the information always is up-to-date. Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Donald Eastlake wrote: Almost all registries I'm familiar with explicitly list unassigned ranges. The IANA Language Subtag Registry doesn't: http://www.iana.org/assignments/language-subtag-registry -- Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
12.01.2011 22:07, Donald Eastlake wrote: Almost all registries I'm familiar with explicitly list unassigned ranges. In some cases, different unassigned subranges have different allocation policies. For example, there may be a small unassigned range of lower values requiring Standards Action with the bulk of the unassigned values allocatable on a less stringent basis. RFC 5226 has an exact rule: Unassigned values shall be mentioned while creating registries. And another (not from 5226): it is RECOMMENDED to explain all abbreviation, even well-known once they occur. I do not know what is the problem here. Mykyta Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Wed, Jan 12, 2011 at 9:35 AM, Julian Reschke wrote: On 12.01.2011 15:22, Adrian Farrel wrote: Entirely at random I clicked on: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml http://www.iana.org/assignments/calipso/calipso.xhtml http://www.iana.org/assignments/lmp-parameters Looks like IANA tries to fill up all the blanks with markers of "unassigned". Is that harmful? Minimally, it's redundant. Also, it only makes sense on certain types of registries. I just checked the XML version of the first registry, and, indeed, it contains entries for unassigned values. /me shakes head in disbelief. What *should* be done is computing the unassigned ranges for *presentation*; that is, they should not be part of the actual registry. The way it's done currently defeats one of the reasons of having a machine-readable registry (consumers will have to hard-wire knowledge of the specific "unassigned" entry to make sense of the registry). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
Almost all registries I'm familiar with explicitly list unassigned ranges. In some cases, different unassigned subranges have different allocation policies. For example, there may be a small unassigned range of lower values requiring Standards Action with the bulk of the unassigned values allocatable on a less stringent basis. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street Milford, MA 01757 USA d3e...@gmail.com On Wed, Jan 12, 2011 at 9:35 AM, Julian Reschke wrote: > On 12.01.2011 15:22, Adrian Farrel wrote: >> >> Entirely at random I clicked on: >> >> http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml >> http://www.iana.org/assignments/calipso/calipso.xhtml >> http://www.iana.org/assignments/lmp-parameters >> >> Looks like IANA tries to fill up all the blanks with markers of >> "unassigned". >> >> Is that harmful? > > Minimally, it's redundant. Also, it only makes sense on certain types of > registries. > > I just checked the XML version of the first registry, and, indeed, it > contains entries for unassigned values. /me shakes head in disbelief. > > What *should* be done is computing the unassigned ranges for *presentation*; > that is, they should not be part of the actual registry. The way it's done > currently defeats one of the reasons of having a machine-readable registry > (consumers will have to hard-wire knowledge of the specific "unassigned" > entry to make sense of the registry). > > Best regards, Julian > > ___ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 1/12/2011 5:25 AM, Adrian Farrel wrote: Hi Mykyta, I am writing to provide some review on the draft-ietf-pim-registry, that is currently in Last Call, Many thanks for reviewing. Furstly, this document does not explain the abreviatures once they has appeared in the title, abstract and main text. Good catch. It looks like a number of the acronyms we expected to be "well-known" are not. I find: PIM RFC (wow, that is a real surprise) PIM is also in the list. The only one missing is RFC. Which indeed is a surprise :) I can expand that if you want me to. Or we can leave it to the RFC-Editor to decide? On the other hand, some *are* well-known and don't need to be expanded: IANA IGMP IETF For reference, see http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt Moreover, the initial contents of the regsitry does not mention that values that are Unassigned. Yeah, probably worth adding an entry... 11-14 Unassigned I find it a bit superfluous, but I can certainly do that. Just so it's clear that nothing may have been omitted. What is more, the document does not have clear regsitry format description, eg. Message Type - an integer, values from 0 to 15 are assigned etc. I propose to create the separate section and name it 'Regsitry Description' and place a number of sub-section tehre that would describe the regsutry as detailed as possible. You are right. The description of the Message Type should be included. In particular the range is very important. This should be added to the end of the paragraph in Section 3. I agree. The document notes in the introduction that its 4 bits, but it should be as part of the registry. Once the last call is ended I'll do a new version where I point this out. Stig And in this occasion out the follwoing IANA Considerations' Section: 'IANA is asked to create the 'name' regsitry following Section 2 of this document." I am not sure what your suggestion is here. Section 3 begins with exactly this request (using different words). So I recommend not to publih this document in the current view, Agreed. Thanks for catching these issues which can be fixed. stop the Last Call, if posible, and work on it a bit more. No, I don't think so. The purpose of a last call is not necessarily to have everyone agree that a document is perfect. The purpose is to catch exactly the type of issue you have raised. I do not believe that your input here (which *is* valuable) results in changes to the I-D that make a fundamental difference to the document that would necessitate a further last call. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 12.01.2011 15:22, Adrian Farrel wrote: Entirely at random I clicked on: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml http://www.iana.org/assignments/calipso/calipso.xhtml http://www.iana.org/assignments/lmp-parameters Looks like IANA tries to fill up all the blanks with markers of "unassigned". Is that harmful? Minimally, it's redundant. Also, it only makes sense on certain types of registries. I just checked the XML version of the first registry, and, indeed, it contains entries for unassigned values. /me shakes head in disbelief. What *should* be done is computing the unassigned ranges for *presentation*; that is, they should not be part of the actual registry. The way it's done currently defeats one of the reasons of having a machine-readable registry (consumers will have to hard-wire knowledge of the specific "unassigned" entry to make sense of the registry). Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call on draft-ietf-pim-registry-03.txt
Entirely at random I clicked on: http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xhtml http://www.iana.org/assignments/calipso/calipso.xhtml http://www.iana.org/assignments/lmp-parameters Looks like IANA tries to fill up all the blanks with markers of "unassigned". Is that harmful? Adrian > -Original Message- > From: Julian Reschke [mailto:julian.resc...@gmx.de] > Sent: 12 January 2011 13:58 > To: adrian.far...@huawei.com > Cc: 'Mykyta Yevstifeyev'; 'The IETF'; s...@cisco.com > Subject: Re: Last Call on draft-ietf-pim-registry-03.txt > > On 12.01.2011 14:25, Adrian Farrel wrote: > > ... > >> Moreover, the initial contents of the regsitry does not mention that > >> values that are Unassigned. > > > > Yeah, probably worth adding an entry... > > > > 11-14 Unassigned > > ... > > My understanding was that if something isn't registered then it's > unassigned. When did we start to list those in a registry? > > > ... > > Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call on draft-ietf-pim-registry-03.txt
On 12.01.2011 14:25, Adrian Farrel wrote: ... Moreover, the initial contents of the regsitry does not mention that values that are Unassigned. Yeah, probably worth adding an entry... 11-14 Unassigned ... My understanding was that if something isn't registered then it's unassigned. When did we start to list those in a registry? > ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call on draft-ietf-pim-registry-03.txt
Hi Mykyta, > I am writing to provide some review on the draft-ietf-pim-registry, > that is currently in Last Call, Many thanks for reviewing. > Furstly, this document does not explain the abreviatures once they has > appeared in the title, abstract and main text. Good catch. It looks like a number of the acronyms we expected to be "well-known" are not. I find: PIM RFC (wow, that is a real surprise) On the other hand, some *are* well-known and don't need to be expanded: IANA IGMP IETF For reference, see http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > Moreover, the initial contents of the regsitry does not mention that > values that are Unassigned. Yeah, probably worth adding an entry... 11-14 Unassigned > What is more, the document does not have > clear regsitry format description, eg. Message Type - an integer, > values from 0 to 15 are assigned etc. I propose to create the > separate section and name it 'Regsitry Description' and place a number > of sub-section tehre that would describe the regsutry as detailed as > possible. You are right. The description of the Message Type should be included. In particular the range is very important. This should be added to the end of the paragraph in Section 3. > And in this occasion out the follwoing IANA Considerations' > Section: > > 'IANA is asked to create the 'name' regsitry following Section 2 of > this document." I am not sure what your suggestion is here. Section 3 begins with exactly this request (using different words). > So I recommend not to publih this document in the current view, Agreed. Thanks for catching these issues which can be fixed. > stop > the Last Call, if posible, and work on it a bit more. No, I don't think so. The purpose of a last call is not necessarily to have everyone agree that a document is perfect. The purpose is to catch exactly the type of issue you have raised. I do not believe that your input here (which *is* valuable) results in changes to the I-D that make a fundamental difference to the document that would necessitate a further last call. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call on draft-ietf-pim-registry-03.txt
Hello all, I am writing to provide some review on the draft-ietf-pim-registry, that is currently in Last Call, Furstly, this document does not explain the abreviatures once they has appeared in the title, abstract and main text. Moreover, the initial contents of the regsitry does not mention that values that are Unassigned. What is more, the document does not have clear regsitry format description, eg. Message Type - an integer, values from 0 to 15 are assigned etc. I propose to create the separate section and name it 'Regsitry Description' and place a number of sub-section tehre that would describe the regsutry as detailed as possible. And in this occasion out the follwoing IANA Considerations' Section: 'IANA is asked to create the 'name' regsitry following Section 2 of this document." So I recommend not to publih this document in the current view, stop the Last Call, if posible, and work on it a bit more. All the best, Mykyta Yevstifeyev ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
