Hi Aijun, Please take my email literally. I didn't mean to say anything more or anything to be read between the lines.
Thanks, Ketan On Fri, Oct 25, 2024 at 1:21 PM Aijun Wang <[email protected]> wrote: > > Hi, Ketan: > > I have read your mail. If you mean that currently there are only two IS-IS > TLVs(Type 22 and Type 135) needs to be extended, then all the contents of > section 8.2 should be removed. > > And the sentence in the abstract of this document——“ This document codifies > the common mechanism of extending the TLV content space through multiple > TLVs.”SHOULD be replaced with “This document codifies the “what constitutes a > key” for two IS-IS TLVs.” > > After the above changes, I will support its forwarding. > > Aijun Wang > China Telecom > > On Oct 25, 2024, at 10:30, 【外部账号】Ketan Talaulikar <[email protected]> > wrote: > > > Hi Aijun, > > Since you bring up vagueness and interoperability, please refer to my > suggestion here: > https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/ > > HTH > > Thanks, > Ketan > > > > On Fri, 25 Oct, 2024, 4:32 am Aijun Wang, <[email protected]> wrote: >> >> Hi, Acee and Ketan: >> >> Then, the proposed MP-TLV draft should state clearly that it clarifies the >> “what constitutes a key” for two TLVs only and such definition(“what >> constitutes a key”) for other TLVs are left for further studies or >> clarification. >> >> Even done so, the declaration of “MP-TLV capabilities” has still some >> vagueness: because such declaration is IS-IS TLV type independent, the >> communication peers can’t decide the other side has which one of the MP-TLV >> supported? The interoperability issues will be arose also. >> >> Given there are potential other big IS-IS TLVs >> are emerging, the road to solve such problems will be an dead end. >> >> Aijun Wang >> China Telecom >> >> > On Oct 25, 2024, at 00:57, 【外部账号】Acee Lindem <[email protected]> wrote: >> > >> > Speaking as WG member: >> > >> > I agree totally with Ketan and, at least in my case, stems from the fact >> > that I’m less familiar with IS-IS than OSPF. >> > >> > If there are WG participants who have both the IS-IS expertise and >> > bandwidth, this might be a good topic for an informational draft. >> > >> > We certainly shouldn’t stale this work as documenting the vagaries of >> > IS-IS wasn’t within original purpose or scope of this document. >> > >> > Thanks, >> > Acee >> > >> >> On Oct 24, 2024, at 12:28, Ketan Talaulikar <[email protected]> wrote: >> >> >> >> FWIW those were the reasons why I am supporting publication of this >> >> document after raising the same question originally. >> >> >> >> I think those that are still raising Qs about the "lack of clarity" on >> >> keys should look over the specific TLVs/sub-TLVs and identify what is >> >> not clear. I did that for a good chunk (what I felt were important and >> >> with potential to "grow large") to satisfy myself and I encourage >> >> others that have doubts to do the same. >> >> >> >> If there is something really unclear, we can solve those individual >> >> issues rather than stalling this work. >> >> >> >> Thanks, >> >> Ketan >> >> >> >>> On Thu, Oct 24, 2024 at 9:27 PM Les Ginsberg (ginsberg) >> >>> <[email protected]> wrote: >> >>> >> >>> Changwang – >> >>> >> >>> >> >>> >> _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
