From: Aijun Wang <[email protected]> Sent: 15 September 2023 08:08 Hi,John:
Thanks in advance for your review for the discussion within the mail list. Normally, the WG adoption call decisions will be coordinated between the Chairs. That’s the reason that I sort the judgement directly from the AD. If the previous results represents only Acee’s preference, we would like to ask Chris to review also all the discussions and expect Chris to solve my concerns that Acee didn’t convince me. The IETF community should respect the initiative idea and adoption decision should be made based on the facts. <tp> Aijun The IETF community works on 'rough consensus and running code' to a greater or lesser extent. The descriptions of our processes do not give hard and fast rules about what constitutes consensus and that flexibility is one of the strengths of the IETF. Consensus is judged, by WG Chairs, AD, IESG, IAB, based on what the mailing lists contain. The judgement can be appealed. The result can be one I-D going forward or two or none. Here we currently have consensus declared for one I-D to go forward. I hear you protest and see that as an implicit appeal but I am unclear what you are appealing. The appeal could be that consensus does not reflect what appeared on the list, that the consensus call was not properly made, that there should have been additional consensus calls and so on. You list facts and that is fine but they are only input to my and others' judgement which we then express in response to a consensus call. The facts may persuade some, they may not persuade others but it is the summation of views expressed on the list that determines the consensus, not facts. Tom Petch Hi, Chris: I have asked Acee the following questions (https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/<https://mailarchive.ietf.org/arch/msg/lsr/Oegys8UjFbc4R1Fw4o8mnZmEJ08/> )and would like to hear your feedback: For the adoption call or merge efforts, I think the WG should consider the following facts: 1) Which draft is the first to provide the use cases? 2) Which draft is the first to propose explicit signaling for unreachable information? 3) Which draft is the first to propose short lived notification? 4) Which explicit signaling mechanism is simpler? 5) Which draft provides more mechanisms to cover more scenarios? The base document should be selected based on the answers of the above questions. John can also refer the above questions when reviewing the past discussions within the list. Aijun Wang China Telecom On Sep 15, 2023, at 04:02, John Scudder <[email protected]> wrote: Tom is right of course, and thank you for pointing it out. (The specific section in RFC 2026 to look at is 6.5.1.) In the meantime, I’ll review the mailing list discussion. However, the most desirable outcome would be to settle things at the WG level without further escalation. —John On Sep 14, 2023, at 12:25 PM, tom petch <[email protected]> wrote: From: Lsr <[email protected]> on behalf of Aijun Wang <[email protected]> Sent: 14 September 2023 11:38 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. <tp> I think that what you have in mind is an appeal, as per RFC2026. The first stage therein is to involve the Chairs, and while Acee is one, he is not the only one. Have you involved the other Chair, on or off list? That would seem to me to be next step. Tom Petch 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!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5KWnyE3KA$ , 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!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$ _______________________________________________ Lsr mailing list [email protected] https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
