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
