Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06

From: Peter Psenak <[email-masked]>
Date: Thu, 15 Oct 2020 11:09:26 +0200

Hi Chris,

I am not aware of any undisclosed IPRs.

thanks,
Peter

On 15/10/2020 08:15, Christian Hoppsprotocol= application/pgp-signature 
wrote:
> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, for:
> 
>    https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
> 
> The following IPR has been filed https://datatracker.ietf.org/ipr/3448/
> 
> Authors,
> 
>    Please indicate to the list, your knowledge of any other IPR related to this work.
> 
> Thanks,
> Chris.
>

---

From: Aijun Wang <[email-masked]>
Date: Mon, 19 Oct 2020 22:42:24 +0800

Hi, John:

Would you like to illustrate your broken case more clearly and not make the conclusion so hurry?

Aijun Wang
China Telecom

> On Oct 19, 2020, at 22:15, John E Drake <jdrake=[email-masked]> wrote:
> 
> Aijun,
> 
> What part of "using IP address advertisement to derive topological data is broken" do you not understand?
> 
> Yours Irrespectively,
> 
> John
> 
> 
> Juniper Business Use Only
> 
>> -----Original Message-----
>> From: Peter Psenak <[email-masked]>
>> Sent: Monday, October 19, 2020 6:32 AM
>> To: Aijun Wang <[email-masked]>; Peter Psenak
>> <ppsenak=[email-masked]>
>> Cc: Les Ginsberg (ginsberg) <[email-masked]>; Aijun Wang
>> <[email-masked]>; Christian Hopps <[email-masked]>; John E
>> Drake <[email-masked]>; [email-masked]; [email-masked]; Jeff Tantsura
>> <[email-masked]>; [email-masked]; lsr-
>> [email-masked]
>> Subject: Re: [Lsr] WG Last Call draft-ietf-lsr-ospf-prefix-originator-06
>> [External Email. Be cautious of content]
>> Hi Aijun,
>> please see inline:
>>> On 19/10/2020 12:10, Aijun Wang wrote:
>>> Hi. Peter, Les:
>>> We have defined many extensions for protocol, but only a small part of them
>> are deployed. Have you ever considered the reason?
>>> Adding more contents for their  potential usages can certainly be helpful for
>> their influences, or else, they will just stay at the IETF repository.
>> I disagree. RFCs are not deployment or use case documents. They exists to
>> address the interoperability.
>>> More replies inline below.
>>> Aijun Wang
>>> China Telecom
>>>> On Oct 19, 2020, at 17:14, Peter Psenak
>> <ppsenak=[email-masked]> wrote:
>>>> Aijun,
>>>>> On 19/10/2020 09:32, Les Ginsberg (ginsberg) wrote:
>>>>> Aijun -
>>>>> I am not going to continue these side discussions with you.
>>>>> The primary purpose of the protocol extensions are as stated in the draft
>> Introduction. This is analogous to the use cases for the equivalent extensions for
>> IS-IS already approved in RFC 7794. We need the equivalent in OSPF.
>>>>> You can show that you are listening to the concerns of WG members by
>> removing the Appendices - in which case you have (I believe) broad support for
>> moving the draft forward.
>>>> I agree with Les.
>>>> As a co-author, I have asked you several times to get rid of the use case
>> described in appendix.
>>> [WAJ] Moving the expansion of this use case from body part of this draft to its
>> appendix is our initial consensus, not remove it totally. We have discussed
>> intensely for its application in vary situations. The discussion results are stated
>> clearly in the appendix.
>> just because you insisted and did not listen to rest of us.
>>> Wish to hear more technical analysis/comments for the current statements of
>> this part from other experts, or from you if you have fresh consideration.
>> we are in a circle. Multiple WG members (Les, Tony P. Acee, Ketan,
>> myself) are telling you that using IP address advertisement to derive topological
>> data is broken and you keep repeating it is valid use case and ask for more
>> reasoning.
>> thanks,
>> Peter
>>>> Trying to use prefix advertisement to derive topological data is simply
>> broken. The reason we are adding the prefix originator extension to OSPF is NOT
>> the broken use case in the appendix of the draft.
>>>> thanks,
>>>> Peter
>>>>> You can then write a separate draft to discuss other use cases and allow the
>> WG to discuss those other use cases w/o preventing the extensions from being
>> approved and deployed for the use cases which have already been
>> demonstrated as useful by IS-IS.
>>>>> If you remove the Appendices I can support the draft.
>>>>> If you do not remove the Appendices I cannot support the draft.
>>>>> Please discuss this with your co-authors and come to consensus on your
>> next step.
>>>>> Les
>>>>>> -----Original Message-----
>>>>>> From: Aijun Wang <[email-masked]>
>>>>>> Sent: Monday, October 19, 2020 12:06 AM
>>>>>> To: Les Ginsberg (ginsberg) <[email-masked]>; 'Christian Hopps'
>>>>>> <[email-masked]>
>>>>>> Cc: 'John E Drake' <[email-masked]>; [email-masked];
>>>>>> [email-masked]; 'Jeff Tantsura' <[email-masked]>;
>>>>>> draft-ietf-lsr-ospf-prefix- [email-masked]; [email-masked]
>>>>>> Subject: RE: [Lsr] WG Last Call
>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>> Hi, Les:
>>>>>> As I stated clearly before, the appendix described in the draft is
>>>>>> not the new use case. It is the start point of this draft.
>>>>>> Have you noticed that the introduction part is not the final usage
>>>>>> of such protocol extension information?
>>>>>> Certainly, we will not expand all the possible use cases in very
>>>>>> detail, but putting some of them(some interesting, prominent use
>>>>>> cases) in the appendix will not hamper the protocol extension itself.
>>>>>> If the statements/descriptions in the appendix are not correct, we
>>>>>> can fix it, or remove it finally.  If not, why not let it be for
>>>>>> reference to the user of such protocol extension?
>>>>>> For the body part of this draft, we are also welcome comments.
>>>>>> More replies inline below[WAJ]
>>>>>> Best Regards
>>>>>> Aijun Wang
>>>>>> China Telecom
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>>> Of Les Ginsberg (ginsberg)
>>>>>> Sent: Monday, October 19, 2020 2:15 PM
>>>>>> To: Aijun Wang <[email-masked]>; 'Christian Hopps'
>>>>>> <[email-masked]>
>>>>>> Cc: 'John E Drake' <[email-masked]>; [email-masked]; 'Les
>>>>>> Ginsberg (ginsberg)' <ginsberg=[email-masked]>;
>>>>>> [email-masked]; 'Jeff Tantsura' <[email-masked]>;
>>>>>> draft-ietf-lsr-ospf-prefix- [email-masked]; [email-masked]
>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>> Aijun -
>>>>>> The "use case" for the protocol extensions is clearly stated in the
>>>>>> Introduction:
>>>>>> "The primary use case for the extensions proposed in this document is
>>>>>> to be able to identify the originator of the prefix in the network.
>>>>>> In cases where multiple prefixes are advertised by a given router, it
>>>>>> is also useful to be able to associate all these prefixes with a
>>>>>> single router even when prefixes are advertised outside of the area
>>>>>> in which they originated.  It also helps to determine when the same
>>>>>> prefix is being originated by multiple routers across areas."
>>>>>> This is equivalent to language in RFC 7794 which defines the
>>>>>> analogous extensions for IS-IS.
>>>>>> Everything you have in the Appendix is not related to the primary
>>>>>> use case - and is fact a use case which many of us have objected to.
>>>>>> [WAJ] Very glad to know the false statements in the appendix.
>>>>>> You are entitled to write another draft advocating for your new use
>>>>>> case if you wish, but requiring that the protocol extensions in
>>>>>> support of the primary use case not go forward without your new use
>>>>>> case is - as Chris has stated very clearly - holding approval of
>>>>>> the protocol extensions hostage to your new use case.
>>>>>> [WAJ] It is not new use case. As I sated before, I am open to this
>>>>>> part, but should on the conditions that the statements in this part are
>> incorrect.
>>>>>> I am asking you (yet again) not to do this.
>>>>>> I cannot support the document moving forward with the content in
>>>>>> the Appendices included.
>>>>>> [WAJ] Would like to hear more technical analysis.
>>>>>> Les
>>>>>>> -----Original Message-----
>>>>>>> From: Lsr <[email-masked]> On Behalf Of Aijun Wang
>>>>>>> Sent: Sunday, October 18, 2020 7:08 PM
>>>>>>> To: 'Christian Hopps' <[email-masked]>
>>>>>>> Cc: 'John E Drake' <[email-masked]>; [email-masked]; 'Les
>>>>>>> Ginsberg (ginsberg)' <ginsberg=[email-masked]>;
>>>>>>> [email-masked]; 'Jeff Tantsura' <[email-masked]>;
>>>>>>> draft-ietf-lsr-ospf-prefix- [email-masked]; [email-masked]
>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>> Hi, Chris:
>>>>>>> I think we have "put the cart before the horse". For protocol
>>>>>>> extension draft, the origin is the use case.
>>>>>>> And I think we will not expand OSPF protocol, just because it lack
>>>>>>> something as compared with ISIS, right?
>>>>>>> As I stated before, the use case in current appendix is the main
>>>>>>> motivation of this draft, you can see this in main body of the
>>>>>>> earlier version of this draft(from version 0 to version 5).
>>>>>>> The reason that we move this part to the appendix, as that you
>>>>>>> said, is to let person focus on the protocol extension itself.
>>>>>>> Moving this part to appendix is acceptable, but removing it from
>>>>>>> the draft will erase the origin of this document.
>>>>>>> Is it reasonable that one document discusses the "origin"(of the
>>>>>>> prefix), can't keep its origin?
>>>>>>> More replies inline below[WAJ].
>>>>>>> Best Regards
>>>>>>> Aijun Wang
>>>>>>> China Telecom
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>>>> Of Christian Hopps
>>>>>>> Sent: Friday, October 16, 2020 10:47 PM
>>>>>>> To: 王爱俊 <[email-masked]>
>>>>>>> Cc: John E Drake <[email-masked]>; Christian Hopps
>>>>>>> <[email-masked]>; [email-masked]; Les Ginsberg (ginsberg)
>>>>>>> <ginsberg=[email-masked]>; [email-masked]; Jeff Tantsura
>>>>>>> <[email-masked]>;
>>>>>>> [email-masked]; lsr- [email-masked]
>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>> Isn't this just adding an analogous extension that already exists in
>> RFC7794?
>>>>>>> [WAJ] No. RFC7794 is just one example that to illustrate, as the
>>>>>>> companion IGP protocol, OSPF can also accomplish this. And,
>>>>>>> actually, there are differences consideration in this draft for the protocol
>> extension.
>>>>>>> I don't think we need to do a lot of convincing at this point. I
>>>>>>> agree with Les, if you want to talk about use cases (especially
>>>>>>> ones that are controversial!) then the correct place for that is
>>>>>>> in a new informative
>>>>>> draft.
>>>>>>> [WAJ] we have discussed the use case before and state the
>>>>>>> discussion results at the appendix part. We will not emphasis and
>>>>>>> expand the use case more. If one does not agree the statement of
>>>>>>> this appendix, we can discuss online or offline. We just need to
>>>>>>> make the statement in
>>>>>> appendix is correct.
>>>>>>> Otherwise, especially if the cases are controversial, this can be
>>>>>>> seen as doing an "end-run" to avoid the debate b/c people want the
>>>>>>> extension, but maybe don't agree with your use case.
>>>>>>> [WAJ] One should point out which statement in the appendix is
>>>>>>> controversial, we can correct it. This use case is the origin of
>>>>>>> this draft, not the results.
>>>>>>> Legislators do this sometimes adding things they want personally
>>>>>>> to popular bills, that other people may not want, but since people
>>>>>>> want the main bill they vote for it anyway, in the US it's called
>>>>>>> "adding pork" or "pork barrel politics". :) [WAJ] The appendix is
>>>>>>> not added later, but exist at the first beginning. This is the
>>>>>>> origin of the bills.
>>>>>>> Thanks,
>>>>>>> Chris.
>>>>>>>> On Oct 16, 2020, at 10:37 AM, 王爱俊 <[email-masked]>
>>>>>>> wrote:
>>>>>>>> Hi, Chris:
>>>>>>>> Originally, the appendix part is within the document, which is
>>>>>>>> the start
>>>>>>> point/main motivation to extend the prefix origin.
>>>>>>>> There may exists other usages of this information. Pack these
>>>>>>>> examples
>>>>>>> into some short sentences or introduction is viable, but expand
>>>>>>> some of them is also helpful.
>>>>>>>> As I known, when we want to do protocol extension, we should
>>>>>>>> always
>>>>>>> convince other the reason/motivation/prospects to do so. On the
>>>>>>> other hand, the use case described in the current appendix is very
>>>>>>> prominent for operator to accomplish the TE task in multi-area
>> environment.
>>>>>>>> Aijun Wang
>>>>>>>> 在2020-10-16，Christian Hopps &lt;[email-masked]&gt;写道:
>>>>>>>> -----原始邮件-----
>>>>>>>> 发件人： Christian Hopps &lt;[email-masked]&gt;
>>>>>>>> 发件时间: 2020年10月16日 星期五
>>>>>>>> 写道: [&quot;Les Ginsberg (ginsberg)&quot;
>>>>>>>> &lt;ginsberg=[email-masked]&gt;]
>>>>>>>> 主题： Re: [Lsr] WG Last Call
>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg)
>>>>>>> <ginsberg=[email-masked]> wrote:
>>>>>>>>> Aijun -
>>>>>>>>> The point I am making is very focused.
>>>>>>>>> This draft is defining a protocol extension. As such it is
>>>>>>>>> necessary that this
>>>>>>> be Standards track as adhering to the normative statements in the
>>>>>>> draft are necessary for interoperability.
>>>>>>>>> What is discussed in the Appendix is a use case. It is not
>>>>>>>>> normative and
>>>>>>> there are strong opinions on both sides as to whether this is an
>>>>>>> appropriate use case or not.
>>>>>>>>> In the context of this draft, I have no interest in trying to
>>>>>>>>> resolve our
>>>>>>> difference of opinion on this use case. I simply want the protocol
>>>>>>> extension to move forward so that we have another tool available.
>>>>>>>>> If you want to write a draft on the use case discussed in the
>>>>>>>>> Appendix
>>>>>>> please feel free to do so. That draft may very well not be
>>>>>>> normative - Informational or BCP may be more appropriate - because
>>>>>>> it will be discussing a deployment scenario and a proposal to use
>>>>>>> defined protocol extensions as one way to solve problems in that
>>>>>>> deployment scenario. Such a draft might also be more appropriate
>>>>>>> in another WG (e.g., TEAS). The merits of using prefix
>>>>>>> advertisements to build a topology
>>>>>> could then be discussed on its own.
>>>>>>>>> Please do not try to avoid having a full discussion of the
>>>>>>>>> merits of using
>>>>>>> prefix advertisements to derive topology by adding it to a draft
>>>>>>> that is (and should be) focused on simple protocol extensions.
>>>>>>>> [As WG member]
>>>>>>>> I find this very compelling and so support the removal of the
>>>>>>>> referred to
>>>>>>> non-normative appendices.
>>>>>>>> Thanks,
>>>>>>>> Chris.
>>>>>>>>> Thanx.
>>>>>>>>> Les
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Aijun Wang <[email-masked]>
>>>>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM
>>>>>>>>>> To: 'Jeff Tantsura' <[email-masked]>; 'John E Drake'
>>>>>>>>>> <[email-masked]>
>>>>>>>>>> Cc: 'Christian Hopps' <[email-masked]>; [email-masked];
>>>>>>>>>> Les Ginsberg
>>>>>>>>>> (ginsberg) <[email-masked]>; [email-masked];
>>>>>>>>>> [email-masked];
>>>>>>>>>> draft-ietf- [email-masked]
>>>>>>>>>> Subject: RE: [Lsr] WG Last Call
>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>>>> Hi, Les, John and Jeff:
>>>>>>>>>> Let's reply you all together.
>>>>>>>>>> In my POV, The standard document should not define solely the
>>>>>>>>>> protocol extension, but their usages in the network deployment.
>>>>>>>>>> As I known, almost all the IETF documents following this style.
>>>>>>>>>> And, before adopting one work, we have often intense discussion
>>>>>>>>>> for what's their usages.
>>>>>>>>>> Such discussion in the mail list and statements in the document
>>>>>>>>>> can certainly assist the reader/user of the document get the
>>>>>>>>>> essence of the standard, and follow them unambiguously.
>>>>>>>>>> Regarding the contents of appendices, as stated in the section,
>>>>>>>>>> "The Appendix A heuristic to rebuild the topology can normally
>>>>>>>>>> be used if all links are numbered." I think this can apply
>>>>>>>>>> almost most of the operator's network, and facilitate the
>>>>>>>>>> inter-area TE path calculation for central controller, or even
>>>>>>>>>> for the head-end router that located in one area that different from
>> the tail- end router.
>>>>>>>>>> Keeping the contents of appendices does not have the negative
>>>>>>>>>> impact of the protocol extension, it is just one reference for
>>>>>>>>>> the usage of this extension.
>>>>>>>>>> One can select not refer to it, if their networks are deployed
>>>>>>>>>> with large amount of unnumbered links. But for others, the
>>>>>>>>>> heuristic
>>>>>> applies.
>>>>>>>>>> Best Regards
>>>>>>>>>> Aijun Wang
>>>>>>>>>> China Telecom
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>>>>>> Behalf Of Jeff Tantsura
>>>>>>>>>> Sent: Friday, October 16, 2020 5:28 AM
>>>>>>>>>> To: John E Drake <jdrake=[email-masked]>
>>>>>>>>>> Cc: Christian Hopps <[email-masked]>; [email-masked];
>>>>>>>>>> Les Ginsberg
>>>>>>>>>> (ginsberg) <ginsberg=[email-masked]>; [email-masked];
>>>>>>>>>> lsr- [email-masked];
>>>>>>>>>> [email-masked]
>>>>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>>>> +1
>>>>>>>>>> Regards,
>>>>>>>>>> Jeff
>>>>>>>>>>> On Oct 15, 2020, at 11:33, John E Drake
>>>>>>>>>> <jdrake=[email-masked]> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>> I agree with Les.  This is a simple protocol extension for a
>>>>>>>>>>> specific purpose
>>>>>>>>>> and there is no reason to include speculation about its use for
>>>>>>>>>> other purposes, particularly when it is inherently not suited for them.
>>>>>>>>>>> Yours Irrespectively,
>>>>>>>>>>> John
>>>>>>>>>>> Juniper Business Use Only
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Lsr <[email-masked]> On Behalf Of Les Ginsberg
>>>>>>>>>>>> (ginsberg)
>>>>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM
>>>>>>>>>>>> To: Christian Hopps <[email-masked]>; [email-masked]
>>>>>>>>>>>> Cc: [email-masked]; [email-masked];
>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix- [email-masked]
>>>>>>>>>>>> Subject: Re: [Lsr] WG Last Call
>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>>>>>> [External Email. Be cautious of content]
>>>>>>>>>>>> I support moving this document forward.
>>>>>>>>>>>> Similar functionality in IS-IS has proved useful.
>>>>>>>>>>>> I would however like to repeat comments I made earlier in the
>>>>>>>>>>>> review of this document.
>>>>>>>>>>>> The content of the Appendices should be removed.
>>>>>>>>>>>> The Appendices define and discuss deriving topology
>>>>>>>>>>>> information from prefix advertisements - which is flawed and
>>>>>>>>>>>> should not be
>>>>>> done.
>>>>>>>>>>>> Perhaps more relevant, the purpose of the document is to
>>>>>>>>>>>> define protocol extensions supporting advertisement of the
>>>>>>>>>>>> originators of a prefix advertisement. There is no need to
>>>>>>>>>>>> discuss how this mechanism might be used to build topology
>> information.
>>>>>>>>>>>> This document should confine itself to defining the protocol
>>>>>>>>>>>> extensions - similar the RFC 7794.
>>>>>>>>>>>> If the authors do not agree to do this, I would encourage
>>>>>>>>>>>> this point to be discussed during IESG review.
>>>>>>>>>>>> Les
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: Lsr <[email-masked]> On Behalf Of Christian
>>>>>>>>>>>>> Hopps
>>>>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM
>>>>>>>>>>>>> To: [email-masked]
>>>>>>>>>>>>> Cc: [email-masked];
>>>>>>>>>>>>> [email-masked]; lsr- [email-masked]; Christian Hopps
>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>> Subject: [Lsr] WG Last Call
>>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06
>>>>>>>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc
>>>>>>>>>>>>> /d
>>>>>>>>>>>>> ra
>>>>>>>>>>>>> ft-i
>>>>>>>>>>>>> et
>>>>>>>>>>>>> f-lsr-ospf-prefix-originator/__;!!NEt6yMaO-
>>>>>>>>>> gk!TaSzQThghtCFOuYPS2VjLq
>>>>>>>>>>>>> hK 8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcjkjClpk$
>>>>>>>>>>>>> The following IPR has been filed
>>>>>>> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/3448/__;!
>>>>>>>>>>>>> !NEt6yMaO-
>>>>>>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcz
>>>>>>>>>>>>> 5KtUHQ$
>>>>>>>>>>>>> Authors,
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Lsr mailing list
>>>>>>>>>>>> [email-masked]
>>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list
>>>>>>>>>>>> in
>>>>>>>>>>>> fo
>>>>>>>>>>>> /lsr
>>>>>>>>>>>> __;!!NEt
>>>>>>>>>>>> 6yMaO-
>> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm
>>>>>>>>>> w8
>>>>>>>>>>>> Lc$
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Lsr mailing list
>>>>>>>>>>> [email-masked]
>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
>>>>>>>>>>> nfo/lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml
>>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Lsr mailing list
>>>>>>>>>> [email-masked]
>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin
>>>>>>>>>> fo/lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9
>>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$
>>>>>>>>> _______________________________________________
>>>>>>>>> Lsr mailing list
>>>>>>>>> [email-masked]
>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
>>>>>>>>> o/lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv
>>>>>>>>> oAZwe64fnzVvizNujmq1M$
>>>>>>> _______________________________________________
>>>>>>> Lsr mailing list
>>>>>>> [email-masked]
>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
>>>>>>> lsr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw
>>>>>>> e64fnzVvizNujmq1M$
>>>>>> _______________________________________________
>>>>>> Lsr mailing list
>>>>>> [email-masked]
>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
>>>>>> sr__;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6
>>>>>> 4fnzVvizNujmq1M$
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> [email-masked]
>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
>>>> __;!!NEt6yMaO-
>> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz
>>>> VvizNujmq1M$
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Aijun Wang <[email-masked]>
Date: Mon, 19 Oct 2020 22:41:38 +0800

Hi, John:

Aijun Wang
China Telecom