Thanks Les -

Robert -

-----Original Message-----
From: Robert Sparks [mailto:rjspa...@nostrum.com]
Sent: Sunday, July 20, 2014 8:14 AM
To: Les Ginsberg (ginsberg); draft-ietf-isis-tlv-codepoi...@tools.ietf.org;
isis...@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-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.
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.

    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...@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

Reply via email to