Hi, Adrian: I have read your Rtgdir reviews and update suggestions on the current document. Appreciate for your efforts! But, I don’t know why you ignore the issues that you have concerned previously also about the “explicit key” definition of each possible IS-IS TLV/sub-TLV.(Please refer to: https://mailarchive.ietf.org/arch/msg/lsr/Xga5YrD6ObbNDvFFK_nVDXlipJA/). Let’s try to don’t loop the past arguments and make the life better. Then, would you, and also other experts/reviewer that pass this document answer the following simple, straightforward question: Can you concatenate several pieces together without one “explicit key” to identify them belong to the same segment? If the answer is “can”, please tell me how? If the answer is “can’t”, then, where is necessary “explicit key” in this document? And, if there is none of such “explicit key” information, what’s the value of this document? Let’s be clear for the further discussion, the implicit negotiations solution to solve the interoperability is not STANDARD solution. I copied this discussions also to the IESG mail list for further evaluations of the IESG experts. Best Regards Aijun Wang China Telecom 发件人: forwardingalgorithm@xxxxxxxx [mailto:forwardingalgorithm@xxxxxxxx] 代表 Adrian Farrel Many thanks for your responsiveness, Les. V9 addresses all of my nits adequately. I will update the status of my review in the Datatracker. As to… > That said, after posting V9, I thought maybe something like what I show below > might be added to Section 4. I am not convinced it is needed – but let me know > what you think. > > “Each TLV that is part of an MP-TLV MUST be parsable independent of other > TLVs in the MP-TLV. Breaking of a single sub-TLV or other data unit across TLVs > MUST NOT be done.” I agree with you that this is “not needed.” I do believe it would be somewhat helpful to avoid people falling into error. I leave it to you and your co-authors to decide. Cheers, Adrian |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
