Tom, Actually RFC 5029 does not mention anything about handling multiple same link-attribute sub-TLV, it just says if a router does not support this sub-TLV, it will silently ignore the sub-TLV, and this is true for any IS-IS TLV or sub-TLV. If one does not understand, it has to ignore it. Spiting out an error or debug message or not is up to the implementation.
thanks. - Naiming > On Jan 6, 2018, at 11:39 AM, Naiming Shen (naiming) <[email protected]> wrote: > > > Tom, > > Sure. We can add similar wording on that. > > thanks. > - Naiming > >> On Jan 6, 2018, at 4:12 AM, t.petch <[email protected]> wrote: >> >> Naiming >> >> One follow-up comment inline >> >> Tom Petch >> >> ---- Original Message ----- >> From: "Naiming Shen (naiming)" <[email protected]> >> Sent: Saturday, January 06, 2018 12:31 AM >> >>> Hi Tom, >>> >>> Thanks for the review, some replies inline, >>> >>> On Dec 29, 2017, at 2:53 AM, t.petch >> <[email protected]<mailto:[email protected]>> wrote: >>> >>> 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? >>> >>> NS> will add the range. >>> >>> >>> - A note in s.2 asking that TBD be replaced by the value that IANA >>> allocates might be useful for the RFC Editor. >>> >>> NS> will do. >>> >>> >>> - Are the flag bits of this new TLV going to form a new registry? >>> >>> NS> it is not. >>> >>> >>> - And a non-IANA thought - what does a receiver do if it receives more >>> than one such TLV? >>> >>> NS> In section 2, it mentions "A sender MUST only transmit a single >>> Reverse Metric TLV in a IS-IS Hello PDU.” >> >> I know it does, but I also know that we cannot rely on all >> implementations being perfect:-) >> >> Look at some other RFC (e.g. RFC5029) and you will find an action >> defined such as subsequent ones will be ignored, or perhaps that this >> should be treated as a fatal error or .. I suggest something similar >> here although have no strong views what the action should be. >> >> Tom Petch >> >>> "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. >>> >>> >>> NS> OK. >>> >>> (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. >>> >>> >>> NS> will do. >>> >>> thanks. >>> - Naiming >>> >>> 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]<mailto:[email protected]>> >>> >>> >>> >> > _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
