Alvaro - Thanx. V2 of the draft has been posted. I believe it addresses all of your comments.
Les > -----Original Message----- > From: Alvaro Retana <[email protected]> > Sent: Monday, June 22, 2020 3:05 PM > To: Les Ginsberg (ginsberg) <[email protected]>; draft-ietf-lsr-isis-invalid- > [email protected] > Cc: [email protected]; [email protected]; Christian Hopps <[email protected]> > Subject: RE: AD Review of draft-ietf-lsr-isis-invalid-tlv-01 > > On June 19, 2020 at 11:49:51 AM, Les Ginsberg wrote: > > > Les: > > Hi! > > Just a couple of in-line answers. > > We should be ready to move forward once you submit the update. > > Thanks!! > > Alvaro. > > > ... > > > I'm writing all this here to have a record of this decision and to > > > give anyone in the WG the opportunity to raise concerns, if any. > > > > [Les:] Just to be sure I understand, you are documenting that we need do > > nothing in this regard? > > Correct. > > > > ... > > > [major] s/5304/5305 Is §3.2 intended to update rfc5304? > > > > [Les:] 3.2 updates RFC 5304 to the extent that it recommends controls for > > behaviors that might not be backwards compatible. (Similar for RFC 6233) > > > > Section 3.3 clearly updates RFC 5305, so I have added that here. > > > > But it is a fair question to ask if RFC 5304 should be added to the list of > > documents updated? It currently is NOT listed - which makes me wonder > why > > we include RFC 6233 in the list of updated documents. > > > > I am inclined to not include either in the list of updated documents. > > > > Please comment. > > I agree that it is not necessary to formally Update either. > > > > > ... > > > [major] An important clarification, which I don't think is explicitly > > > made, is that the behavior for unknown is being applied to disallowed. > > > Not knowing and not expecting (= disallowed) are different things, but > > > this document is saying that the document treats them the same: > > > ignore. I think adding a sentence about that relationship would help > > > a lot, and it may help us cover any cases that may have been missed (I > > > don't think there are any, but just in case)...maybe something like > > > this (I'm sure you can come up with much better words): > > > > > > This document extends the concept of unknown to disallowed. > > > > > > > > > [major] Related to the last comment... The title of the document > > > mentions "Invalid" TLVs. (1) there is no other mention of an invalid > > > TLV in the text, and (2) there is no connection made between "invalid" > > > (in the title) and "disallowed" (in the text). > > > > > > [Les:] It seems to me that Section 3.1 is very clear on this point. I > > prefer not to change/add text as you have suggested. > > > > I did add some examples of "invalid". > > As long as it is clear to other reviewers that invalid, disallowed and > unknown have the same behavior...we can go ahead with no changes. > > > ... > > [Les:] It isn’t clear to me that we have updated RFC3563 - unless you > > presume that anything that alters the registries in any way is considered > > an update to RFC 3563. > > > > RFC3563 created the registry based on RFC 3359 - which had the columns in > > there. > > > > The description of the columns is present in this document to provide > > context for the rest of the document. I don’t believe this description > > represents any change to the registry. > > > > Specifically, we are not proposing that the registry be altered to include > > the description. > > > > If you agree, should we then remove RFC 3563 from the list of RFCs > updated > > by this document?? > > > Yes, I agree. > > BTW, this request.. > > "IANA is requested to update the TLV Codepoints Registry to reference > this document." > > ...is to add a reference to this document, and not to remove the others, > right? > > If so, then maybe "IANA is requested to add this document as a > reference for the TLV Codepoints Registry." might be better. > > > > ... > > > 215 "The additional values for this TLV should be IIH:n, LSP:y, SNP:n, > > > 216 and Purge:y. " > > > > > > [nit] s/y. "/y." > > > > [Les:] This is a direct quote from RFC6232. > > > > Sorry, you don’t get to edit it. 😊 > > Not editing the quote...just the extra space after the period. ;-) _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
