Stephane - > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Friday, January 15, 2016 12:08 AM > To: Stefano Previdi (sprevidi) > Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email protected] > Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: Updating > other > drafts > > So I think we have an agreement by duplicating the sender requirement in > the conflict draft.
[Les:] Yes - this will be done. Les > > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:[email protected]] > Sent: Thursday, January 14, 2016 18:39 > To: LITKOWSKI Stephane SCE/OINIS > Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email protected] > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: Updating > other drafts > > Hi Stephane, > > > > On Jan 14, 2016, at 6:12 PM, [email protected] wrote: > > > > Hi Stefano, > > > > My worry is that tomorrow we will have a new protocol, and this KEY > > piece may be forgotten because nothing tells that this is required… > > > why would it be like that ? The conflict resolution can still mandate the > sender behavior that is explicitly stated in the protocol draft. It’s a > matter of > text duplication (and in general, the sender behavior is pretty simple). > > > > and this is a cross protocol behavior that we want. > > > I'm fine to have it in the protocol as far as we have a more global document > telling that all the protocols MUST follow this rule and IMO the architecture > document is a good place. > > > the conflict-resolution draft is the right place. The SR architecture draft > is not > intended to go into such level of details. > > Still, it’s important that each protocol specification has the description of > the > sender behavior. > > > > Now taking into account, that the arch doc is almost closed (even not yet > completely), I'm fine also to have this statement in the conflict-resolution > draft. > > > we’re in agreement. Note that I wouldn’t put it in the arch draft even if it > wasn’t in LC. > > > > This is a really small addition and my preference is clearly to update the > > arch > doc. > > > I don’t agree: > > sender behavior is pretty small but if you want it in the arch doc then you > also > have to include the receiver behavior and this is a different story. > > That’s why we have the conflict draft. > > > > The receiver side for the SRGB part is per protocol as the consensus was in > the thread that cross validation for SRGB is not necessary. > > > I want a generic approach, not specific to a single conflict. SRGB is the > easiest > one but wait for the SID allocation conflict… that’s where the party really > begins. > > So, again, I prefer to see: > > . sender behavior properly documented in each protocol . sender behavior to > also been documented in conflict draft (for completeness) . receiver > behavior (which may imply multi-protocol behavior) documented into the > conflict draft. > . receiver behavior referenced in protocol drafts (i.e.: a reference to the > conflict draft). > > > > We must not mix topic, here the topic is where do we put the sender and > receiver behaviors for the SRGB validation. SID conflicts is another subject > that we also need to discuss : but let's close this one first. > > > I agree on the SID conflict fun… but still sender behavior is pretty simple. > > > > I would also say that both sender and receiver parts are key, > > > indeed but if the sender does the proper thing, most (not all, but most) of > the receiver problems vanish. > > > > and I would not give any priority to one over the other except if now > > vendors stop to produce buggy codes ;) > > > vendors produce features… ;-) > > s. > > > > > > Best regards, > > > > Stephane > > > > > > > > -----Original Message----- > > From: Stefano Previdi (sprevidi) [mailto:[email protected]] > > Sent: Thursday, January 14, 2016 17:08 > > To: LITKOWSKI Stephane SCE/OINIS > > Cc: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email protected] > > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: > > Updating other drafts > > > > Hi Stephane, > > > > to me it’s perfectly fine to have the sender behavior described in the > protocol because this is the critical part of the whole game. > > > > If all implementations behave properly at the sender side, you won’t have > any problem at the receiver side. > > > > Also, the protocol-specific draft is the reference document for any > implementor so it’s important to find all the necessary information so that > routing updates are formatted properly. > > > > Now, the receiver-side can be more complex because the receiver > behavior may involve more than just one protocol. We will come to this > when we will discuss SID allocation conflicts among protocols. Therefore, the > receiver behavior must be described into a protocol-agnostic document. > > > > s. > > > > > > > >> On Jan 14, 2016, at 11:45 AM, [email protected] wrote: > >> > >> [Les:] Just to be sure I understand you, you are advocating putting the > SRGB sender behavior specification in draft-ginsberg-spring-conflict- > resolution as well as the receiver behavior? > >> Sender behavior HAS to be specified in the protocol documents as it > describes the normative behavior of the protocols. > >> > >> [SLI] Well that’s a point of view, but in this case the receiver side has > >> also > to be in the protocols. All depends of the responsibility : is it a protocol > related responsibility or not or a more global architectural requirement that > all the protocols will need defacto to fill. > >> > >> > >> From: Les Ginsberg (ginsberg) [mailto:[email protected]] > >> Sent: Thursday, January 14, 2016 10:21 > >> To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN > >> Cc: [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > >> Updating other drafts > >> > >> Stephane - > >> > >> From: [email protected] > >> [mailto:[email protected]] > >> Sent: Thursday, January 14, 2016 12:27 AM > >> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN > >> Cc: [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > >> Updating other drafts > >> > >> Hi Les, > >> > >> BGP needs also to be taken into account : draft-ietf-idr-bgp-prefix-sid. > >> > >> [Les:] Perhaps. The BGP draft contains a reference to the OSPF draft as > regards SRGB (see Section 4.3) - this might suffice - but in principle I > agree > with you that we need to ensure that all protocols reference the common > conflict resolution document. The authors of the BGP draft should indicate > what language they believe is needed there. > >> > >> IMO, as I already pointed, it would be easier to handle it a single > document rather than in the protocol docs. Moreover we will have the > sender part in many docs, and the receiver part in the spring-conflict- > resolution draft. > >> > >> > >> > >> Inclusion of the sender behavior in draft-ginsberg-spring-conflict- > resolution would then be redundant. I generally resist this because I think > one of two things can happen: > >> > >> 1)The text is – either due to different wording or different context – > subject to a different interpretation. > >> 2)The text is entirely redundant > >> > >> I am open to adding the (redundant) sender text – but I would prefer not > to do so. > >> > >> Les > >> > >> > >> Best Regards, > >> > >> From: Les Ginsberg (ginsberg) [mailto:[email protected]] > >> Sent: Wednesday, January 13, 2016 17:50 > >> To: DECRAENE Bruno IMT/OLN; LITKOWSKI Stephane SCE/OINIS > >> Cc: [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: > >> Updating other drafts > >> > >> (Changed the subject a bit) > >> > >> Here is my proposal as regards the need to update other SR related drafts > regarding handling invalid SRGBs. > >> > >> 1)No need for any change to SR architecture draft. > >> > >> 2) What is already in > >> https://www.ietf.org/id/draft-ietf-isis-segment-routing-extensions-06. > >> txt > >> Section 3.1 > >> > >> “The originating router MUST NOT advertise overlapping ranges. > >> > >> When a router receives multiple overlapping ranges, it MUST conform > >> to the procedures defined in > >> [I-D.ginsberg-spring-conflict-resolution].” > >> > >> We need to add equivalent language to: > >> > >> https://www.ietf.org/id/draft-ietf-ospf-ospfv3-segment-routing- > extensions-04.txt > >> Section 3.2 > >> > >> and > >> > >> https://www.ietf.org/id/draft-ietf-ospf-segment-routing-extensions-06. > >> txt > >> Section 3.2 > >> > >> This makes the conflict resolution draft the authoritative document and > no additional changes to other SR documents will be needed in the future no > matter what changes occur in the conflict resolution draft. > >> > >> Les > >> > >> > >> > >> > >> From: spring [mailto:[email protected]] On Behalf Of Les > >> Ginsberg (ginsberg) > >> Sent: Wednesday, January 06, 2016 9:22 PM > >> To: [email protected]; LITKOWSKI Stephane SCE/OINIS > >> Cc: [email protected] > >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > >> INCONSISTENCY > >> > >> Bruno (AKA Mr. co-chair J) – > >> > >> Please do not worry. IETF process will be followed whatever the changes > may be. > >> > >> At the moment I have not decided whether to recommend changes to > the architecture doc – or the protocol docs – or both. I will likely consult w > the authors of those drafts first to see what seems to make sense. Then the > proposed changes will – as always – be presented to the WG. > >> > >> Les > >> > >> > >> From: [email protected] > [mailto:[email protected]] > >> Sent: Wednesday, January 06, 2016 10:05 AM > >> To: Les Ginsberg (ginsberg); LITKOWSKI Stephane SCE/OINIS > >> Cc: [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > >> INCONSISTENCY > >> > >> Les, > >> > >> <chair hat> > >> > >> [SLI] I’m was not suggesting to use only Adj-SID … as I also do not see a > real use case for that. I’m just saying that the specification does not > prevent > it. So may be let’s prevent it …so we can update the architecture document > saying that advertising a valid SRGB is a must. There is something wrong to > me here, because we will state that a node with invalid SRGB will be treated > as non SR capable while the architecture does not forbid to not have a SRGB > and does not say anything on how the architecture works with no SRGB (we > can only guess that only Adj-SID can be used). > >> > >> > >> [Les2:] OK good – I think we agree on this point also. What is needed is to > ensure that there is appropriate language in the SR architecture draft and/or > the protocol drafts to specify how receiving an invalid SRGB affects the > interpretation of “SR-MPLS capability”. > >> > >> As of today, the SR architecture has passed WG Last Call and his pending > shepherd write up. Are you saying that there is a need to introduce technical > change in the SR architecture? > >> > >> [Les2:] I will take an action item to follow up on that with the various > >> draft > authors. > >> > >> Before introducing such technical change in the document, draft authors > would need to discuss them in the WG. Thanks. > >> > >> </chair hat> > >> > >> -- Bruno > >> > >> > >> From: Les Ginsberg (ginsberg) [mailto:[email protected]] > >> Sent: Tuesday, January 05, 2016 9:30 PM > >> To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; > >> [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > >> INCONSISTENCY > >> > >> Stephane - > >> > >> From: [email protected] > >> [mailto:[email protected]] > >> Sent: Tuesday, January 05, 2016 12:45 AM > >> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > >> INCONSISTENCY > >> > >> Hi Les, > >> > >> Pls find more inline. > >> > >> > >> From: Les Ginsberg (ginsberg) [mailto:[email protected]] > >> Sent: Tuesday, January 05, 2016 00:34 > >> To: LITKOWSKI Stephane SCE/OINIS; DECRAENE Bruno IMT/OLN; > >> [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > >> INCONSISTENCY > >> > >> Stephane - > >> > >> From: [email protected] > >> [mailto:[email protected]] > >> Sent: Monday, January 04, 2016 12:55 AM > >> To: Les Ginsberg (ginsberg); DECRAENE Bruno IMT/OLN; [email protected] > >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > >> INCONSISTENCY > >> > >> Hi Les, > >> > >> Happy new year. > >> [Les:] And to you… > >> > >> I agree with your proposal. > >> The text must state that there must be a local configuration mechanism > that avoids sender to originate overlapping SRGB. > >> > >> [Les:] Hmmm…IS-IS draft (for example) already states (Section 3.1): > >> > >> <snip> > >> The originating router MUST NOT advertise overlapping ranges. > >> > >> When a router receives multiple overlapping ranges, it MUST conform > >> to the procedures defined in [I-D.ginsberg-spring-conflict-resolution]. > >> <end snip> > >> > >> Isn’t this sufficient? > >> > >> [SLI] I missed this, thanks. Anyway from a readability point of view, it > would be good to recall that the protocol documents address the sender > side. Do we have the same for BGP ? > >> The issue with putting this text in the protocol doc, is that you > >> need to ensure that all protocols will always have this restriction. > >> It’s not really a protocol thing, more a configuration management one > >> … > >> > >> [Les2:] If your concern is to make sure that all the protocol documents > provide equivalent language – I agree this should be done and we will do the > diligence necessary to make sure that text is included in all the places > needed. My comment was that adding such a statement in this specification > is really out of place. The right place to state the requirement is in the > sender > specification. I think we agree on this. > >> > >> In this case, as you mention, if a router receives overlapping SRGB, this > >> is a > bad behavior and we cannot guess if the forwarding plane is correctly > programmed or not on the originator, so it is better to avoid it. > >> > >> Now regarding the sentence :” The originating router is considered to be > incapable of supporting the SR-MPLS forwarding plane”. Do we have > something in the architecture document saying that advertising a SRGB is > mandatory to use SR ? Pure theorical example : what if someone wants only > to use Adj-SIDs in SR network ? there is no need to advertise a SRGB. Stating > that the node must be considered as non SR capable is strong, it will also > prevent the usage of Adj-SID which will work well without SRGB. If we > consider that having a SRGB is mandatory, we need to have this requirement > in the architecture document. > >> > >> [Les:] An interesting point. What I am after here is recognition that > without a valid SRGB the indication from a node that it is capable of > “processing SR MPLS encapsulated IPv4/IPv6 packets on all interfaces” does > not apply. > >> You are suggesting that a node which is not capable of supporting SR- > MPLS dataplane for prefix-SIDs should still be allowed to support ADJ-SIDs – > although it would have to be restricted to local SIDs (ADJ-SIDs can be > assigned from the global SID space - just not the most common usage). While > you may be right in that such a practice is not explicitly forbidden by any of > the specifications, I am struggling to find a real world use case. > >> > >> Doing so certainly complicates implementations. Implementations today > verify whether a node supports SR-MPLS before using SR-MPLS > advertisements (prefix-SIDs, ADJ-SIDs). You are proposing that this logic be > enhanced to treat the case where the node has sent an invalid SRGB as if the > node is still SR-MPLS capable but for local SIDs only. I don’t deny this > could be > done – I just don’t understand why. > >> > >> Please help me understand why worrying about this case is useful??? > >> [SLI] I’m was not suggesting to use only Adj-SID … as I also do not see a > real use case for that. I’m just saying that the specification does not > prevent > it. So may be let’s prevent it …so we can update the architecture document > saying that advertising a valid SRGB is a must. There is something wrong to > me here, because we will state that a node with invalid SRGB will be treated > as non SR capable while the architecture does not forbid to not have a SRGB > and does not say anything on how the architecture works with no SRGB (we > can only guess that only Adj-SID can be used). > >> > >> > >> [Les2:] OK good – I think we agree on this point also. What is needed is to > ensure that there is appropriate language in the SR architecture draft and/or > the protocol drafts to specify how receiving an invalid SRGB affects the > interpretation of “SR-MPLS capability”. I will take an action item to follow > up > on that with the various draft authors. > >> > >> Les > >> > >> > >> > >> Les > >> > >> > >> Best regards, > >> > >> Stephane > >> > >> > >> From: spring [mailto:[email protected]] On Behalf Of Les > >> Ginsberg (ginsberg) > >> Sent: Monday, January 04, 2016 06:55 > >> To: DECRAENE Bruno IMT/OLN; [email protected] > >> Subject: [spring] draft-ginsberg-spring-conflict-resolution: SRGB > >> INCONSISTENCY > >> > >> One of the topics discussed in https://datatracker.ietf.org/doc/draft- > ginsberg-spring-conflict-resolution/ is how to handle inconsistent SRGB > advertisements from a given node. > >> > >> The draft defines one possible solution -from Section 2: > >> > >> " Each range is examined in the order it was advertised. If it does > >> not overlap with any advertised range which preceded it the > >> advertised range is used. If the range overlaps with any preceding > >> range it MUST NOT be used and all ranges advertised after the first > >> encountered overlapping range also MUST NOT be used." > >> > >> This is one instance of a class of solutions which attempt to make use of > part of the advertisements even when there is some inconsistency (overlap) > in the set of SRGB ranges received. A more complete discussion of this class > of solutions can be seen in > https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - many thanx > to Bruno for writing this. > >> > >> However, there is an alternative solution which was suggested (notably > by Acee Lindem) after the draft was written. This alternative is to ignore the > entire set of SRGB advertisements and treat the problematic router as if it > were not SR MPLS capable. This alternative was discussed during the > presentation in SPRING WG at IETF94 (see > https://www.ietf.org/proceedings/94/slides/slides-94-spring-2.pdf slide #3). > It is also discussed in Bruno's post > (https://mailarchive.ietf.org/arch/attach/spring/txtk0n56G.txt - see Section > 2.2). > >> > >> The basis of the alternative solution is that a correct implementation > should never allow inconsistent SRGB ranges to be successfully configured > (let alone advertised). So this is not a case of a misconfiguration – it is a > case > of a defective implementation. It then seems appropriate to put the onus on > the originating router to only send valid SRGB advertisements rather than > forcing all the receivers to try to "correct" the invalid information in some > consistent way. This has a number of advantages: > >> > >> 1. It is by far the simplest to implement > >> 2. It isolates the router which is untrustworthy > >> 3. As the problem can only occur as a result of a defective > implementation the behavior of the originating router is unpredictable – it is > therefore safer not to use the information > >> > >> It is worth noting that since the invalid advertisement is the result of > >> some > sort of defect in the originating router’s implementation, it is not safe to > assume that the source will actually be using the advertised SRGB in a > manner consistent with the selective choice made by the receiving routers. > >> > >> I therefore propose that the above quoted text from > https://datatracker.ietf.org/doc/draft-ginsberg-spring-conflict-resolution/ > be replaced with the following: > >> > >> “The set of received ranges is examined . If there is overlap between any > two of the advertised ranges the entire SRGB set is considered invalid and is > ignored. > >> The originating router is considered to be incapable of supporting the SR- > MPLS forwarding plane. Routers which receive an SRGB advertisement with > overlapping ranges SHOULD report the occurrence.” > >> > >> Comments? > >> > >> Les > >> > >> > __________________________________________________________ > ___________ > >> _ ___________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > >> les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >> Thank you. > >> > __________________________________________________________ > ___________ > >> _ ___________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > >> les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >> Thank you. > >> > __________________________________________________________ > ___________ > >> _ ___________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > >> les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >> Thank you. > >> > __________________________________________________________ > ___________ > >> _ ___________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > >> les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >> Thank you. > >> > __________________________________________________________ > ___________ > >> _ ___________________________________________________ > >> > >> Ce message et ses pieces jointes peuvent contenir des informations > >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > >> exploites ou copies sans autorisation. Si vous avez recu ce message > >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que > >> les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > >> > >> This message and its attachments may contain confidential or > >> privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > >> If you have received this email in error, please notify the sender and > delete this message and its attachments. > >> As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > >> Thank you. > >> > >> _______________________________________________ > >> spring mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/spring > > > > > > > __________________________________________________________ > ____________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > > delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > > > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
