Speaking as WG member: > On Nov 3, 2023, at 10:01 AM, Peter Psenak > <[email protected]> wrote: > > Hi John, > > On 31/10/2023 23:01, John Scudder wrote: >> Hi Aijun, >> I apologize for the length of time it’s taken me to respond to your request. >> Having now taken the time to study the question properly, including a review >> of both drafts in question, the WG adoption call, and the subsequent email, >> here’s my take. >> In large part, your position appears to be based on historical precedence — >> your draft was published first. (This is your “follower solution… initiator” >> in the email I’m responding to, as well as the first three “which draft is >> the first” points in your follow-up.) This is true of course. Furthermore, >> although our formal process does not take into account such questions as >> “who came first?” I think it would be safe for me to say that people >> generally do try to do not just what’s required, but what’s right, in terms >> of acknowledging prior work. For this reason, I was a little surprised to >> see no acknowledgment of the contributions of your draft in draft-ppsenak. >> But I think such an acknowledgment — which is a norm, not a requirement — is >> the most you can expect for having published the first > > for the record, I have offered co-authorship to Aijun and rest of the authors > of his draft numerous times. They decided to pursue their draft instead.
I am not sure the reasoning here. The draft (draft-wang-lsr-prefix-unreachable-annoucement) reuses (and some may argue overloads) the Prefix Source Router TLV defined in RFC 9084 (which coincides with existing IS-IS encodings). https://datatracker.ietf.org/doc/rfc9084/ I’m not sure if there is any remote connection here but RFC 9084 has an IPR declaration. It is an IETF friendly one. https://datatracker.ietf.org/ipr/3448/ This draft - https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ has an unfavorable FRAN IPR declaration - although from a different holder: https://datatracker.ietf.org/ipr/6079/ Thanks, Acee > > thanks, > Peter > > > draft that covers the same general subject area as draft-ppsenak. This might > also be a good time to remind you that > draft-wang-lsr-prefix-unreachable-annoucement-00 includes the statement, >> This Internet-Draft is submitted in full conformance with the >> provisions of BCP 78 and BCP 79. >> I encourage you to review BCP 78 if you haven’t recently. >> In short, I’m not persuaded by the first-to-publish argument. >> The other major point made by you, and others advocating for the >> consideration of draft-wang as the WG solution and against draft-ppsenak, is >> that draft-wang is said to cover more cases. (This is “cover more scenarios” >> in your email, as well as point five, “cover more scenarios” in your >> follow-up.) There was some spirited debate about whether the draft does so >> successfully, or not, but I don’t want to take a position on that in this >> email. Rather, what I observe is that since these points were made clearly, >> and repeatedly, in the WG adoption email thread as well as at other times >> previously, it can’t be argued that the WG didn’t know that draft-wang >> claims to address (for example) area partition, and that draft-ppsenak >> explicitly doesn’t. So, this suggests those who supported the adoption of >> draft-ppsenak either implicitly, or explicitly, believed that the additional >> use cases draft-wang claims to address are not important. At least, not >> important to address in this draft, at this time, as part of this adopted WG >> work. >> In your follow-up, you also proposed that “which explicit signaling >> mechanism is simpler” should be a criterion (point four). In my experience, >> this kind of question seldom leads to a useful outcome since it’s so >> subjective. I will say however that many of the people who responded to the >> WG adoption call made it clear they had such considerations in mind, so I >> think there is good reason to think the WG has taken this question into >> account. >> I also want to speak to the questions of whether the WG adoption decision >> was too hasty, whether there should be more deliberation in the WG, and >> whether there should have been a separate adoption call for draft-wang, >> which are points you’ve made emails other than the one I’m replying to. >> Regarding whether it was too hasty — as you say in this email, this work has >> been in progress since 2019. The merits of the solutions have been debated >> extensively. A considerable amount of valuable WG meeting time has been >> devoted to these discussions, as well as a great many emails. It’s hard for >> me to see the WG adoption decision as being made without due deliberation — >> the opposite if anything. Regarding whether there should have been an >> adoption call for draft-wang — our process allows considerable latitude to >> WG chairs in how they choose to run these things. In reviewing this adoption >> call, it seems to me that all participants were clear that in practice and >> regardless of what the subject line was, they were really addressing a >> multi-part question: should the WG work on this area? If so, should the base >> document be draft-ppsenak, or draft-wang? These questions received a full >> airing, as far as I can tell. >> As you know, the IETF runs on “rough consensus”. This is true for WG >> adoptions just as for anything else, and it sometimes requires WG chairs to >> make hard decisions to call a consensus where some WG contributors are “in >> the rough”. After reviewing the WG adoption call, drafts, and history, it >> appears to me that the WG chairs have listened to all the positions put >> forward and considered them, and judged the rough consensus to favor the >> adoption of draft-ppsenak. I don’t see sufficient evidence to make me >> believe I should overrule the WG chairs’ judgment. >> Finally, I will point out that you have many options still open to you if >> you strongly feel that the scenarios that are not covered by the adopted >> document are crucial. >> Thanks for your patience as I investigated this matter, >> —John >> P.S.: As I’ve reviewed the adoption call and subsequent discussion, I’ve >> noticed that tempers have grown a little heated at times. I’d like to remind >> all participants that BCP 54, Guidelines for Conduct, cautions us among >> other things that "IETF participants extend respect and courtesy to their >> colleagues at all times” and "IETF participants have impersonal >> discussions”, and ask that we keep these guidelines in mind. >>> On Sep 14, 2023, at 6:38 AM, Aijun Wang <[email protected]> wrote: >>> >>> Hi, Acee: >>> >>> I admire your efforts for the LSR WG, but for the adoption call of this >>> draft, you have not convinced me, although I gave you large amount of solid >>> facts. >>> Then, it's time to let our AD to step in, to make the non-biased judgement, >>> based on our discussions along the adoption call. >>> >>> We request the WG document be based on the >>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/__;!!NEt6yMaO-gk!EzMeDOJ2CKQMN5BjyxXnXhjJdOHPCa5wJqBo4AHwGRRhiwl1lIneQoxBdHDm1d58PO0NM7tu7IQ4ULrpAq_7Zw$ >>> , because it is the first document to initiate the use case, provide the >>> explicit signaling mechanism, and cover more scenarios. >>> >>> It’s unreasonable to adopt the follower solution and ignore the initiator. >>> We started and lead the discussions THREE years earlier than the current >>> proposal. >>> >>> Aijun Wang >>> China Telecom >>> >>>> On Sep 8, 2023, at 23:16, Acee Lindem <[email protected]> wrote: >>>> >>>> The WG adoption call has completed and there is more than sufficient >>>> support for adoption. >>>> What’s more, vendors are implementing and operators are planning of >>>> deploying the extensions. >>>> Please republish the draft as draft-ietf-lsr-igp-ureach-prefix-announce-00. >>>> >>>> A couple of WG members, while acknowledging the use case, thought that it >>>> would be better satisfied outside of the IGPs. >>>> In fact, they both offered other viable alternatives. However, with the >>>> overwhelming support and commitment to implementation >>>> and deployment, we are going forward with WG adoption of this document. As >>>> the Co-Chair managing the adoption, I don’t see >>>> this optional mechanism as fundamentally changing the IGPs. >>>> >>>> There was also quite vehement opposition from the authors of >>>> draft-wang-lsr-prefix-unreachable-annoucement. This draft >>>> purports to support the same use case as well as others (the archives can >>>> be consulted for the discussion). Further discussion >>>> of this other draft and the use cases it addresses should be in the >>>> context of draft-wang-lsr-prefix-unreachable-annoucement >>>> and not the WG draft. >>>> >>>> Thanks, >>>> Acee >>>> >>>>> On Aug 23, 2023, at 3:58 PM, Acee Lindem <[email protected]> wrote: >>>>> >>>>> LSR Working Group, >>>>> >>>>> This begins the working group adoption call for “IGP Unreachable Prefix >>>>> Announcement” - draft-ppsenak-lsr-igp-unreach-prefix-announce-04. >>>>> Please indicate your support or objection on this list prior to September >>>>> 7th, 2023. >>>>> >>>>> Thanks, >>>>> Acee >>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!EzMeDOJ2CKQMN5BjyxXnXhjJdOHPCa5wJqBo4AHwGRRhiwl1lIneQoxBdHDm1d58PO0NM7tu7IQ4ULpTBQ5vgw$ >>> > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
