[OPS-AREA]Re: [ippm] Re: foo-over-QUIC Operational Mot ivations & Challenges
"Lucas Pardue" <[email protected]> Sun, 05 Jul 2026 02:31:56 +0100
| Newsgroups | gmane.ietf.ops,gmane.ietf.opsawg,gmane.ietf.ippm |
|---|---|
| Message-ID | <[email protected]> |
--===============3292903000394378495== Content-Type: multipart/alternative; boundary=5f3d9ba6720f88895cd2e89ea76b9a718a61e420 --5f3d9ba6720f88895cd2e89ea76b9a718a61e420 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Benoit et al, On Fri, Jul 3, 2026, at 13:53, [email protected] wrote: > Dear all, >=20 > On that front of foo-over-QUIC Operational Motivations & Challenges, w= e have been posting this brand new draft >=20 > URL: https://www.ietf.org/archive/id/draft-netana-opsawg-telemetr= y-over-quic-00.txt > Status: https://datatracker.ietf.org/doc/draft-netana-opsawg-telemet= ry-over-quic/ > HTML: https://www.ietf.org/archive/id/draft-netana-opsawg-telemetr= y-over-quic-00.html > HTMLized: https://datatracker.ietf.org/doc/html/draft-netana-opsawg-te= lemetry-over-quic >=20 >=20 > QUIC Transport for Network Telemetry > draft-netana-opsawg-telemetry-over-quic-00 >=20 > Abstract >=20 > This document describes the use of the QUIC transport protocol as a > common transport substrate for operational Network Telemetry > protocols that currently rely on UDP. Specifically, it discusses > carrying protocols such as IPFIX, Syslog, YANG-Push UDP-Notif, and > RADIUS Accounting over QUIC connections. For telemetry protocols > whose data plane is inherently loss-tolerant (where a missing sample > is preferable to a delayed retransmission) this document recommends > use of the Unreliable Datagram Extension to QUIC (DATAGRAM frames). >=20 > A primary motivation for this work is the unification of transport- > layer security across heterogeneous telemetry protocols. Protocols > that currently have no mandatory transport security (syslog over UD= P) > or optional-only security (IPFIX over UDP with DTLS) or weak securi= ty > (RADIUS with MD5 obfuscation) would all benefit from the mandatory > TLS 1.3 mutual authentication that QUIC provides. This document > specifically addresses the operational advantages of managing a > single PKI certificate lifecycle per Network Node to authenticate a= ll > telemetry streams. >=20 > This document is intended as a framework and applicability statemen= t. > Per-protocol bindings that require normative specification are > expected to be chartered in their respective IETF working groups. >=20 > Regards, Benoit (on behalf of the authors) I'm not super familiar with the protocols described in this draft but it= seems to do a good job of describing the high level concerns, similarit= ies and rationale for unified substrate. The mapping to QUIC seems fairl= y sound. I wonder if RFC 9308 (Applicability of the QUIC Transport Protocol) [1] = was helpful in the authoring process? Not intended to be a trick questio= n, its just that it is one of the lesser-known but useful documents for = this type of thing. Some comments on the specific content: =E2=80=A2 The doc often refers to "STREAM frames" when the more usual w= ay to refer to the QUIC capability is simply "stream" or "QUIC stream". = The STREAM frames are often a low-level detail of the wire format, and o= f the implementations framing and packetization details. Application pro= tocols should concern themselves with the ordered byte stream and its li= fecycle - how a stream starts at offset 0, how data is sent to shift the= offset, how FIN or RESET_STREAM affects the final size etc. This become= s apparent in section 5.3 of draft-netana-opsawg-telemetry-over-quic-00:= the statement "A two-byte Telemetry Type field prepended to each QUIC f= rame payload identifies the encapsulated telemetry protocol. This header= applies to both DATAGRAM frames (unreliable telemetry data) and STREAM = frames" is ambiguous because it is unclear if the expectation is that ev= ery STREAM frame has to have these two bytes at the start (hard to achie= ve in practice, since framing is often hidden from apps). I suspect the = design is instead trying to say the first two bytes of the Stream need t= o be this field. =E2=80=A2 On the topic of Section 5.3, the fixed integer format could b= e optimized. QUIC uses variable-length integers widely. Your initial set= of telemetry type codepoints would all fit in the 1-byte encoding, whil= e allowing future extensibility. Is minimizing framing costs desirable t= o telemetry protocols? =E2=80=A2 The multiplicity goals of the substrate is not 100% clear to = me. It seems to allow for multiple types of telemetry. But Section 5.1 s= ays "The application layer MUST provide a demultiplexing header in the D= ATAGRAM payload to identify the protocol and stream identity (see Sectio= n 5.3 <https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry-ove= r-quic-00.html#datagram-format>)." - I'm left unsure if the telemetry ty= pe field is that or not =E2=80=A2 Furthermore, there seem to be quite stark differences betwe= en ALPN negotiating "telq" vs. the other specific options. Is it an erro= r to receive a DATAGRAM of Stream that is attempting to use a type that = would not be allowed by the negotiation? E.g. negotiate "sysq" and then = receive a message of IPFIX type. =E2=80=A2 The current design seems to be all or one - "telq" or speci= fic. A server cannot state a preference for subsets of protocols, meanin= g that you may end up with ALPN proliferation. An alternative design wou= ld be to push the negotiation inside the protocol. For example, a server= could advertise the set of telemetry types it is willing to support rec= eiving by sending that information over a "control stream" (see HTTP/3 [= 3]) =E2=80=A2 When using streams, the stream limits (concurrency count and = flow control) also play a role. Consider how your MUST or SHOULD require= ments for using streams for some types might place requirements on endpo= int to provide sufficient credit for the telemetry transfer to succeed. = This also has a relationship with the above point - the more protocols t= hat get multiplexed on a single substrate (something we tend to call poo= ling in WIT), the more potential there is for contention of the transpor= t resource. =E2=80=A2 When using streams, it is good practice to state when a clean= close is expected. I suspect that after sending a single type-specific = record you want to close the stream? Or does a single stream carry multi= ple? =E2=80=A2 Explicit connection close and stream aborts? Its common for e= ndpoints to want to explicitly close a connection or abort a stream. Bot= h of these are application protocol determined and need application-leve= l error codes. For example, consider a client that sends unexpected data= to a server and it wants to terminate the connection with an error code= to communicate the cause. =E2=80=A2 Graceful close? QUIC doesn't offer this itself but it is some= thing we recommend application protocols specify. A "control stream" wou= ld allow client or server to exchange a message that states an intent to= close prior to a CONNECTION_CLOSE or idle timeout. Cheers Lucas [1] https://www.rfc-editor.org/rfc/rfc9308.html [2] https://www.rfc-editor.org/info/rfc9000/#integer-encoding [3 https://datatracker.ietf.org/doc/html/rfc9114#name-control-streams [4] https://www.rfc-editor.org/rfc/rfc9308.html#name-connection-terminat= ion >=20 >=20 >=20 > On 02/04/2026 17:33, [email protected] wrote: >> Hi all >> =20 >> Many proposals (*) are being promoted in several IETF WGs to port pro= tocols widely used in operator networks to be transported over QUIC. The= re are several technical arguments that motivate such extensions, howeve= r, porting protocols used within operator networks to support QUIC would= have some impacts on fault isolation, troubleshooting, etc. Because of = the lack of the visibility on the transport headers, providing feature p= arity may be challenging without tools upgrade and also logistic (e.g., = synchronize keys to decode messages, etc.). >> =20 >> There is a need to (1) have a common understanding of the operational= benefits, (2) understand the underlying challenges that can be inherite= d especially when the connection endpoints are not adjacent to each othe= rs, and (3) identify deployment incentives especially when there are alt= ernate mechanisms to achieve similar objectives (TLS, etc.), (4) identif= y whether there are specific missing QUIC features that would ease use i= n operators network , and (5) explore whether there is common operationa= l guidance that can inform most of these extensions (and similar). >> =20 >> Per (cced) kindly accepted to coordinate and lead the discussion on t= his topic. Per will be presenting the outcome during IETF#126. Many than= ks Per! >> =20 >> This is thus a call for inputs and feedback on this topic. Feel free = to use this thread, get in touch with Per, or fill PRs/Issues using http= s://github.com/IETF-OPS-AD/foo-over-QUIC-Operational-Considerations. >> =20 >> Thank you >> =20 >> Cheers, >> Med >> =20 >> (*) >> =E2=80=A2 draft-ietf-netconf-over-quic <https://datatracker.ietf.org= /doc/draft-ietf-netconf-over-quic/>: NETCONF over QUIC >> =E2=80=A2 draft-liu-grow-bmp-over-quic <https://datatracker.ietf.org= /doc/draft-liu-grow-bmp-over-quic/>: Using BMP over QUIC connection >> =E2=80=A2 draft-liu-sidrops-rpki-rtr-over-quic <https://datatracker.= ietf.org/doc/draft-liu-sidrops-rpki-rtr-over-quic/>: RPKI to Router Prot= ocol over QUIC >> =E2=80=A2 draft-llg-opsawg-ipfix-over-quic <https://datatracker.ietf= .org/doc/draft-llg-opsawg-ipfix-over-quic/>: IPFIX Protocol over QUIC >> =E2=80=A2 draft-retana-idr-bgp-quic <https://datatracker.ietf.org/do= c/draft-retana-idr-bgp-quic/>: BGP over QUIC >> =E2=80=A2 draft-yl-radext-quic-transport <https://datatracker.ietf.o= rg/doc/draft-yl-radext-quic-transport/>: RADIUS over QUIC >> =E2=80=A2 draft-yang-pce-pcep-over-quic <https://datatracker.ietf.or= g/doc/draft-yang-pce-pcep-over-quic/>: PCEP over QUIC >> =E2=80=A2 draft-cel-nfsv4-rpc-over-quicv1 <https://datatracker.ietf.= org/doc/draft-cel-nfsv4-rpc-over-quicv1/>: Remote Procedure Call over QU= IC Version 1 >> =E2=80=A2 draft-ietf-regext-epp-quic <https://datatracker.ietf.org/d= oc/draft-ietf-regext-epp-quic/>: Extensible Provisioning Protocol (EPP) = Transport over QUIC >> =20 >> _____________________________________________________________________= _______________________________________ >> Ce message et ses pieces jointes peuvent contenir des informations co= nfidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous ave= z recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messa= ges electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, defor= me ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileg= ed 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 an= d 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. >>=20 >> _______________________________________________ >> ippm mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >=20 > _______________________________________________ > ippm mailing list -- [email protected] > To unsubscribe send an email to [email protected] >=20 --5f3d9ba6720f88895cd2e89ea76b9a718a61e420 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><head><title></title><style type=3D"text/css">#qt p= .qt-MsoNormal,#qt li.qt-MsoNormal,#qt div.qt-MsoNormal{margin-top:0cm;ma= rgin-right:0cm;margin-bottom:0cm;margin-left:0cm;font-size:11pt;font-fam= ily:"Aptos", sans-serif;}=0A#qt a:link,#qt span.qt-MsoHyperlink{color:rg= b(70, 120, 134);text-decoration-color:currentcolor;text-decoration-line:= underline;text-decoration-style:solid;text-decoration-thickness:auto;}=0A= #qt span.qt-EmailStyle17{font-family:"Courier New";color:windowtext;}=0A= #qt .qt-MsoChpDefault{font-size:11pt;}=0A#qt ul,#qt ol{margin-bottom:0cm= ;}=0A=0A</style></head><body><div>Hi Benoit et al,</div><div><br></div><= div>On Fri, Jul 3, 2026, at 13:53, <a href=3D"mailto:Benoit@everyth= ing-ops.net">[email protected]</a> wrote:</div><blockquote type=3D= "cite" id=3D"qt" style=3D""><div>Dear all,</div><div> <br></div><div> On= that front of foo-over-QUIC Operational Motivations &=0A Challen= ges, we have been posting this brand new draft</div><div><br></div><pre = class=3D"qt-moz-quote-pre">URL: <a class=3D"qt-moz-txt-link-freetex= t" href=3D"https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry= -over-quic-00.txt">https://www.ietf.org/archive/id/draft-netana-opsawg-t= elemetry-over-quic-00.txt</a>=0AStatus: <a class=3D"qt-moz-txt-link-fr= eetext" href=3D"https://datatracker.ietf.org/doc/draft-netana-opsawg-tel= emetry-over-quic/">https://datatracker.ietf.org/doc/draft-netana-opsawg-= telemetry-over-quic/</a>=0AHTML: <a class=3D"qt-moz-txt-link-freetex= t" href=3D"https://www.ietf.org/archive/id/draft-netana-opsawg-telemetry= -over-quic-00.html">https://www.ietf.org/archive/id/draft-netana-opsawg-= telemetry-over-quic-00.html</a>=0AHTMLized: <a class=3D"qt-moz-txt-link-= freetext" href=3D"https://datatracker.ietf.org/doc/html/draft-netana-ops= awg-telemetry-over-quic">https://datatracker.ietf.org/doc/html/draft-net= ana-opsawg-telemetry-over-quic=0A</a><br></pre><div><br></div><pre> = QUIC Transport for Network Telemetry=0A draft= -netana-opsawg-telemetry-over-quic-00=0A=0AAbstract=0A=0A This documen= t describes the use of the QUIC transport protocol as a=0A common tran= sport substrate for operational Network Telemetry=0A protocols that cu= rrently rely on UDP. Specifically, it discusses=0A carrying protocols= such as IPFIX, Syslog, YANG-Push UDP-Notif, and=0A RADIUS Accounting = over QUIC connections. For telemetry protocols=0A whose data plane is= inherently loss-tolerant (where a missing sample=0A is preferable to = a delayed retransmission) this document recommends=0A use of the Unrel= iable Datagram Extension to QUIC (DATAGRAM frames).=0A=0A A primary mo= tivation for this work is the unification of transport-=0A layer secur= ity across heterogeneous telemetry protocols. Protocols=0A that curre= ntly have no mandatory transport security (syslog over UDP)=0A or opti= onal-only security (IPFIX over UDP with DTLS) or weak security=0A (RAD= IUS with MD5 obfuscation) would all benefit from the mandatory=0A TLS = 1.3 mutual authentication that QUIC provides. This document=0A specif= ically addresses the operational advantages of managing a=0A single PK= I certificate lifecycle per Network Node to authenticate all=0A teleme= try streams.=0A=0A This document is intended as a framework and applic= ability statement.=0A Per-protocol bindings that require normative spe= cification are=0A expected to be chartered in their respective IETF wo= rking groups.=0A=0ARegards, Benoit (on behalf of the authors)</pre></blo= ckquote><div><br></div><div>I'm not super familiar with the protocols de= scribed in this draft but it seems to do a good job of describing the hi= gh level concerns, similarities and rationale for unified substrate. The= mapping to QUIC seems fairly sound.<br><br>I wonder if RFC 9308 (Applic= ability of the QUIC Transport Protocol) [1] was helpful in the authoring= process? Not intended to be a trick question, its just that it is one o= f the lesser-known but useful documents for this type of thing.</div><di= v><br></div><div>Some comments on the specific content:</div><div><br></= div><ul><li>The doc often refers to "STREAM frames" when the more usual = way to refer to the QUIC capability is simply "stream" or "QUIC stream".= The STREAM frames are often a low-level detail of the wire format, and = of the implementations framing and packetization details. Application pr= otocols should concern themselves with the ordered byte stream and its l= ifecycle - how a stream starts at offset 0, how data is sent to shift th= e offset, how FIN or RESET_STREAM affects the final size etc. This becom= es apparent in section 5.3 of draft-netana-opsawg-telemetry-over-qu= ic-00: the statement "A two-byte Telemetry Type field prepended to each = QUIC frame payload=0Aidentifies the encapsulated telemetry protocol. Th= is header applies=0Ato both DATAGRAM frames (unreliable telemetry data) = and STREAM frames" is ambiguous because it is unclear if the expectation= is that every STREAM frame has to have these two bytes at the start (ha= rd to achieve in practice, since framing is often hidden from apps). I s= uspect the design is instead trying to say the first two bytes of the St= ream need to be this field.<br></li><li>On the topic of Section 5.3, the= fixed integer format could be optimized. QUIC uses variable-length inte= gers widely. Your initial set of telemetry type codepoints would all fit= in the 1-byte encoding, while allowing future extensibility. Is minimiz= ing framing costs desirable to telemetry protocols?</li><li>The multipli= city goals of the substrate is not 100% clear to me. It seems to allow f= or multiple types of telemetry. But Section 5.1 says "The application la= yer MUST provide a=0Ademultiplexing header in the DATAGRAM payload to id= entify the protocol=0Aand stream identity (see <a href=3D"https://www.ie= tf.org/archive/id/draft-netana-opsawg-telemetry-over-quic-00.html#datagr= am-format">Section 5.3</a>)." - I'm left unsure if the telemetry type fi= eld is that or not</li><ul><li>Furthermore, there seem to be quite stark= differences between ALPN negotiating "telq" vs. the other specific opti= ons. Is it an error to receive a DATAGRAM of Stream that is attempting t= o use a type that would not be allowed by the negotiation? E.g. negotiat= e "sysq" and then receive a message of IPFIX type.</li><li>The current d= esign seems to be all or one - "telq" or specific. A server cannot state= a preference for subsets of protocols, meaning that you may end up with= ALPN proliferation. An alternative design would be to push the negotiat= ion inside the protocol. For example, a server could advertise the set o= f telemetry types it is willing to support receiving by sending that inf= ormation over a "control stream" (see HTTP/3 [3])</li></ul><li>When usin= g streams, the stream limits (concurrency count and flow control) also p= lay a role. Consider how your MUST or SHOULD requirements for using stre= ams for some types might place requirements on endpoint to provide suffi= cient credit for the telemetry transfer to succeed. This also has a rela= tionship with the above point - the more protocols that get multiplexed = on a single substrate (something we tend to call pooling in WIT), the mo= re potential there is for contention of the transport resource.</li><li>= When using streams, it is good practice to state when a clean close is e= xpected. I suspect that after sending a single type-specific record you = want to close the stream? Or does a single stream carry multiple?</li><l= i>Explicit connection close and stream aborts? Its common for endpoints = to want to explicitly close a connection or abort a stream. Both of thes= e are application protocol determined and need application-level error c= odes. For example, consider a client that sends unexpected data to a ser= ver and it wants to terminate the connection with an error code to commu= nicate the cause.</li><li>Graceful close? QUIC doesn't offer this itself= but it is something we recommend application protocols specify. A "cont= rol stream" would allow client or server to exchange a message that stat= es an intent to close prior to a CONNECTION_CLOSE or idle timeout.</li><= /ul><div>Cheers</div><div>Lucas</div><div><br></div><div>[1] <a hre= f=3D"https://www.rfc-editor.org/rfc/rfc9308.html">https://www.rfc-editor= .org/rfc/rfc9308.html</a></div><div>[2] <a href=3D"https://www.rfc-= editor.org/info/rfc9000/#integer-encoding">https://www.rfc-editor.org/in= fo/rfc9000/#integer-encoding</a></div><div>[3 <a href=3D"https://da= tatracker.ietf.org/doc/html/rfc9114#name-control-streams">https://datatr= acker.ietf.org/doc/html/rfc9114#name-control-streams</a></div><div>[4]&n= bsp;<a href=3D"https://www.rfc-editor.org/rfc/rfc9308.html#name-connecti= on-termination">https://www.rfc-editor.org/rfc/rfc9308.html#name-connect= ion-termination</a><br></div><blockquote type=3D"cite" id=3D"qt" style=3D= ""><pre><br></pre><div><br></div><div><br></div><div class=3D"qt-moz-cit= e-prefix">On 02/04/2026 17:33, <a class=3D"qt-moz-txt-link-abbreviated" = href=3D"mailto:[email protected]">[email protected]= m</a> wrote:</div><blockquote type=3D"cite" cite=3D"mid:PATP264MB6765059= [email protected]"><div clas= s=3D"qt-WordSection1"><p class=3D"qt-MsoNormal"><span class=3D"font" sty= le=3D"font-family:"Courier New";">Hi all</span></p><p class=3D= "qt-MsoNormal"><span class=3D"font" style=3D"font-family:"Courier N= ew";"> </span></p><p class=3D"qt-MsoNormal"><span class=3D"fon= t" style=3D"font-family:"Courier New";">Many proposals=0A = (*) are being promoted in several IETF WGs to port protocols=0A = widely used in operator networks to be transported over=0A = QUIC. There are several technical arguments that motivate=0A = such extensions, however, porting protocols used within=0A = operator networks to support QUIC would have some impacts on=0A = fault isolation, troubleshooting, etc. Because of the lack=0A = of the visibility on the transport headers, providing=0A = feature parity may be challenging without tools upgrade and=0A = also logistic (e.g., synchronize keys to decode messages,=0A = etc.).</span></p><p class=3D"qt-MsoNormal"><span class=3D"font" = style=3D"font-family:"Courier New";"> </span></p><p class= =3D"qt-MsoNormal"><span class=3D"font" style=3D"font-family:"Courie= r New";">There is a need=0A to (1) have a common underst= anding of the operational=0A benefits, (2) understand the und= erlying challenges that can=0A be inherited especially when t= he connection endpoints are=0A not adjacent to each others, a= nd (3) identify deployment=0A incentives especially when ther= e are alternate mechanisms to=0A achieve similar objectives (= TLS, etc.), (4) identify whether=0A there are specific missin= g QUIC features that would ease use=0A in operators network ,= and (5) explore whether there is=0A common operational guida= nce that can inform most of these=0A extensions (and similar)= .</span></p><p class=3D"qt-MsoNormal"><span class=3D"font" style=3D"font= -family:"Courier New";"> </span></p><p class=3D"qt-MsoNor= mal"><span class=3D"font" style=3D"font-family:"Courier New";"= >Per (cced)=0A kindly accepted to coordinate and lead the dis= cussion on=0A this topic. Per will be presenting the outcome = during=0A IETF#126. Many thanks Per!</span></p><p class=3D"qt= -MsoNormal"><span class=3D"font" style=3D"font-family:"Courier New&= quot;;"> </span></p><p class=3D"qt-MsoNormal"><span class=3D"font" = style=3D"font-family:"Courier New";">This is thus a=0A = call for inputs and feedback on this topic. Feel free to use=0A = this thread, get in touch with Per, or fill PRs/Issues using </sp= an><span class=3D"font" style=3D"font-family:"Courier New";"><= a href=3D"https://github.com/IETF-OPS-AD/foo-over-QUIC-Operational-Consi= derations"><span lang=3D"EN-US">https://github.com/IETF-OPS-AD/foo-over-= QUIC-Operational-Considerations</span></a></span><span class=3D"font" st= yle=3D"font-family:"Courier New";">.</span></p><p class=3D"qt-= MsoNormal"><span class=3D"font" style=3D"font-family:"Courier New&q= uot;;"> </span></p><p class=3D"qt-MsoNormal"><span class=3D"font" s= tyle=3D"font-family:"Courier New";">Thank you</span></p><p cla= ss=3D"qt-MsoNormal"><span class=3D"font" style=3D"font-family:"Cour= ier New";"> </span></p><p class=3D"qt-MsoNormal"><span class=3D= "font" style=3D"font-family:"Courier New";">Cheers,</span></p>= <p class=3D"qt-MsoNormal"><span class=3D"font" style=3D"font-family:&quo= t;Courier New";">Med</span></p><p class=3D"qt-MsoNormal"><span clas= s=3D"font" style=3D"font-family:"Courier New";"> </span><= /p><p class=3D"qt-MsoNormal"><span class=3D"font" style=3D"font-family:&= quot;Courier New";">(*)</span></p><ul style=3D"margin-top:0cm;" typ= e=3D"disc"><li class=3D"qt-MsoNormal" style=3D""><span class=3D"font" st= yle=3D"font-family:"Courier New";"><a href=3D"https://datatrac= ker.ietf.org/doc/draft-ietf-netconf-over-quic/"><span lang=3D"EN-US">dra= ft-ietf-netconf-over-quic</span></a></span><span class=3D"font" style=3D= "font-family:"Courier New";">:=0A NETCONF over QU= IC</span></li><li class=3D"qt-MsoNormal" style=3D""><span class=3D"font"= style=3D"font-family:"Courier New";"><a href=3D"https://datat= racker.ietf.org/doc/draft-liu-grow-bmp-over-quic/"><span lang=3D"EN-US">= draft-liu-grow-bmp-over-quic</span></a></span><span class=3D"font" style= =3D"font-family:"Courier New";">:=0A Using BMP ov= er QUIC connection</span></li><li class=3D"qt-MsoNormal" style=3D""><spa= n class=3D"font" style=3D"font-family:"Courier New";"><a href=3D= "https://datatracker.ietf.org/doc/draft-liu-sidrops-rpki-rtr-over-quic/"= ><span lang=3D"EN-US">draft-liu-sidrops-rpki-rtr-over-quic</span></a></s= pan><span class=3D"font" style=3D"font-family:"Courier New";">:= =0A RPKI to Router Protocol over QUIC</span></li><li class=3D= "qt-MsoNormal" style=3D""><span class=3D"font" style=3D"font-family:&quo= t;Courier New";"><a href=3D"https://datatracker.ietf.org/doc/draft-= llg-opsawg-ipfix-over-quic/"><span lang=3D"EN-US">draft-llg-opsawg-ipfix= -over-quic</span></a></span><span class=3D"font" style=3D"font-family:&q= uot;Courier New";">:=0A IPFIX Protocol over QUIC</span= ></li><li class=3D"qt-MsoNormal" style=3D""><span class=3D"font" style=3D= "font-family:"Courier New";"><a href=3D"https://datatracker.ie= tf.org/doc/draft-retana-idr-bgp-quic/"><span lang=3D"EN-US">draft-retana= -idr-bgp-quic</span></a></span><span class=3D"font" style=3D"font-family= :"Courier New";">:=0A BGP over QUIC</span></li><l= i class=3D"qt-MsoNormal" style=3D""><span class=3D"font" style=3D"font-f= amily:"Courier New";"><a href=3D"https://datatracker.ietf.org/= doc/draft-yl-radext-quic-transport/"><span lang=3D"EN-US">draft-yl-radex= t-quic-transport</span></a></span><span class=3D"font" style=3D"font-fam= ily:"Courier New";">:=0A RADIUS over QUIC</span><= /li><li class=3D"qt-MsoNormal" style=3D""><span class=3D"font" style=3D"= font-family:"Courier New";"><a href=3D"https://datatracker.iet= f.org/doc/draft-yang-pce-pcep-over-quic/"><span lang=3D"EN-US">draft-yan= g-pce-pcep-over-quic</span></a></span><span class=3D"font" style=3D"font= -family:"Courier New";">:=0A PCEP over QUIC</span= ></li><li class=3D"qt-MsoNormal" style=3D""><span class=3D"font" style=3D= "font-family:"Courier New";"><a href=3D"https://datatracker.ie= tf.org/doc/draft-cel-nfsv4-rpc-over-quicv1/"><span lang=3D"EN-US">draft-= cel-nfsv4-rpc-over-quicv1</span></a></span><span class=3D"font" style=3D= "font-family:"Courier New";">:=0A Remote Procedur= e Call over QUIC Version 1</span></li><li class=3D"qt-MsoNormal" style=3D= ""><span class=3D"font" style=3D"font-family:"Courier New";"><= a href=3D"https://datatracker.ietf.org/doc/draft-ietf-regext-epp-quic/">= <span lang=3D"EN-US">draft-ietf-regext-epp-quic</span></a></span><span c= lass=3D"font" style=3D"font-family:"Courier New";">:=0A = Extensible Provisioning Protocol (EPP) Transport over QUIC</span>= </li></ul><p class=3D"qt-MsoNormal"><span class=3D"font" style=3D"font-f= amily:"Courier New";"> </span></p></div><pre>____________= _____<wbr>______________________________<wbr>___________________________= ___<wbr>______________________________<wbr>_=0ACe message et ses pieces = jointes peuvent contenir des informations confidentielles ou privilegiee= s et ne doivent donc=0Apas etre diffuses, exploites ou copies sans autor= isation. Si vous avez recu ce message par erreur, veuillez le signaler=0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages= electroniques etant susceptibles d'alteration,=0AOrange decline toute r= esponsabilite si ce message a ete altere, deforme ou falsifie. Merci.=0A= =0AThis message and its attachments may contain confidential or privileg= ed information that may be protected by law;=0Athey should not be distri= buted, used or copied without authorisation.=0AIf you have received this= email in error, please notify the sender and delete this message and it= s attachments.=0AAs emails may be altered, Orange is not liable for mess= ages that have been modified, changed or falsified.=0AThank you.</pre><d= iv><br></div><pre class=3D"qt-moz-quote-pre">___________________________= ____________________=0Aippm mailing list -- <a class=3D"qt-moz-txt-link-= abbreviated" href=3D"mailto:[email protected]">[email protected]</a>=0ATo unsubs= cribe send an email to <a class=3D"qt-moz-txt-link-abbreviated" href=3D"= mailto:[email protected]">[email protected]</a>=0A</pre></blockquote= ><div><br></div><div>_______________________________________________</di= v><div>ippm mailing list -- <a href=3D"mailto:[email protected]">ippm@i= etf.org</a></div><div>To unsubscribe send an email to <a href=3D"ma= ilto:[email protected]">[email protected]</a></div><div><br></div></= blockquote><div><br></div></body></html> --5f3d9ba6720f88895cd2e89ea76b9a718a61e420-- --===============3292903000394378495== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KT1BTLUFSRUEg bWFpbGluZyBsaXN0IC0tIG9wcy1hcmVhQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4g ZW1haWwgdG8gb3BzLWFyZWEtbGVhdmVAaWV0Zi5vcmcK --===============3292903000394378495==--