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=40juniper....@dmarc.ietf.org> > 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 <ppse...@cisco.com> >> Sent: Monday, October 19, 2020 6:32 AM >> To: Aijun Wang <wang...@chinatelecom.cn>; Peter Psenak >> <ppsenak=40cisco....@dmarc.ietf.org> >> Cc: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Aijun Wang >> <wangai...@tsinghua.org.cn>; Christian Hopps <cho...@chopps.org>; John E >> Drake <jdr...@juniper.net>; lsr-cha...@ietf.org; lsr@ietf.org; Jeff Tantsura >> <jefftant.i...@gmail.com>; draft-ietf-lsr-ospf-prefix-origina...@ietf.org; >> lsr- >> a...@ietf.org >> 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=40cisco....@dmarc.ietf.org> 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 <wangai...@tsinghua.org.cn> >>>>>> Sent: Monday, October 19, 2020 12:06 AM >>>>>> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; 'Christian Hopps' >>>>>> <cho...@chopps.org> >>>>>> Cc: 'John E Drake' <jdr...@juniper.net>; lsr-cha...@ietf.org; >>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.i...@gmail.com>; >>>>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org >>>>>> 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: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf >>>>>> Of Les Ginsberg (ginsberg) >>>>>> Sent: Monday, October 19, 2020 2:15 PM >>>>>> To: Aijun Wang <wangai...@tsinghua.org.cn>; 'Christian Hopps' >>>>>> <cho...@chopps.org> >>>>>> Cc: 'John E Drake' <jdr...@juniper.net>; lsr-cha...@ietf.org; 'Les >>>>>> Ginsberg (ginsberg)' <ginsberg=40cisco....@dmarc.ietf.org>; >>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.i...@gmail.com>; >>>>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org >>>>>> 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 <lsr-boun...@ietf.org> On Behalf Of Aijun Wang >>>>>>> Sent: Sunday, October 18, 2020 7:08 PM >>>>>>> To: 'Christian Hopps' <cho...@chopps.org> >>>>>>> Cc: 'John E Drake' <jdr...@juniper.net>; lsr-cha...@ietf.org; 'Les >>>>>>> Ginsberg (ginsberg)' <ginsberg=40cisco....@dmarc.ietf.org>; >>>>>>> lsr@ietf.org; 'Jeff Tantsura' <jefftant.i...@gmail.com>; >>>>>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org; lsr-...@ietf.org >>>>>>> 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: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On Behalf >>>>>>> Of Christian Hopps >>>>>>> Sent: Friday, October 16, 2020 10:47 PM >>>>>>> To: 王爱俊 <wangai...@tsinghua.org.cn> >>>>>>> Cc: John E Drake <jdr...@juniper.net>; Christian Hopps >>>>>>> <cho...@chopps.org>; lsr-cha...@ietf.org; Les Ginsberg (ginsberg) >>>>>>> <ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org; Jeff Tantsura >>>>>>> <jefftant.i...@gmail.com>; >>>>>>> draft-ietf-lsr-ospf-prefix-origina...@ietf.org; lsr- a...@ietf.org >>>>>>> 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, 王爱俊 <wangai...@tsinghua.org.cn> >>>>>>> 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 <cho...@chopps.org>写道: >>>>>>>> -----原始邮件----- >>>>>>>> 发件人： Christian Hopps <cho...@chopps.org> >>>>>>>> 发件时间: 2020年10月16日 星期五 >>>>>>>> 写道: ["Les Ginsberg (ginsberg)" >>>>>>>> <ginsberg=40cisco....@dmarc.ietf.org>] >>>>>>>> 主题： Re: [Lsr] WG Last Call >>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>> On Oct 16, 2020, at 1:51 AM, Les Ginsberg (ginsberg) >>>>>>> <ginsberg=40cisco....@dmarc.ietf.org> 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 <wangai...@tsinghua.org.cn> >>>>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM >>>>>>>>>> To: 'Jeff Tantsura' <jefftant.i...@gmail.com>; 'John E Drake' >>>>>>>>>> <jdr...@juniper.net> >>>>>>>>>> Cc: 'Christian Hopps' <cho...@chopps.org>; lsr-cha...@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org; >>>>>>>>>> lsr-...@ietf.org; >>>>>>>>>> draft-ietf- lsr-ospf-prefix-origina...@ietf.org >>>>>>>>>> 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: lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] On >>>>>>>>>> Behalf Of Jeff Tantsura >>>>>>>>>> Sent: Friday, October 16, 2020 5:28 AM >>>>>>>>>> To: John E Drake <jdrake=40juniper....@dmarc.ietf.org> >>>>>>>>>> Cc: Christian Hopps <cho...@chopps.org>; lsr-cha...@ietf.org; >>>>>>>>>> Les Ginsberg >>>>>>>>>> (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org>; lsr@ietf.org; >>>>>>>>>> lsr- a...@ietf.org; >>>>>>>>>> draft-ietf-lsr-ospf-prefix-origina...@ietf.org >>>>>>>>>> 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=40juniper....@dmarc.ietf.org> 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 <lsr-boun...@ietf.org> On Behalf Of Les Ginsberg >>>>>>>>>>>> (ginsberg) >>>>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM >>>>>>>>>>>> To: Christian Hopps <cho...@chopps.org>; lsr@ietf.org >>>>>>>>>>>> Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; >>>>>>>>>>>> draft-ietf-lsr-ospf-prefix- origina...@ietf.org >>>>>>>>>>>> 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 <lsr-boun...@ietf.org> On Behalf Of Christian >>>>>>>>>>>>> Hopps >>>>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM >>>>>>>>>>>>> To: lsr@ietf.org >>>>>>>>>>>>> Cc: draft-ietf-lsr-ospf-prefix-origina...@ietf.org; >>>>>>>>>>>>> lsr-cha...@ietf.org; lsr- a...@ietf.org; Christian Hopps >>>>>>>>>>>>> <cho...@chopps.org> >>>>>>>>>>>>> Subject: [Lsr] WG Last Call >>>>>>>>>>>>> draft-ietf-lsr-ospf-prefix-originator-06 >>>>>>>>>>>>> This begins a 2 week WG Last Call, ending after Oct 29th, 2020, >> for: >>>>>>>>>>>>> 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, >>>>>>>>>>>>> Please indicate to the list, your knowledge of any other IPR >>>>>>>>>>>>> related to this work. >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Chris. >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Lsr mailing list >>>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list >>>>>>>>>>>> in >>>>>>>>>>>> fo >>>>>>>>>>>> /lsr >>>>>>>>>>>> __;!!NEt >>>>>>>>>>>> 6yMaO- >> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm >>>>>>>>>> w8 >>>>>>>>>>>> Lc$ >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Lsr mailing list >>>>>>>>>>> Lsr@ietf.org >>>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>>>>>>>> nfo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml >>>>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>>> _______________________________________________ >>>>>>>>>> Lsr mailing list >>>>>>>>>> Lsr@ietf.org >>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin >>>>>>>>>> fo/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9 >>>>>>>>>> TvoAZwe64fnzVvizNujmq1M$ >>>>>>>>> _______________________________________________ >>>>>>>>> Lsr mailing list >>>>>>>>> Lsr@ietf.org >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf >>>>>>>>> o/lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv >>>>>>>>> oAZwe64fnzVvizNujmq1M$ >>>>>>> _______________________________________________ >>>>>>> Lsr mailing list >>>>>>> Lsr@ietf.org >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>>>>>> lsr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw >>>>>>> e64fnzVvizNujmq1M$ >>>>>> _______________________________________________ >>>>>> Lsr mailing list >>>>>> Lsr@ietf.org >>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l >>>>>> sr__;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6 >>>>>> 4fnzVvizNujmq1M$ >>>> _______________________________________________ >>>> Lsr mailing list >>>> Lsr@ietf.org >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr >>>> __;!!NEt6yMaO- >> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz >>>> VvizNujmq1M$ > _______________________________________________ > 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
