Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Ketan Talaulikar]

Hi Aijun,

I am not sure what "logic" you are looking for while being somewhat
dismissive of the arguments/logic provided.

Let us agree to disagree.

At least I've concluded that it is no more fruitful for me to try to
convince you. C'est la vie ...

Thanks,
Ketan


On Tue, Nov 7, 2023 at 11:08 AM Aijun Wang 
wrote:

> Hi, Ketan:
>
> There are many examples within IETF that special values has special
> meanings, please see:
>
> 1)
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
>
> 2)
> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>
> 3)
> https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml
>
> 4) LS-Infinity
>
> Then, please state clearly that why we cannot define specific value for
> prefix originator to indicate the unreachability.
>
> We need the logic that supports your conclusions. Until now, none.
>
> Or anyone else can elaborate the logic more clearly?
>
> Aijun Wang
> China Telecom
>
> On Nov 7, 2023, at 10:19, Ketan Talaulikar  wrote:
>
> 
> Hi Aijun,
>
> I realize that continuing this argument with you is futile.
>
> However, perhaps one last response that I would address not to you but for
> other WG members (if any one is still following this thread).
>
> On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang 
> wrote:
>
>> Hi, Ketan and Les:
>>
>> There are two sub-TLVs to indicate the source information of the prefix
>> within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router
>> Address”
>>
>> What’s you refer to is the first sub-TLV, for the second sub-TLV, we
>> haven’t such statements, this is also true for IS-IS,  as Les pointed out.
>>
>
> KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address
> should be clear to anyone that reads the procedures in Sec 3.
>
>
>>
>>
>> So, contrary to your happiness :) this give us the room to define the
>> specific value to indicate “unreachability”.
>>
>> And, to Ketan again, until now, you don’t explain clearly that if we
>> can’t define specific value for “unreachability” why can we define the
>> specific value for “LS-Infinity”?
>>
>
> KT> For LS-Infinity - please read RFC2328.
>
> Thanks,
> Ketan
>
>
>>
>>
>> Aijun Wang
>> China Telecom
>>
>> On Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) > 40cisco@dmarc.ietf.org> wrote:
>>
>> 
>>
>> Ketan –
>>
>>
>>
>> I am very happy to be wrong in this case. 
>>
>> We are in full agreement.
>>
>>
>>
>> Les
>>
>>
>>
>>
>>
>> *From:* Lsr  *On Behalf Of * Ketan Talaulikar
>> *Sent:* Monday, November 6, 2023 11:52 PM
>> *To:* Les Ginsberg (ginsberg) 
>> *Cc:* John Drake ; Peter Psenak
>> (ppsenak) ; Aijun Wang ;
>> lsr@ietf.org
>> *Subject:* Re: [Lsr] Technical questions for draft about unreachable
>> prefixes announcement
>>
>>
>>
>> Hi Les,
>>
>>
>>
>> I disagree with your reading of RFC9084 (OSPF Prefix Originator).
>>
>>
>>
>> Sec 1
>>
>> This document proposes extensions to the OSPF protocol for the inclusion
>> of information associated with the router originating the prefix along with
>> the prefix advertisement. These extensions do not change the core OSPF
>> route computation functionality.
>>
>>
>>
>> Sec 2.1
>>
>> For intra-area prefix advertisements, the Prefix Source OSPF Router-ID
>> Sub-TLV *MUST* be considered invalid and ignored if the OSPF Router ID
>> field is not the same as the Advertising Router field in the containing
>> LSA. Similar validation cannot be reliably performed for inter-area and
>> external prefix advertisements.¶
>> 
>>
>> A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID
>> field set to 0 *MUST* be considered invalid and ignored. Additionally,
>> reception of such sub-TLVs *SHOULD* be logged as an error (subject to
>> rate limiting).
>>
>> As editor of this document, it is absolutely clear to me that we are
>> referring to the sub-TLV and not the prefix advertisement. So, when the
>> value is set to 0, the sub-TLV is invalid and ignored - the prefix
>> reachability is not at all affected.
>>
>> This is the reason why I am firmly opposed to using Prefix Originator
>> value 0 for UPA or any other indication.
>>
>>
>>
>> I hope I am able to convince you :-)
>>
>>
>>
>> Thanks,
>>
>> Ketan
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) <
>> ginsb...@cisco.com> wrote:
>>
>> To add to what Ketan has stated…
>>
>>
>>
>> draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism
>> for both OSPF and IS-IS i.e., it proposes to use a prefix-originator
>> sub-TLV with address set to 0.0.0.0 to indicate unreachability.
>>
>> For OSPF, this might be considered compatible with RFC 9084 where it is
>> stated that advertisements with “Router ID field set to 0 MUST be
>> considered invalid and ignored” - though Ketan has indicated this usage is
>> undesirable.
>>
>> However, no 

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Ketan:There are many examples within IETF that special values has special meanings, please see:1) https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml2) https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml3) https://www.iana.org/assignments/iana-as-numbers-special-registry/iana-as-numbers-special-registry.xhtml4) LS-InfinityThen, please state clearly that why we cannot define specific value for prefix originator to indicate the unreachability.We need the logic that supports your conclusions. Until now, none.Or anyone else can elaborate the logic more clearly?Aijun WangChina TelecomOn Nov 7, 2023, at 10:19, Ketan Talaulikar  wrote:Hi Aijun,I realize that continuing this argument with you is futile. However, perhaps one last response that I would address not to you but for other WG members (if any one is still following this thread).On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang  wrote:Hi, Ketan and Les:There are two sub-TLVs to indicate the source information of the prefix within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”What’s you refer to is the first sub-TLV, for the second sub-TLV, we haven’t such statements, this is also true for IS-IS,  as Les pointed out.KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address should be clear to anyone that reads the procedures in Sec 3.  So, contrary to your happiness :) this give us the room to define the specific value to indicate “unreachability”.And, to Ketan again, until now, you don’t explain clearly that if we can’t define specific value for “unreachability” why can we define the specific value for “LS-Infinity”?KT> For LS-Infinity - please read RFC2328.Thanks,Ketan Aijun WangChina TelecomOn Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg) 40cisco@dmarc.ietf.org> wrote:







Ketan –
 
I am very happy to be wrong in this case. 

We are in full agreement.
 
    Les
 
 



From: Lsr  On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) 
Cc: John Drake 40yahoo@dmarc.ietf.org>; Peter Psenak (ppsenak) ; Aijun Wang ; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement


 

Hi Les,

 


I disagree with your reading of RFC9084 (OSPF Prefix Originator).


 


Sec 1


This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These
 extensions do not change the core OSPF route computation functionality.


 


Sec 2.1



For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be
 considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements.¶

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be
 considered invalid and ignored. Additionally, reception of such sub-TLVs SHOULD be logged
 as an error (subject to rate limiting).

As editor of this document, it is absolutely clear to me that we are referring to the sub-TLV and not the prefix advertisement. So, when the value is set to 0, the sub-TLV is invalid and ignored
 - the prefix reachability is not at all affected.


This is the reason why I am firmly opposed to using Prefix Originator value 0 for UPA or any other indication.


 


I hope I am able to convince you :-)


 


Thanks,


Ketan


 


 


 


On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg)  wrote:





To add to what Ketan has stated…
 
draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with address set to 0.0.0.0
 to indicate unreachability.
For OSPF, this might be considered compatible with RFC 9084 where it is stated that advertisements with “Router ID field set to 0 MUST be considered invalid and ignored” - though
 Ketan has indicated this usage is undesirable.
However, no equivalent statement was ever made for IS-IS in RFC 7794 – so this simply does not work in the case of IS-IS.
I (among others) pointed this out to the authors of draft-wang multiple times over the years, but my feedback was ignored.
 
Which is an example of why I would like to echo Ketan’s sentiments – let’s please put an end to this non-constructive discussion.
 
The authors of draft-wang have had many opportunities over the years to respond in a more constructive way to feedback. They were also – as Peter has indicated – given an opportunity
 to co-author draft-ietf-lsr-igp-ureach-prefix-announce out of respect for them bringing the problem space to the attention of 

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Ketan Talaulikar]

Hi Aijun,

I realize that continuing this argument with you is futile.

However, perhaps one last response that I would address not to you but for
other WG members (if any one is still following this thread).

On Tue, Nov 7, 2023 at 9:54 AM Aijun Wang  wrote:

> Hi, Ketan and Les:
>
> There are two sub-TLVs to indicate the source information of the prefix
> within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router
> Address”
>
> What’s you refer to is the first sub-TLV, for the second sub-TLV, we
> haven’t such statements, this is also true for IS-IS,  as Les pointed out.
>

KT> I am not a lawyer. The semantics for Prefix Source OSPF Router Address
should be clear to anyone that reads the procedures in Sec 3.


>
>
> So, contrary to your happiness :) this give us the room to define the
> specific value to indicate “unreachability”.
>
> And, to Ketan again, until now, you don’t explain clearly that if we can’t
> define specific value for “unreachability” why can we define the specific
> value for “LS-Infinity”?
>

KT> For LS-Infinity - please read RFC2328.

Thanks,
Ketan


>
>
> Aijun Wang
> China Telecom
>
> On Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg)  40cisco@dmarc.ietf.org> wrote:
>
> 
>
> Ketan –
>
>
>
> I am very happy to be wrong in this case. 
>
> We are in full agreement.
>
>
>
> Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Ketan Talaulikar
> *Sent:* Monday, November 6, 2023 11:52 PM
> *To:* Les Ginsberg (ginsberg) 
> *Cc:* John Drake ; Peter Psenak
> (ppsenak) ; Aijun Wang ;
> lsr@ietf.org
> *Subject:* Re: [Lsr] Technical questions for draft about unreachable
> prefixes announcement
>
>
>
> Hi Les,
>
>
>
> I disagree with your reading of RFC9084 (OSPF Prefix Originator).
>
>
>
> Sec 1
>
> This document proposes extensions to the OSPF protocol for the inclusion
> of information associated with the router originating the prefix along with
> the prefix advertisement. These extensions do not change the core OSPF
> route computation functionality.
>
>
>
> Sec 2.1
>
> For intra-area prefix advertisements, the Prefix Source OSPF Router-ID
> Sub-TLV *MUST* be considered invalid and ignored if the OSPF Router ID
> field is not the same as the Advertising Router field in the containing
> LSA. Similar validation cannot be reliably performed for inter-area and
> external prefix advertisements.¶
> 
>
> A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID
> field set to 0 *MUST* be considered invalid and ignored. Additionally,
> reception of such sub-TLVs *SHOULD* be logged as an error (subject to
> rate limiting).
>
> As editor of this document, it is absolutely clear to me that we are
> referring to the sub-TLV and not the prefix advertisement. So, when the
> value is set to 0, the sub-TLV is invalid and ignored - the prefix
> reachability is not at all affected.
>
> This is the reason why I am firmly opposed to using Prefix Originator
> value 0 for UPA or any other indication.
>
>
>
> I hope I am able to convince you :-)
>
>
>
> Thanks,
>
> Ketan
>
>
>
>
>
>
>
> On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) <
> ginsb...@cisco.com> wrote:
>
> To add to what Ketan has stated…
>
>
>
> draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism
> for both OSPF and IS-IS i.e., it proposes to use a prefix-originator
> sub-TLV with address set to 0.0.0.0 to indicate unreachability.
>
> For OSPF, this might be considered compatible with RFC 9084 where it is
> stated that advertisements with “Router ID field set to 0 MUST be
> considered invalid and ignored” - though Ketan has indicated this usage is
> undesirable.
>
> However, no equivalent statement was ever made for IS-IS in RFC 7794 – so
> this simply does not work in the case of IS-IS.
>
> I (among others) pointed this out to the authors of draft-wang multiple
> times over the years, but my feedback was ignored.
>
>
>
> Which is an example of why I would like to echo Ketan’s sentiments – let’s
> please put an end to this non-constructive discussion.
>
>
>
> The authors of draft-wang have had many opportunities over the years to
> respond in a more constructive way to feedback. They were also – as Peter
> has indicated – given an opportunity to co-author
> draft-ietf-lsr-igp-ureach-prefix-announce out of respect for them bringing
> the problem space to the attention of the WG. They declined – which of
> course is their right. But they do not have the right to endlessly oppose
> the consensus of the WG.
>
>
>
> Let’s please move on.
>
>
>
>Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of *Ketan Talaulikar
> *Sent:* Monday, November 6, 2023 3:01 PM
> *To:* John Drake 
> *Cc:* Peter Psenak (ppsenak) ; Aijun Wang <
> wangai...@tsinghua.org.cn>; lsr@ietf.org
> *Subject:* Re: [Lsr] Technical questions for draft about unreachable
> prefixes announcement
>
>
>
> Hi Aijun,
>
>
>
> As your co-author on the OSPF Prefix Originator RFC, I have 

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Aijun Wang]

Hi, Ketan and Les:There are two sub-TLVs to indicate the source information of the prefix within OSPF——“Prefix Source OSPF Router ID” and “Prefix Source OSPF Router Address”What’s you refer to is the first sub-TLV, for the second sub-TLV, we haven’t such statements, this is also true for IS-IS,  as Les pointed out. So, contrary to your happiness :) this give us the room to define the specific value to indicate “unreachability”.And, to Ketan again, until now, you don’t explain clearly that if we can’t define specific value for “unreachability” why can we define the specific value for “LS-Infinity”?Aijun WangChina TelecomOn Nov 7, 2023, at 09:23, Les Ginsberg (ginsberg)  wrote:







Ketan –
 
I am very happy to be wrong in this case. 

We are in full agreement.
 
    Les
 
 



From: Lsr  On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) 
Cc: John Drake ; Peter Psenak (ppsenak) ; Aijun Wang ; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement


 

Hi Les,

 


I disagree with your reading of RFC9084 (OSPF Prefix Originator).


 


Sec 1


This document proposes extensions to the OSPF protocol for the inclusion of information associated with the router originating the prefix along with the prefix advertisement. These
 extensions do not change the core OSPF route computation functionality.


 


Sec 2.1



For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV MUST be
 considered invalid and ignored if the OSPF Router ID field is not the same as the Advertising Router field in the containing LSA. Similar validation cannot be reliably performed for inter-area and external prefix advertisements.¶

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field set to 0 MUST be
 considered invalid and ignored. Additionally, reception of such sub-TLVs SHOULD be logged
 as an error (subject to rate limiting).

As editor of this document, it is absolutely clear to me that we are referring to the sub-TLV and not the prefix advertisement. So, when the value is set to 0, the sub-TLV is invalid and ignored
 - the prefix reachability is not at all affected.


This is the reason why I am firmly opposed to using Prefix Originator value 0 for UPA or any other indication.


 


I hope I am able to convince you :-)


 


Thanks,


Ketan


 


 


 


On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg)  wrote:





To add to what Ketan has stated…
 
draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with address set to 0.0.0.0
 to indicate unreachability.
For OSPF, this might be considered compatible with RFC 9084 where it is stated that advertisements with “Router ID field set to 0 MUST be considered invalid and ignored” - though
 Ketan has indicated this usage is undesirable.
However, no equivalent statement was ever made for IS-IS in RFC 7794 – so this simply does not work in the case of IS-IS.
I (among others) pointed this out to the authors of draft-wang multiple times over the years, but my feedback was ignored.
 
Which is an example of why I would like to echo Ketan’s sentiments – let’s please put an end to this non-constructive discussion.
 
The authors of draft-wang have had many opportunities over the years to respond in a more constructive way to feedback. They were also – as Peter has indicated – given an opportunity
 to co-author draft-ietf-lsr-igp-ureach-prefix-announce out of respect for them bringing the problem space to the attention of the WG. They declined – which of course is their right. But they do not have the right to endlessly oppose the consensus of the WG.
 
Let’s please move on.
 
   Les
 
 



From: Lsr 
On Behalf Of Ketan Talaulikar
Sent: Monday, November 6, 2023 3:01 PM
To: John Drake 40yahoo@dmarc.ietf.org>
Cc: Peter Psenak (ppsenak) ; Aijun Wang ;
lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes announcement


 

Hi Aijun,

 


As your co-author on the OSPF Prefix Originator RFC, I have stated many times (e.g. [1]) that overloading semantics of Prefix Originator is not a good or clean protocol encoding.
 Semantically, it is wrong and a very bad protocol design in my opinion. Going by this logic, tomorrow, someone would want to encode some different meaning for all 1's value in the originator address. We cannot be doing such (IMHO) HACKS in the protocol encodings.


 


It is better to signal the semantics/meaning explicitly using specific flags that are meaningful.


 


The authors of draft-ppsenak (now a WG document) agreed to this feedback from WG members and incorporated the U/UP flags in their draft. However, the authors of draft-wang seem
 to continue to refuse to accept feedback. It is perhaps one of the reasons why 

Re: [Lsr] Technical questions for draft about unreachable prefixes announcement

[Les Ginsberg (ginsberg)]

Ketan –

I am very happy to be wrong in this case. 
We are in full agreement.

Les


From: Lsr  On Behalf Of Ketan Talaulikar
Sent: Monday, November 6, 2023 11:52 PM
To: Les Ginsberg (ginsberg) 
Cc: John Drake ; Peter Psenak (ppsenak) 
; Aijun Wang ; lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes 
announcement

Hi Les,

I disagree with your reading of RFC9084 (OSPF Prefix Originator).

Sec 1
This document proposes extensions to the OSPF protocol for the inclusion of 
information associated with the router originating the prefix along with the 
prefix advertisement. These extensions do not change the core OSPF route 
computation functionality.

Sec 2.1

For intra-area prefix advertisements, the Prefix Source OSPF Router-ID Sub-TLV 
MUST be considered invalid and ignored if the OSPF Router ID field is not the 
same as the Advertising Router field in the containing LSA. Similar validation 
cannot be reliably performed for inter-area and external prefix 
advertisements.¶

A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF Router ID field 
set to 0 MUST be considered invalid and ignored. Additionally, reception of 
such sub-TLVs SHOULD be logged as an error (subject to rate limiting).

As editor of this document, it is absolutely clear to me that we are referring 
to the sub-TLV and not the prefix advertisement. So, when the value is set to 
0, the sub-TLV is invalid and ignored - the prefix reachability is not at all 
affected.
This is the reason why I am firmly opposed to using Prefix Originator value 0 
for UPA or any other indication.

I hope I am able to convince you :-)

Thanks,
Ketan



On Tue, Nov 7, 2023 at 12:44 AM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
To add to what Ketan has stated…

draft-wang-lsr-prefix-unreachable-annoucement defines the same mechanism for 
both OSPF and IS-IS i.e., it proposes to use a prefix-originator sub-TLV with 
address set to 0.0.0.0 to indicate unreachability.
For OSPF, this might be considered compatible with RFC 9084 where it is stated 
that advertisements with “Router ID field set to 0 MUST be considered invalid 
and ignored” - though Ketan has indicated this usage is undesirable.
However, no equivalent statement was ever made for IS-IS in RFC 7794 – so this 
simply does not work in the case of IS-IS.
I (among others) pointed this out to the authors of draft-wang multiple times 
over the years, but my feedback was ignored.

Which is an example of why I would like to echo Ketan’s sentiments – let’s 
please put an end to this non-constructive discussion.

The authors of draft-wang have had many opportunities over the years to respond 
in a more constructive way to feedback. They were also – as Peter has indicated 
– given an opportunity to co-author draft-ietf-lsr-igp-ureach-prefix-announce 
out of respect for them bringing the problem space to the attention of the WG. 
They declined – which of course is their right. But they do not have the right 
to endlessly oppose the consensus of the WG.

Let’s please move on.

   Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Ketan Talaulikar
Sent: Monday, November 6, 2023 3:01 PM
To: John Drake 
mailto:40yahoo@dmarc.ietf.org>>
Cc: Peter Psenak (ppsenak) mailto:ppse...@cisco.com>>; Aijun 
Wang mailto:wangai...@tsinghua.org.cn>>; 
lsr@ietf.org
Subject: Re: [Lsr] Technical questions for draft about unreachable prefixes 
announcement

Hi Aijun,

As your co-author on the OSPF Prefix Originator RFC, I have stated many times 
(e.g. [1]) that overloading semantics of Prefix Originator is not a good or 
clean protocol encoding. Semantically, it is wrong and a very bad protocol 
design in my opinion. Going by this logic, tomorrow, someone would want to 
encode some different meaning for all 1's value in the originator address. We 
cannot be doing such (IMHO) HACKS in the protocol encodings.

It is better to signal the semantics/meaning explicitly using specific flags 
that are meaningful.

The authors of draft-ppsenak (now a WG document) agreed to this feedback from 
WG members and incorporated the U/UP flags in their draft. However, the authors 
of draft-wang seem to continue to refuse to accept feedback. It is perhaps one 
of the reasons why the WG adopted the draft-ppsenak and not draft-wang.

WG chairs, is there a way to put an end to this debate such that it does not 
continue endlessly?

Thanks,
Ketan

[1] thread 
https://mailarchive.ietf.org/arch/msg/lsr/FNbqHPhphY3GOfw-NWkLjmoRDVs/


On Mon, Nov 6, 2023 at 7:31 PM John Drake 
mailto:40yahoo@dmarc.ietf.org>> wrote:
Aijun,

You castigated Peter for his lack of rigor in his reply to your email, however, 
I think that was completely unfounded.  Further, your reply to Peter seems to 
be argument by emphatic assertion, rather than "technical analysis/comparison".

Thanks,

John

On Monday, November 6, 2023 at