[As WG Co-chair] I concur Chris's statement as WG co-chair.
The second adoption call should focus on the changes made since the first one, and whether these changes addressed/fixed the issues raised during the first adoption call. Thanks, Yingzhen On Mon, Jan 15, 2024 at 8:15 AM Les Ginsberg (ginsberg) <[email protected]> wrote: > 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 <[email protected]> On Behalf Of Christian Hopps > > Sent: Wednesday, January 10, 2024 2:17 AM > > To: Huzhibo <[email protected]> > > Cc: Acee Lindem <[email protected]>; Yingzhen Qu > > <[email protected]>; [email protected] > > 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
