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

[John E Drake <[e-mail]>]

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 <[e-mail]>
> Sent: Monday, October 19, 2020 6:32 AM
> To: Aijun Wang <[e-mail]>; Peter Psenak
> <ppsenak=[e-mail]>
> Cc: Les Ginsberg (ginsberg) <[e-mail]>; Aijun Wang
> <[e-mail]>; Christian Hopps <[e-mail]>; John E
> Drake <[e-mail]>; [e-mail]; [e-mail]; Jeff Tantsura
> <[e-mail]>; [e-mail]; lsr-
> [e-mail]
> 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=[e-mail]> 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 <[e-mail]>
> >>>> Sent: Monday, October 19, 2020 12:06 AM
> >>>> To: Les Ginsberg (ginsberg) <[e-mail]>; 'Christian Hopps'
> >>>> <[e-mail]>
> >>>> Cc: 'John E Drake' <[e-mail]>; [e-mail];
> >>>> [e-mail]; 'Jeff Tantsura' <[e-mail]>;
> >>>> draft-ietf-lsr-ospf-prefix- [e-mail]; [e-mail]
> >>>> 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: [e-mail] [mailto:[e-mail]] On Behalf
> >>>> Of Les Ginsberg (ginsberg)
> >>>> Sent: Monday, October 19, 2020 2:15 PM
> >>>> To: Aijun Wang <[e-mail]>; 'Christian Hopps'
> >>>> <[e-mail]>
> >>>> Cc: 'John E Drake' <[e-mail]>; [e-mail]; 'Les
> >>>> Ginsberg (ginsberg)' <ginsberg=[e-mail]>;
> >>>> [e-mail]; 'Jeff Tantsura' <[e-mail]>;
> >>>> draft-ietf-lsr-ospf-prefix- [e-mail]; [e-mail]
> >>>> 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 <[e-mail]> On Behalf Of Aijun Wang
> >>>>> Sent: Sunday, October 18, 2020 7:08 PM
> >>>>> To: 'Christian Hopps' <[e-mail]>
> >>>>> Cc: 'John E Drake' <[e-mail]>; [e-mail]; 'Les
> >>>>> Ginsberg (ginsberg)' <ginsberg=[e-mail]>;
> >>>>> [e-mail]; 'Jeff Tantsura' <[e-mail]>;
> >>>>> draft-ietf-lsr-ospf-prefix- [e-mail]; [e-mail]
> >>>>> 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: [e-mail] [mailto:[e-mail]] On Behalf
> >>>>> Of Christian Hopps
> >>>>> Sent: Friday, October 16, 2020 10:47 PM
> >>>>> To: 王爱俊 <[e-mail]>
> >>>>> Cc: John E Drake <[e-mail]>; Christian Hopps
> >>>>> <[e-mail]>; [e-mail]; Les Ginsberg (ginsberg)
> >>>>> <ginsberg=[e-mail]>; [e-mail]; Jeff Tantsura
> >>>>> <[e-mail]>;
> >>>>> [e-mail]; lsr- [e-mail]
> >>>>> 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, 王爱俊 <[e-mail]>
> >>>>> 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;[e-mail]&gt;写道:
> >>>>>> -----原始邮件-----
> >>>>>> 发件人： Christian Hopps &lt;[e-mail]&gt;
> >>>>>> 发件时间: 2020年10月16日 星期五
> >>>>>> 写道: [&quot;Les Ginsberg (ginsberg)&quot;
> >>>>>> &lt;ginsberg=[e-mail]&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=[e-mail]> 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 <[e-mail]>
> >>>>>>>> Sent: Thursday, October 15, 2020 6:51 PM
> >>>>>>>> To: 'Jeff Tantsura' <[e-mail]>; 'John E Drake'
> >>>>>>>> <[e-mail]>
> >>>>>>>> Cc: 'Christian Hopps' <[e-mail]>; [e-mail];
> >>>>>>>> Les Ginsberg
> >>>>>>>> (ginsberg) <[e-mail]>; [e-mail];
> >>>>>>>> [e-mail];
> >>>>>>>> draft-ietf- [e-mail]
> >>>>>>>> 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: [e-mail] [mailto:[e-mail]] On
> >>>>>>>> Behalf Of Jeff Tantsura
> >>>>>>>> Sent: Friday, October 16, 2020 5:28 AM
> >>>>>>>> To: John E Drake <jdrake=[e-mail]>
> >>>>>>>> Cc: Christian Hopps <[e-mail]>; [e-mail];
> >>>>>>>> Les Ginsberg
> >>>>>>>> (ginsberg) <ginsberg=[e-mail]>; [e-mail];
> >>>>>>>> lsr- [e-mail];
> >>>>>>>> [e-mail]
> >>>>>>>> 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=[e-mail]> 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 <[e-mail]> On Behalf Of Les Ginsberg
> >>>>>>>>>> (ginsberg)
> >>>>>>>>>> Sent: Thursday, October 15, 2020 12:33 PM
> >>>>>>>>>> To: Christian Hopps <[e-mail]>; [e-mail]
> >>>>>>>>>> Cc: [e-mail]; [e-mail];
> >>>>>>>>>> draft-ietf-lsr-ospf-prefix- [e-mail]
> >>>>>>>>>> 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 <[e-mail]> On Behalf Of Christian
> >>>>>>>>>>> Hopps
> >>>>>>>>>>> Sent: Wednesday, October 14, 2020 11:15 PM
> >>>>>>>>>>> To: [e-mail]
> >>>>>>>>>>> Cc: [e-mail];
> >>>>>>>>>>> [e-mail]; lsr- [e-mail]; Christian Hopps
> >>>>>>>>>>> <[e-mail]>
> >>>>>>>>>>> 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
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/list
> >>>>>>>>>> in
> >>>>>>>>>> fo
> >>>>>>>>>> /lsr
> >>>>>>>>>> __;!!NEt
> >>>>>>>>>> 6yMaO-
> >>>>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>
> gk!TaSzQThghtCFOuYPS2VjLqhK8p03Fg3L9LuCGXw8C0X6qRQdrHjKDKHcUdm
> >>>>>>>> w8
> >>>>>>>>>> Lc$
> >>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Lsr mailing list
> >>>>>>>>> [e-mail]
> >>>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
> >>>>>>>>> nfo/lsr__;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffml
> >>>>>>>>> e9TvoAZwe64fnzVvizNujmq1M$
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Lsr mailing list
> >>>>>>>> [e-mail]
> >>>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listin
> >>>>>>>> fo/lsr__;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9
> >>>>>>>> TvoAZwe64fnzVvizNujmq1M$
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Lsr mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinf
> >>>>>>> o/lsr__;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9Tv
> >>>>>>> oAZwe64fnzVvizNujmq1M$
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Lsr mailing list
> >>>>> [e-mail]
> >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> >>>>> lsr__;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZw
> >>>>> e64fnzVvizNujmq1M$
> >>>> _______________________________________________
> >>>> Lsr mailing list
> >>>> [e-mail]
> >>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/l
> >>>> sr__;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe6
> >>>> 4fnzVvizNujmq1M$
> >>
> >> _______________________________________________
> >> Lsr mailing list
> >> [e-mail]
> >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr
> >> __;!!NEt6yMaO-
> gk!SVHvqKxo2kRaG3pNWkdiKGIae4721UKLWnffmle9TvoAZwe64fnz
> >> VvizNujmq1M$
> >
> >
> >