Re: [Isis-wg] Gen-art LC review draft-ietf-isis-tlv-codepoints-00

Robert -

> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@nostrum.com]
> Sent: Sunday, July 20, 2014 8:14 AM
> To: Les Ginsberg (ginsberg); draft-ietf-isis-tlv-codepoints@tools.ietf.org;
> isis-wg@ietf.org; General Area Review Team
> Subject: Re: [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-bounces@ietf.org] On Behalf Of Robert
> Sparks
> >> Sent: Sunday, July 20, 2014 7:27 AM
> >> To: draft-ietf-isis-tlv-codepoints@tools.ietf.org; isis-wg@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.

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.

   Les

> >
> > 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-wg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/isis-wg