Hi Tony, Thanks for your prompt reply. I can live with most of that, just a few follow-ups below.
> On Dec 7, 2023, at 3:45 PM, Tony Li <[email protected]> wrote: > > Hi John, > > Thank you for your comments and suggestions. I’m incorporating most of > them Cool. Looking forward to reviewing version 10. > and only responding to ones that warrant further discussion. Ditto. > […] >> @@ -302,14 +315,23 @@ >> value of the SRGB advertised by all Inside Nodes MUST start at the >> same value. The range advertised for the area will be the minimum of >> all Inside Nodes. >> ++--- >> +jgs: shouldn't the document say something about what to do if >> +either one of the MUST requirements isn't met? >> ++--- > > > If either is not met, it would be a protocol error and major malfunctions > will occur. > The network manager should remedy the problem. I’m not sure that needs to be > called out. > > If you’re suggesting that implementations should complain if those > constraints are > not met, we did not specify that as that would require a walk through the LSDB > that is not otherwise required. Doesn't the area leader already have to do an operation like that, to determine what range to advertise? I had expected to be told what the area leader is supposed to do if it encounters non-overlapping SRGB as it looks for the minimum mentioned in the quoted text. Halt and catch fire? Give up and log an error? Something else? (Also, now that I've looked at that sentence a few more times, a nit: how about "will be the minimum of that advertised by all Inside Nodes"?) […] >> @@ -644,6 +701,28 @@ >> If the inside area supports Traffic Engineering (TE), the Area Leader >> SHOULD copy TE related sub-TLVs [RFC5305] Section 3 to each Extended >> IS Reachability TLV in the Proxy LSP. >> ++--- >> +jgs: what is 4.4.4 and 4.4.5 are specified as MAY. According to the RFC >> +2119 definition of MAY, >> + >> +5. MAY This word, or the adjective "OPTIONAL", mean that an item is >> + truly optional. >> + [etc] >> + >> +That means it would be considered completely reasonable and OK for >> +the area leader to omit both the IS neighbors TLV and end the extended >> +IS neighbors TLV. Would the protocol still function correctly and >> +usefully if both of those TLVs were omitted from the Proxy LSP? Seems >> +as though it wouldn't. >> + >> +I think probably what is going on here is that you're trying to say >> +that ordinarily, only one or the other would be expected, not both. >> +The RFC 2119 keywords seem like a poor fit for expressing this. This >> +seems like a good time to remind you that it's not mandatory to use >> +RFC 2119 keywords, and in cases like these where they hinder, >> +rather than help, clarity, it's worth considering whether you should >> +rewrite the affected text without relying on them. >> ++--- > > > Yes, we would expect one and not both. There’s a sentence that even says > that. You're referring to this sentence, right? "An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, so the Area Leader SHOULD NOT do this." > We intentionally selected 2119 keywords because we wanted to explicitly > say what is permissible. > > Again, the protocol would work syntactically and semantically if things are > omitted, but not meet network architectural requirements. Additionally, > we did not want to preclude filtering, so we did not think that ‘MUST’ was > called > for. I could swallow your justification for the various SHOULDs because you said (my paraphrase) that there isn't any single one of them that's of the essence for the utility of the protocol. However, if you don't advertise either of the IS Neighbors or Extended IS Neighbors TLVs, I don't think you have a useful routing protocol, do you? So, even though neither one of them, individually, is of the essence, collectively they still are. I don't think your text captures this. An example of text that would address this concern is, OLD: An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, so the Area Leader SHOULD NOT do this. NEW: An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors would be functionally redundant, so the Area Leader SHOULD NOT do this. Although considered in isolation, either of these two TLV types may be omitted, at least one MUST be included. That's only an illustration, I don't think it's the most artful way to do it. My own preference would be something more like, change both MAY to “can”, and add something like, The Area Leader MAY omit either the IS Neighbors TLV or the Extended IS Neighbors TLV, but it MUST include at least one of them. If you're stuck on having each subsection stand on its own, you’d put the sentence in twice, once each. But I think you aren't stuck on that, because you only include the "functionally redundant" paragraph I have quoted once. Thanks, —John _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
