Hi Bruno, Thank you for your comments.
> As a constructive proposal, and as mitigations, I would like the document be > improved with the following changes: > Sending MUST be controlled by configuration [1] > [1] > OLD: It is RECOMMENDED that implementations which support the sending of > MP-TLVs provide configuration controls to enable/disable generation of > MP-TLVs. > NEW: It is REQUIRED that implementations which support the sending of MP-TLVs > provide configuration controls to enable/disable generation of MP-TLVs. As you know, some systems already generate multi-part TLVs. And they lack any controls for doing this today. The language that you’re suggesting would make these systems immediately out of compliance, thereby punishing them for providing leading technology. Furthermore, it is highly unlikely that any implementation is going to actually comply just because of our choice of adjective here. The control is clearly not necessary for interoperability and we should not overuse our ability to place requirements on implementations. We all know that the real power comes from customers who place requirements on vendors and the requirements that we place in RFCs are only meaningful when describing the requirements for correct operation of our protocols. Overextending ourselves dilutes our interoperability requirements. > For existing TLVs (and “any level of sub-TLVs”), details the TLV which could > be advertised with no risks for the network and TLVs which must not be > advertised before all nodes be upgraded. What is ’no risk’? We are not competent to make that assesment. That requires knowing everything about every implementation, past, present, and future and testing the full cross product of those implementations in all possible scenarios. > Given this document typically may require global support before this be > enabled, I think this draft would be a good candidate for the addition of the > relevant yang module as per draft-qgp-lsr-isis-pics-yang [3]. I personally > don’t see a problem with adding a normative reference to an individual draft, > but if I’m wrong, an option for the chairs to consider would be to pause this > adoption call and start an adoption call for draft-qgp-lsr-isis-pics-yang. That would stall this document indefinitely, pending progress on the YANG model. Please recall that this document is already two years old and that this is an adoption call, NOT WGLC. The question on the table is not whether this document is perfect. The question is whether this is worth continuing to work on and whether this document is the correct basis for that work. I would like to see this document published sometime this century. Regards, Tony
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
