Re: WG Last Call for draft-ietf-isis-reverse-metric-07
"t.petch" <[email protected]> Fri, 29 Dec 2017 10:53:33 -0000
| Newsgroups | gmane.ietf.isis |
|---|---|
| Message-ID | <007601d38094$72d122a0$4001a8c0__1559.91623546488$1514545491$gmane$org@gateway.2wire.net> |
A couple of IANA thoughts on this I-D; "This document requests that IANA allocate from the IS-IS TLV Codepoints Registry a new TLV, " - Is there a particular range that this value should come from? - A note in s.2 asking that TBD be replaced by the value that IANA allocates might be useful for the RFC Editor. - Are the flag bits of this new TLV going to form a new registry? - And a non-IANA thought - what does a receiver do if it receives more than one such TLV? "This document also request that IANA allocate from the link-attribute bit value for sub-TLV 19 of TLV 22." I struggled to parse this initially. Perhaps "This document also requests that IANA allocate a bit from the 'link-attribute bit values for sub-TLV 19 of TLV 22' registry. (That registry title is a bit of a mouthful compounded by the lack of Capitals in the title:-( The coupling between the request to IANA to allocate the bit and the actual definition in the body of the I-D is ... well, non-existent. You should have a something about the octet with a TBD2 (not a second TBD) in section 3.6, a TBD2 in the IANA actions and a request that this be replaced by RFC Editor by the value that IANA allocates. Yes, a reader can deduce all this but the lack of precision is how mistakes are made IMO. RFC5209 has the sort of detail that I would expect. Tom Petch ----- Original Message ----- From: "Naiming Shen (naiming)" <[email protected]>