Re: WG LC draft-ietf-idr-flowspec-path-redirect-10.txt [11/17/2019 to 12/2/2019]
Robert Raszuk <[email protected]> Fri, 29 Nov 2019 15:01:30 +0100
| Newsgroups | gmane.ietf.idr |
|---|---|
| Message-ID | <CAOj+MMG_6SAs3_Pay_=14s02euTCuQex+VXaOY1op4q2-H8o3A@mail.gmail.com> |
--===============2691620477443095100== Content-Type: multipart/alternative; boundary="00000000000097f6ff05987cab51" --00000000000097f6ff05987cab51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Gunter, What is there to validate ? You validate if the flow spec update is legitimate and at most comparing destination match against unicast src which in all of redirect use cases will be disabled anyway - you can not possibly consider valid rule to redirect coming from your eBGP peer :). Also pls observe that you never validate actual actions ... what I am suggesting is just a little add-on in actions. Thx, R. On Fri, Nov 29, 2019 at 11:13 AM Gunter Van De Velde < [email protected]> wrote: > Hi Robert, > > While understanding your point, it does feel like opening a potential can > of worms with respect to validation of all possible combinations humanly > possible. Is the use-case for this capability solid enough that we need > this complication? There seems nothing broken with keeping things simple. > > G/ > > Sent from iCloud > > On November 29, 2019 at 10:34 AM, Robert Raszuk <[email protected]> wrote= : > > Gunter, > > To your and Jeff's point regarding multiple redirect rules I have a bit > different perspective. > > First let's observe that redirect could be realized in two forms (both ar= e > valid and used in practice): > > -A- redirect of the original flow > -B- redirect of copy of the flow > > See while in -A- clearly one redirect must be used, in -B- on the > other hand multiple redirects should be supported. One span, one security > TAP, one TCP analyzer etc ... > > Your draft defines -A-. To add -B- all what is needed is just one bit > flag. > > Would you consider it ? > > Cheers, > R. > > > > > > On Fri, Nov 29, 2019 at 4:51 AM Van De Velde, Gunter (Nokia - BE/Antwerp)= < > [email protected]> wrote: > >> Hi Jeff, >> >> Thanks for the feedback and suggestions. >> >> See inline: *GV>* >> >> -----Original Message----- >> From: Idr <[email protected]> On Behalf Of Jeffrey Haas >> Sent: Thursday, November 28, 2019 20:21 >> To: Sue Hares <[email protected]> >> Cc: [email protected] >> Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.txt >> [11/17/2019 to 12/2/2019] >> >> Sue, >> >> >> >> > On Nov 18, 2019, at 12:41 AM, Susan Hares <[email protected]> wrote: >> > >> > This begins a 2 week WG Last call on >> draft-idr-flowspec-path-redirect-10.txt from [11/17/2019 to 12/2/2019]. >> > >> > You can obtain the draft at: >> > >> > https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect= / >> > >> > Consider in your review whether this draft: >> > >> > 1) Is compatible with draft-ietf-rfc5575bis-17.txt? >> >> Yes. (Close enough.) The current version of the draft is implementable= .. >> >> > 2) Whether the draft is useful for deployments of flow >> specification >> >> It can be useful. >> >> > 3) Is this technology ready for deployment? >> > 4) Is the write-up of this technology in >> draft-ietf-idr-flowspec-path-redirect clearly written and ready for >> publication? >> >> Ready with minor issues, IMO: >> >> Procedure-wise, there needs to be a bit more text covering cases about >> interactions with other traffic actions. This was a known headache for >> similar drafts such as redirect-to-ip. In particular, interaction with >> redirect-to-ip and redirect-to-vrf is needed. >> >> GV> Section =E2=80=9C6. Validation Procedures=E2=80=9D gives input on th= is. We discussed >> this with you long ago and hence this text was added. >> >> =E2=80=9C >> While it MUST NOT happen, and is seen as invalid combination, it is >> possible from a semantics perspective to have multiple clashing >> redirect actions defined within a single flowspec rule. For best and >> consistant compatibility with legacy implementations, the redirect >> functionality as documented by rfc5575bis MUST NOT be broken, and >> hence when a clash occurs, then rfc5575bis based redirect MUST take >> priority. >> =E2=80=9C >> >> This means that redirect-to-VRF will take absolute priority to not break >> rfc5575bis behavior. >> Having also redirect-to-ip will result in an invalid >> >> >> The text "A single flowspec rule MUST NOT have more as one indirection-i= d >> per S-ID. On a flowspec client the indirection-id with lowest S-ID MUST= be >> imposed first for any given flowspec entry." There's no procedure for w= hat >> happens in error handling when you do have more than one of the same S-I= D. >> The text about the case for S-ID of 0 is also a bit ambiguous. It feels >> like it's reading "there is no sequence", but what do you do when you th= en >> have ones that do? >> >> *GV>* What about the following rewrite: >> >> Original: >> The 'S-ID' field identifies a 4 bit Sequence ID field. This field is >> used to provide a flowspec client an indication how and where to >> sequence the received indirection-ids. The Sequence ID value 0 >> indicates that Sequence ID field is NOT set and SHOULD be ignored. A >> single flowspec rule MUST NOT have more as one indirection-id per >> S-ID. On a flowspec client the indirection-id with lowest S-ID MUST >> be imposed first for any given flowspec entry. >> >> New: >> The 'S-ID' field identifies a 4 bit Sequence ID field. This field is >> used to provide a flowspec client an indication how and where to >> sequence the received indirection-ids. The Sequence ID value 0 >> indicates that Sequence ID field is NOT set and *****all** other >> sequence ID's*** >> SHOULD be ignored. A >> single flowspec rule MUST NOT have more as one indirection-id per >> S-ID. On a flowspec client the indirection-id with lowest S-ID MUST >> be imposed first for any given flowspec entry. >> >> *GV>* In section *6. Validation procedure" there is text to handle the >> error condition when the flowspec rule results in an invalid redirection= , >> that prescribe what needs to happen when the =E2=80=9Credirect to indire= ction-id=E2=80=9D >> does not result in a valid redirection: >> >> " >> While it MUST NOT happen, and is seen as invalid combination, it is >> possible from a semantics perspective to have multiple clashing >> redirect actions defined within a single flowspec rule. For best and >> consistant compatibility with legacy implementations, the redirect >> * functionality as documented by rfc5575bis MUST NOT be broken*, and >> hence when a clash occurs, then *rfc5575bis based redirect MUST take* >> * priority*. Additionally, if the "Redirect to indirection-id" does >> not >> result in a valid redirection, then the flowspec rule MUST be >> processed as if the "Redirect to indirection-id" community was not >> attached to the flowspec route. >> " >> >> *GV>* Is there more to add to this? (We could add a line to detail that >> =E2=80=9Credirect-to-ip=E2=80=9D is incompatible with =E2=80=9Credirect = to indirection-id=E2=80=9D and >> result in invalid redirection rule, however to me that is already implie= d >> with enough detail in the text above) >> >> A few IANA issues: >> I see the type registry is currently registered with IANA (code point >> 0x09). However, the sub-type registry is not established for some reaso= n? >> The ID-Type field likely needs its own IANA registry. Values 1-5 are >> defined in this draft. >> >> *GV>* Correct. There is a reason for this. When we asked IANA the >> code-points they informed me that once the document get to RFC the sub-t= ype >> registry will be established by IANA. >> >> The flags field (one octet) currently has 3 bits reserved. In the past, >> we've not done a registry for such cases (c.f. graceful restart) until w= e >> need to start carving out those reserved bits for future extensions. I >> leave it to the chairs' opinion whether we want this a priori or not. >> >> *G/* >> >> >> > >> > Thank you for considering this draft. >> > >> > Cheerily, Susan Hares >> > >> > _______________________________________________ >> > Idr mailing list >> > [email protected] >> > https://www..ietf.org/mailman/listinfo/idr >> <https://www.ietf.org/mailman/listinfo/idr> >> >> _______________________________________________ >> Idr mailing list >> [email protected] >> https://www.ietf..org/mailman/listinfo/idr >> <https://www.ietf.org/mailman/listinfo/idr> >> >> _______________________________________________ >> Idr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/idr >> > _______________________________________________ > Idr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/idr > > --00000000000097f6ff05987cab51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Gunter,<div><br></div><div>What is there to validate ? You= validate if the flow spec update is legitimate and at most comparing desti= nation match against unicast src which in all of redirect use cases will be= disabled anyway - you can not possibly consider valid rule to redirect com= ing from your eBGP peer :).=C2=A0</div><div><br></div><div>Also pls observe= that you never validate actual actions ... what I am suggesting is just a = little add-on in actions.=C2=A0</div><div><br></div><div>Thx,</div><div>R.<= /div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a= ttr">On Fri, Nov 29, 2019 at 11:13 AM Gunter Van De Velde <<a href=3D"ma= ilto:[email protected]">[email protected]</a>> w= rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p= x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>= Hi Robert,</div><div><br></div><div>While understanding your point, it does= feel like opening a=C2=A0potential can of worms=C2=A0with respect to valid= ation of all possible combinations humanly possible. Is the use-case for th= is capability solid enough that we need this complication? There seems noth= ing broken with keeping things simple.=C2=A0</div><div><br></div><div>G/</d= iv><div><br></div><div>Sent from iCloud</div><div><br>On November 29, 2019 = at 10:34 AM, Robert Raszuk <<a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a>> wrote:<br><br></div><div><blockquote = type=3D"cite"><div><div dir=3D"ltr">Gunter,<div><br></div><div>To your and = Jeff's point regarding multiple redirect rules I have a bit different p= erspective.=C2=A0</div><div><br></div><div>First let's observe that red= irect could be realized in two forms (both are valid and used in practice):= =C2=A0</div><div><br></div><div>-A- redirect=C2=A0of the original flow=C2= =A0</div><div>-B- redirect of copy of the flow=C2=A0</div><div><br></div><d= iv>See while in -A- clearly one redirect must be used, in -B- on the other= =C2=A0hand multiple redirects should be supported. One span, one security T= AP, one TCP analyzer etc ...=C2=A0</div><div><br></div><div>Your draft defi= nes -A-. To add -B- all what is needed is just one bit flag.=C2=A0</div><di= v><br></div><div>Would you consider it ?=C2=A0</div><div><br></div><div>Che= ers,</div><div>R.</div><div><br></div><div><br></div><div><br></div><div><b= r></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai= l_attr">On Fri, Nov 29, 2019 at 4:51 AM Van De Velde, Gunter (Nokia - BE/An= twerp) <<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div><span face=3D"Calibri" size=3D"2" sty= le=3D"font-family:Calibri;font-size:small"><span style=3D"font-size:11pt"><= div>Hi Jeff,</div><div>=C2=A0</div><div>Thanks for the feedback and suggest= ions.</div><div>=C2=A0</div><div>See inline: <span color=3D"#4472C4" style= =3D"color:rgb(68,114,196)"><b>GV></b></span></div><a name=3D"m_-53202312= 61738326584_m_-6399825029355686769__MailEndCompose"></a><div>=C2=A0</div><d= iv>-----Original Message-----<br> From: Idr <<a href=3D"mailto:idr-bounc= [email protected]" target=3D"_blank">[email protected]</a>> On Behalf Of Je= ffrey Haas<br> Sent: Thursday, November 28, 2019 20:21<br> To: Sue Hares &l= t;<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&= gt;<br> Cc: <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<= /a><br> Subject: Re: [Idr] WG LC draft-ietf-idr-flowspec-path-redirect-10.t= xt [11/17/2019 to 12/2/2019]</div><div>=C2=A0</div><div>Sue,</div><div>=C2= =A0</div><div>=C2=A0</div><div>=C2=A0</div><div>> On Nov 18, 2019, at 12= :41 AM, Susan Hares <<a href=3D"mailto:[email protected]" target=3D"_blank= ">[email protected]</a>> wrote:</div><div>></div><div>> This begins = a 2 week WG Last call on draft-idr-flowspec-path-redirect-10.txt from [11/1= 7/2019 to 12/2/2019].</div><div>>=C2=A0</div><div>> You can obtain th= e draft at:</div><div>>=C2=A0</div><div>> <a href=3D"https://datatrac= ker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/" target=3D"_blank">= https://datatracker.ietf.org/doc/draft-ietf-idr-flowspec-path-redirect/</a>= </div><div>>=C2=A0</div><div>> Consider in your review whether this d= raft:</div><div>>=C2=A0</div><div>> 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Is compatible with draft-ietf-rfc5575bis-17.txt?</div><div>=C2=A0</div><div= >Yes.=C2=A0 (Close enough.)=C2=A0 The current version of the draft is imple= mentable.</div><div>=C2=A0</div><div>> 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Whether the draft is useful for deployments of flow specification</div><div= >=C2=A0</div><div>It can be useful.</div><div>=C2=A0</div><div>> 3)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Is this technology ready for deployment?</div><= div>> 4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Is the write-up of this technolog= y in draft-ietf-idr-flowspec-path-redirect clearly written and ready for pu= blication?</div><div>=C2=A0</div><div>Ready with minor issues, IMO:</div><d= iv>=C2=A0</div><div>Procedure-wise, there needs to be a bit more text cover= ing cases about interactions with other traffic actions.=C2=A0 This was a k= nown headache for similar drafts such as redirect-to-ip.=C2=A0 In particula= r, interaction with redirect-to-ip and redirect-to-vrf is needed.</div><div= >=C2=A0</div><div>GV> Section =E2=80=9C6. Validation Procedures=E2=80=9D= gives input on this. We discussed this with you long ago and hence this te= xt was added.</div><div>=C2=A0</div><div>=E2=80=9C</div><div>=C2=A0=C2=A0 W= hile it MUST NOT happen, and is seen as invalid combination, it is</div><di= v>=C2=A0=C2=A0 possible from a semantics perspective to have multiple clash= ing</div><div>=C2=A0=C2=A0 redirect actions defined within a single flowspe= c rule.=C2=A0 For best and</div><div>=C2=A0=C2=A0 consistant compatibility = with legacy implementations, the redirect</div><div>=C2=A0=C2=A0 functional= ity as documented by rfc5575bis MUST NOT be broken, and</div><div>=C2=A0=C2= =A0 hence when a clash occurs, then rfc5575bis based redirect MUST take</di= v><div>=C2=A0=C2=A0 priority.</div><div>=E2=80=9C</div><div>=C2=A0</div><di= v>This means that redirect-to-VRF will take absolute priority to not break = rfc5575bis behavior.</div><div>Having also redirect-to-ip will result in an= invalid</div><div>=C2=A0</div><div>=C2=A0</div><div>The text "A singl= e flowspec rule MUST NOT have more as one indirection-id per S-ID.=C2=A0 On= a flowspec client the indirection-id with lowest S-ID MUST be imposed firs= t for any given flowspec entry."=C2=A0 There's no procedure for wh= at happens in error handling when you do have more than one of the same S-I= D.=C2=A0 The text about the case for S-ID of 0 is also a bit ambiguous.=C2= =A0 It feels like it's reading "there is no sequence", but wh= at do you do when you then have ones that do?</div><div>=C2=A0</div><div><s= pan color=3D"#4472C4" style=3D"color:rgb(68,114,196)"><b>GV></b> What ab= out the following rewrite:</span></div><div><span color=3D"#4472C4" style= =3D"color:rgb(68,114,196)">=C2=A0</span></div><div><span color=3D"#4472C4" = style=3D"color:rgb(68,114,196)">Original:</span></div><div><span color=3D"#= 4472C4" style=3D"color:rgb(68,114,196)"> =C2=A0=C2=A0 The 'S-ID' fi= eld identifies a 4 bit Sequence ID field.=C2=A0 This field is</span></div><= div><span color=3D"#4472C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 us= ed to provide a flowspec client an indication how and where to</span></div>= <div><span color=3D"#4472C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 s= equence the received indirection-ids.=C2=A0 The Sequence ID value 0</span><= /div><div><span color=3D"#4472C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2= =A0 indicates that Sequence ID field is NOT set and SHOULD be ignored.=C2= =A0 A</span></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,114,19= 6)">=C2=A0=C2=A0 single flowspec rule MUST NOT have more as one indirection= -id per</span></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,114,= 196)">=C2=A0=C2=A0 S-ID.=C2=A0 On a flowspec client the indirection-id with= lowest S-ID MUST</span></div><div><span color=3D"#4472C4" style=3D"color:r= gb(68,114,196)">=C2=A0=C2=A0 be imposed first for any given flowspec entry.= </span></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,114,196)">= =C2=A0</span></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,114,1= 96)">New:</span></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,11= 4,196)">=C2=A0=C2=A0 The 'S-ID' field identifies a 4 bit Sequence I= D field.=C2=A0 This field is</span></div><div><span color=3D"#4472C4" style= =3D"color:rgb(68,114,196)">=C2=A0=C2=A0 used to provide a flowspec client a= n indication how and where to</span></div><div><span color=3D"#4472C4" styl= e=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 sequence the received indirection-= ids.=C2=A0 The Sequence ID value 0</span></div><div><span color=3D"#4472C4"= style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 indicates that Sequence ID fi= eld is NOT set and <b>**</b><b>all</b><b> other sequence ID's**</b> </s= pan></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,114,196)">=C2= =A0=C2=A0 SHOULD be ignored.=C2=A0 A</span></div><div><span color=3D"#4472C= 4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 single flowspec rule MUST N= OT have more as one indirection-id per</span></div><div><span color=3D"#447= 2C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 S-ID.=C2=A0 On a flowspec= client the indirection-id with lowest S-ID MUST</span></div><div><span col= or=3D"#4472C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 be imposed firs= t for any given flowspec entry.</span></div><div><span color=3D"#4472C4" st= yle=3D"color:rgb(68,114,196)">=C2=A0</span></div><div><span color=3D"#4472C= 4" style=3D"color:rgb(68,114,196)"><b>GV></b> In section *6. Validation = procedure" there is text to handle the error condition when the flowsp= ec rule results in an invalid redirection, that prescribe what needs to hap= pen when the =E2=80=9Credirect to indirection-id=E2=80=9D does not result i= n a valid redirection:</span></div><div><span color=3D"#4472C4" style=3D"co= lor:rgb(68,114,196)">=C2=A0</span></div><div><span color=3D"#4472C4" style= =3D"color:rgb(68,114,196)">"</span></div><div><span color=3D"#4472C4" = style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 While it MUST NOT happen, and = is seen as invalid combination, it is</span></div><div><span color=3D"#4472= C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 possible from a semantics = perspective to have multiple clashing</span></div><div><span color=3D"#4472= C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 redirect actions defined w= ithin a single flowspec rule.=C2=A0 For best and</span></div><div><span col= or=3D"#4472C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 consistant comp= atibility with legacy implementations, the redirect</span></div><div><span = color=3D"#4472C4" style=3D"color:rgb(68,114,196)"><b>=C2=A0=C2=A0 functiona= lity as documented by rfc5575bis MUST NOT be broken</b>, and</span></div><d= iv><span color=3D"#4472C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 hen= ce when a clash occurs, then <b>rfc5575bis based redirect MUST take</b></sp= an></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,114,196)"><b>= =C2=A0=C2=A0 priority</b>.=C2=A0 Additionally, if the "Redirect to ind= irection-id" does not</span></div><div><span color=3D"#4472C4" style= =3D"color:rgb(68,114,196)">=C2=A0=C2=A0 result in a valid redirection, then= the flowspec rule MUST be</span></div><div><span color=3D"#4472C4" style= =3D"color:rgb(68,114,196)">=C2=A0=C2=A0 processed as if the "Redirect = to indirection-id" community was not</span></div><div><span color=3D"#= 4472C4" style=3D"color:rgb(68,114,196)">=C2=A0=C2=A0 attached to the flowsp= ec route.</span></div><div><span color=3D"#4472C4" style=3D"color:rgb(68,11= 4,196)">"</span></div><div><span color=3D"#4472C4" style=3D"color:rgb(= 68,114,196)">=C2=A0</span></div><div><span color=3D"#4472C4" style=3D"color= :rgb(68,114,196)"><b>GV></b> Is there more to add to this? (We could add= a line to detail that =E2=80=9Credirect-to-ip=E2=80=9D is incompatible wit= h =E2=80=9Credirect to indirection-id=E2=80=9D and result in invalid redire= ction rule, however to me that is already implied with enough detail in the= text above)</span></div><div>=C2=A0</div><div>A few IANA issues:</div><div= >I see the type registry is currently registered with IANA (code point 0x09= ).=C2=A0 However, the sub-type registry is not established for some reason?= </div><div>The ID-Type field likely needs its own IANA registry.=C2=A0 Valu= es 1-5 are defined in this draft.</div><div>=C2=A0</div><div><span color=3D= "#4472C4" style=3D"color:rgb(68,114,196)"><b>GV></b> Correct. There is a= reason for this. When we asked IANA the code-points they informed me that = once the document get to RFC the sub-type registry will be established by I= ANA. </span></div><div>=C2=A0</div><div>The flags field (one octet) current= ly has 3 bits reserved.=C2=A0 In the past, we've not done a registry fo= r such cases (c.f. graceful restart) until we need to start carving out tho= se reserved bits for future extensions.=C2=A0 I leave it to the chairs'= opinion whether we want this a priori or not.</div><div>=C2=A0</div><div><= span color=3D"#4472C4" style=3D"color:rgb(68,114,196)"><b>G/</b></span></di= v><div>=C2=A0</div><div>=C2=A0</div><div>>=C2=A0</div><div>> Thank yo= u for considering this draft.</div><div>>=C2=A0</div><div>> Cheerily,= Susan Hares</div><div>>=C2=A0</div><div>> __________________________= _____________________</div><div>> Idr mailing list</div><div>> <a hre= f=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a></div><div>>= <a href=3D"https://www.ietf.org/mailman/listinfo/idr" target=3D"_blank">ht= tps://www..ietf.org/mailman/listinfo/idr</a></div><div>=C2=A0</div><div>___= ____________________________________________</div><div>Idr mailing list</di= v><div><a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a></= div><div><a href=3D"https://www.ietf.org/mailman/listinfo/idr" target=3D"_b= lank">https://www.ietf..org/mailman/listinfo/idr</a></div><div>=C2=A0</div>= </span></span></div>_______________________________________________<br> Idr= mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Idr@iet= f.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/idr" target= =3D"_blank">https://www.ietf.org/mailman/listinfo/idr</a><br></blockquote><= /div><div><span>_______________________________________________<br>Idr mail= ing list<br><a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]<= /a><br><a href=3D"https://www.ietf.org/mailman/listinfo/idr" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/idr</a><br></span></div></div></b= lockquote></div></div></blockquote></div> --00000000000097f6ff05987cab51-- --===============2691620477443095100== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Idr mailing list [email protected] https://www.ietf.org/mailman/listinfo/idr --===============2691620477443095100==--