I respect that individuals may have different opinions - but it is important to distinguish what is factual from what is not. Opinions based upon false information are clearly compromised.
Please do heed Chris's (as WG chair) admonition to review the first WG adoption thread. That will reveal to you what the substantive objections were. https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0 Please also do examine the delta between the previous version which was put up for WG adoption (V3) and the current version (V8) so you can see what has changed. https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--html Some facts: The substantive objections raised during the first adoption call had nothing to do with use cases - they had to do with: a)The use of a prefix to identify a link between two nodes is a flawed concept. It is not robust enough to be used in cases of unnumbered or Pt-2-MP. b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the potential use cases and do so more robustly than the Stub-link proposal. The latest version of the draft makes no substantive changes to the stub link concept or its advertisement. The only substantive change in the latest version is a reorganization of the presentation of use cases. But lack of clarity in the use cases was not the basis on which first WG adoption call was rejected. In this thread (the second WG adoption call), the authors have asserted that they have addressed the concerns raised in the previous adoption call. They have not. The concept and mechanism to identify a stub link has not changed. In this thread the authors continue to assert that RFC 9346/RFC 5392 cannot address the use cases. This is FALSE. As has been pointed out repeatedly, the existing mechanisms provide a robust means to uniquely identify inter-AS links using endpoint identifiers - be they IPv4/IPv6 addresses or Link IDs. This addresses all cases - numbered and unnumbered. There is therefore no need for a new mechanism. No fact-based argument has been made to justify reconsideration of WG adoption. I hope when people post their opinions, that they consider the facts. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps > Sent: Wednesday, January 10, 2024 2:17 AM > To: Huzhibo <huzhibo=40huawei....@dmarc.ietf.org> > Cc: Acee Lindem <acee.i...@gmail.com>; Yingzhen Qu > <yingzhen.i...@gmail.com>; lsr@ietf.org > Subject: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > [As WG Co-Chair] > > Hi Folks, > > Before posting support reasons please read and considerl > *all* the email in the archive covering the first failed > adoption call. > > https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ > https://www.mail- > archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0 > > This adoption call should be considering if the changes > made to the document since it failed to be adopted the > first time, are sufficient to reverse the WGs previous > decision. > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
