Re: [Gen-art] [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00
Thank you very much for your review, Robert. Thanks for assembling such a clearly written document. The shepherd writeup should have discussed _why_ this document is intended for Proposed Standard. There is no protocol definition here, and nothing to progress on the standards ladder. This is, instead, primarily defining process. Why isn't this being progressed as a BCP? The document does two things: 1)It updates some registries for sub-TLVs defined at http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- codepoints.xhtml As these changes are modifying the format (not the content) of registries used by a number of standards track RFCs it needs to be a standards track document. I don't believe that follows. A BCP could update these documents as well. The registries define the codepoints which are sent on the wire by IS-IS implementations. This is absolutely essential for interoperability. I fail to follow your reasoning that a change to such a registry falls into the BCP bucket. That said, I don't really care about the category - my goal in writing this draft is to satisfy the process requirements to get what amount to editorial changes to the registry done. In this matter I am happy to follow the recommendations from IANA/IESG, Gen-ART, etc. So let's not argue - rather please build consensus with your peers in IANA/IESG as well as the ADs and I will happily agree so long as it accomplishes the original goal. Yes - the IESG can steer this at this point. With regards to the document-as-ps issue, I think we can observe that new or changed IANA considerations have been done under various document classifications. I personally can not get worked over whether this is a BCP or a PS, albeit, as Pete notes, Slightly weird to have this be Standards Track.”. I think having the texts clarified as Adrian suggested in his Discuss is probably the most worthwhile thing we can do here. jari signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00
(Resending due to incorrect e-mail address - please respond to this instead.) Thank you very much for your review, Robert. Thanks for assembling such a clearly written document. The shepherd writeup should have discussed _why_ this document is intended for Proposed Standard. There is no protocol definition here, and nothing to progress on the standards ladder. This is, instead, primarily defining process. Why isn't this being progressed as a BCP? The document does two things: 1)It updates some registries for sub-TLVs defined at http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv- codepoints.xhtml As these changes are modifying the format (not the content) of registries used by a number of standards track RFCs it needs to be a standards track document. I don't believe that follows. A BCP could update these documents as well. The registries define the codepoints which are sent on the wire by IS-IS implementations. This is absolutely essential for interoperability. I fail to follow your reasoning that a change to such a registry falls into the BCP bucket. That said, I don't really care about the category - my goal in writing this draft is to satisfy the process requirements to get what amount to editorial changes to the registry done. In this matter I am happy to follow the recommendations from IANA/IESG, Gen-ART, etc. So let's not argue - rather please build consensus with your peers in IANA/IESG as well as the ADs and I will happily agree so long as it accomplishes the original goal. Yes - the IESG can steer this at this point. With regards to the document-as-ps issue, I think we can observe that new or changed IANA considerations have been done under various document classifications. I personally can not get worked over whether this is a BCP or a PS, albeit, as Pete notes, Slightly weird to have this be Standards Track.”. I think having the texts clarified as Adrian suggested in his Discuss is probably the most worthwhile thing we can do here. jari signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00
Robert - -Original Message- From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: Sunday, July 20, 2014 7:27 AM To: draft-ietf-isis-tlv-codepoi...@tools.ietf.org; isis...@ietf.org; General Area Review Team Subject: [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-isis-tlv-codepoints-00 Reviewer: Robert Sparks Review Date: 20-Jul-2014 IETF LC End Date: 25-Jul-2014 IESG Telechat date: 7-Aug-2014 Summary: Basically ready for publication, but with process nits for the group and the IESG to consider Thanks for assembling such a clearly written document. The shepherd writeup should have discussed _why_ this document is intended for Proposed Standard. There is no protocol definition here, and nothing to progress on the standards ladder. This is, instead, primarily defining process. Why isn't this being progressed as a BCP? The document does two things: 1)It updates some registries for sub-TLVs defined at http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml As these changes are modifying the format (not the content) of registries used by a number of standards track RFCs it needs to be a standards track document. 2)It defines procedures for early allocation of codepoints from the above registry. While an argument could be made that this portion should be BCP, the fact that it is combined with #1 requires that the document be Standards track. Should this Update any of the RFCs that previously defined these registries? Yes - it updates the following RFCs: 5130, 5311 Les ___ Isis-wg mailing list isis...@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00
On 7/20/14, 11:04 AM, Les Ginsberg (ginsberg) wrote: Robert - -Original Message- From: Isis-wg [mailto:isis-wg-boun...@ietf.org] On Behalf Of Robert Sparks Sent: Sunday, July 20, 2014 7:27 AM To: draft-ietf-isis-tlv-codepoi...@tools.ietf.org; isis...@ietf.org; General Area Review Team Subject: [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-isis-tlv-codepoints-00 Reviewer: Robert Sparks Review Date: 20-Jul-2014 IETF LC End Date: 25-Jul-2014 IESG Telechat date: 7-Aug-2014 Summary: Basically ready for publication, but with process nits for the group and the IESG to consider Thanks for assembling such a clearly written document. The shepherd writeup should have discussed _why_ this document is intended for Proposed Standard. There is no protocol definition here, and nothing to progress on the standards ladder. This is, instead, primarily defining process. Why isn't this being progressed as a BCP? The document does two things: 1)It updates some registries for sub-TLVs defined at http://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml As these changes are modifying the format (not the content) of registries used by a number of standards track RFCs it needs to be a standards track document. I don't believe that follows. A BCP could update these documents as well. 2)It defines procedures for early allocation of codepoints from the above registry. While an argument could be made that this portion should be BCP, the fact that it is combined with #1 requires that the document be Standards track. Should this Update any of the RFCs that previously defined these registries? Yes - it updates the following RFCs: 5130, 5311 The document header (and abstract) should be updated to indicate that. Les ___ Isis-wg mailing list isis...@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
