Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

Speaking as WG member: 

> On Nov 3, 2023, at 10:01 AM, Peter Psenak 
>  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 r

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Peter Psenak]

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.


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’ jud

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[John Scudder]

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 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 investig

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[tom petch]

From: Aijun Wang 
Sent: 20 September 2023 10:28

Hi, Tom:

My appeal is that it's unfair to ignore the draft that was put forward THREE 
years earlier than the follower, and we devote intense discussions for this 
topic along the process, but there is no adoption call.


Aijun

That seems clear to me.  I will shut up now and let the process take its course.

Tom Petch



Best Regards

Aijun Wang
China Telecom

-邮件原件-
发件人: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] 代表 tom petch
发送时间: 2023年9月15日 18:41
收件人: Aijun Wang ; John Scudder 
; cho...@chopps.org
抄送: lsr ; draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org
主题: Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable 
Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

From: Aijun Wang 
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.

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  
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  wrote:

From: Lsr  on behalf of Aijun Wang 

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.



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 Wan

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

Aijun, John, 

Technical comments as WG member: 

See inline. 

> On Sep 15, 2023, at 3:08 AM, Aijun Wang  wrote:
> 
> 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.
> 
> Hi, Chris:
> 
> I have asked Acee the following questions 
> (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? 

Given that the WG agreed to solve a specific use case, this is irrelevant. 

>> 2) Which draft is the first to propose explicit signaling for 
>> unreachable information?

Since the mechanism in your draft use an assumption about the value of 
prefix-originator, one could argue that it is not strictly explicit. 
However, the first to provide backward-compatible notification focused on the 
short-lived notification use case was the WG document. 

>> 3) Which draft is the first to propose short lived notification?

I believe Robert Raszuk was the first to bring up the use case on the LSR list 
- well before it was included in any draft.  

>> 4) Which explicit signaling mechanism is simpler?

The draft which the WG rallied behind is much cleaner and based on the WG 
request for explicit unreachable flags. As I mentioned before, it is 
backward-compatible. Your document also requires a capabilities advertisement 
and different behavior depending on whether or not all routers in the area 
support the mechanism (section 5). The WG document is clearly simpler. 


>> 5) Which draft provides more mechanisms to cover more scenarios?

While you purport to support multiple use cases, they conflict with one 
another. For example, the use cases which require a change in OSPF 
advertisement by the other ABR(s) would require knowledge as long as the prefix 
is unreachable. You also have section 7 which is relevant to persistent 
notification and not the short-lived notification agreed upon by the WG.  

Aijun - now that I have answered your questions again, I have one for you that 
you have never answered. 

Why have you rejected attempts to merge the drafts unless they adopted your 
mechanisms???  Why wouldn’t you join the WG draft which has adapted to the 
feedback on the LSR llst and garnered the WG support???  

Since your draft claims to support many use cases, you could still attempt to 
bring it forward as well. However, this should be independent of the WG 
document. 

Thanks,
Acee





>> 
>> 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  
>> 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  wrote:
>>> 
>>> From: Lsr  on behalf of Aijun Wang 
>>> 
>>> 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.
>>> 
>>> 
>>> 
>>> 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 ye

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[tom petch]

From: Aijun Wang 
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.

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/
 )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  
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  wrote:

From: Lsr  on behalf of Aijun Wang 

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.



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  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-w

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

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.Hi, Chris:I have asked Acee the following questions (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 WangChina TelecomOn Sep 15, 2023, at 04:02, John Scudder  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.—JohnOn Sep 14, 2023, at 12:25 PM, tom petch  wrote:From: Lsr  on behalf of Aijun Wang Sent: 14 September 2023 11:38Hi, 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.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 PetchWe 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 WangChina TelecomOn Sep 8, 2023, at 23:16, Acee Lindem  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 implementationand deployment, we are going forward with WG adoption of this document. As the Co-Chair managing the adoption, I don’t seethis optional mechanism as fundamentally changing the IGPs.There was also quite vehement opposition from the authors of draft-wang-lsr-prefix-unreachable-annoucement. This draftpurports to support the same use case as well as others (the archives can be consulted for the discussion). Further discussionof this other draft and the use cases it addresses should be in the context of draft-wang-lsr-prefix-unreachable-annoucementand not the WG draft.Thanks,AceeOn Aug 23, 2023, at 3:58 PM, Acee Lindem  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 listLsr@ietf.orghttps://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$___Lsr mailing listLsr@ietf.orghttps://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Acee Lindem]

> On Sep 14, 2023, at 16:01, John Scudder  
> 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.

There were attempts to merge the drafts but the solutions and use cases are 
different. The WG group consensus was to adopt the technical solution in the WG 
document and it has significant momentum. The 
draft-wang-lsr-prefix-unreachable-annoucement solution purports to solve more 
use cases and could be discussed independently. I consider this closed. 

Thanks,
Acee

> 
> —John
> 
>> On Sep 14, 2023, at 12:25 PM, tom petch  wrote:
>> 
>> From: Lsr  on behalf of Aijun Wang 
>> 
>> 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.
>> 
>> 
>> 
>> 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  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  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
>>> Lsr@ietf.org
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[John Scudder]

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  wrote:
> 
> From: Lsr  on behalf of Aijun Wang 
> 
> 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.
> 
> 
> 
> 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  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  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
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!FBaOZ68azDC2Puoe7BZVn9qBD-T-BvvJIoPE539Fz7ZmoBeBkYkjEH4eFsk7HxvaaacJE5IDNwDbvQ$

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[tom petch]

From: Lsr  on behalf of Aijun Wang 

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.



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://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
 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  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  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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

[Lsr] 【Request AD Step In】 Working Group Adoption of "IGP Unreachable Prefix Announcement" - draft-ppsenak-lsr-igp-ureach-prefix-announce-04

[Aijun Wang]

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://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/,
 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  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  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
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr