Subject: Re: [CDNi] FW: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt

From: Kevin Ma <[email-masked]>
Date: Fri, 11 Feb 2022 01:04:01 -0500

Hi Christoph,

  (As Chair) I think it is fair to call for adoption of the draft, since it
was just a split, though I think it would be good to reaffirm that the WG
has an appetite for this work, since it has been a while since we agreed to
adopt the original draft.  If folks could please confirm on the list that
they believe TLS subcerts are still useful to support in CDNI, that would
be great.

  (As an Individual) The actual requirements to support TLS subcerts seem
pretty minimal (see my comments on the draft below).  Assuming the TLS
subcerts draft is on track to be published (I see that the AD recently
requested a revision), I am in favor of adopting the draft.

thanx!

--  Kevin J. Ma

comments:
---------

- does "MI.DelegatedCredentials" need to be defined in this draft?  It is
not transferred via the MI?  is "MI.ConfDelegatedCredentials" sufficient
for CDNI's purposes?
- in the call flows, it looks like only steps 3 and 4 for
"MI.ConfDelegatedCredentials"
are related to CDNI?  perhaps we could make that even more clear, so that
there aren't a lot of questions about the security of what's being proposed?
- the draft needs security and privacy sections (the security section gets
easier if we are clear that the draft only really defines the "
MI.ConfDelegatedCredentials" object which is a simple link and subcerts
does all the heavy security lifting; the privacy section gets easier if we
remove MI.DelegatedCredentials and let the subvert draft deal with passing
around a "private key")

On Wed, Jan 26, 2022 at 11:33 AM Christoph Neumann <
[email-masked]> wrote:

> Dear all,
>
> I submitted a new version of the draft on CDNI Metadata for Delegated
> Credentials (see below).
>
> As discussed and agreed in the CDNi working group, this draft resulted
> from splitting the original CDNi extensions for HTTPS delegation draft
> (draft-ietf-cdni-interfaces-https-delegation) into two:
> - one that handles STAR/ACME type delegation, which remained in
> draft-ietf-cdni-interfaces-https-delegation
> - one that handles delegated credentials, described in
> draft-fieau-interfaces-https-delegation-subcerts
>
> The delegated credentials draft is currently handled as an individual
> submission, and I would like to ask for adoption of this draft in the CDNi
> working group.
>
> Further, feel free to comment the draft on the mailing list.
>
> Best regards,
> Christoph
>
> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: mercredi 26 janvier 2022 17:00
> To: Christoph Neumann <[email-masked]>; Emile Stephan <
> [email-masked]>; Frederic Fieau <[email-masked]>;
> Guillaume Bichot <[email-masked]>; Stephan Emile <
> [email-masked]>
> Subject: New Version Notification for
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
>
>
> A new version of I-D,
> draft-fieau-interfaces-https-delegation-subcerts-01.txt
> has been successfully submitted by Christoph Neumann and posted to the
> IETF repository.
>
> Name:           draft-fieau-interfaces-https-delegation-subcerts
> Revision:       01
> Title:          CDNI Metadata for Delegated Credentials
> Document date:  2022-01-26
> Group:          Individual Submission
> Pages:          9
> URL:
> https://www.ietf.org/archive/id/draft-fieau-interfaces-https-delegation-subcerts-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-fieau-interfaces-https-delegation-subcerts/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-fieau-interfaces-https-delegation-subcerts
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-fieau-interfaces-https-delegation-subcerts-01
>
> Abstract:
>    The delivery of content over HTTPS involving multiple CDNs raises
>    credential management issues.  This document defines metadata in CDNI
>    Control and Metadata interface to setup HTTPS delegation using
>    Delegated Credentials from an Upstream CDN (uCDN) to a Downstream CDN
>    (dCDN).
>
>
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
>

---

From: Christoph Neumann <[email-masked]>
Date: Tue, 15 Feb 2022 17:12:52 +0000

Hi Kevin,

Thanks for your comments.

MI.DelegatedCredentials may or may not be part of the Metadata Interface (MI) described in RFC8006 (In theory, it should not part of it, I agree with you here, at least as it is in the current proposal) but it should be somehow part of CDNi .

The way to retrieve MI.DelegatedCredentials as defined in the proposal is a bit particular. As only the dCDN knows how many delegated credentials (MI.DelegatedCredentials) it needs , it must fetch/request as many MI.DelegatedCredentials as required. On the other side, the uCDN may decide to respond with different or identical MI.DelegatedCredentials payloads.  I also note that there is an error in the current text which can be a bit confusing: page 4: second paragraph, we should read:

"The MI.ConfDelegatedCredentials contains a URI (credentials-location-uri) that allows the dCDN to download delegated credentials. The expected behavior of this URI is that each time that the dCDN accesses this URI a MI.DelegatedCredentials object containing a delegated credential with its corresponding private key is delivered."

I reckon this workflow is not typical to RFC8006 which would favor a separate/new interface for describing that process. This drives to the possibility of only adding MI.ConfDelegatedCredentials to MI (RFC8006) . However, if we cannot describe the protocol to fetch the MI.DelegatedCredentials object and its payload structure (i.e. private key +  DelegatedCredential as defined in [I-D.ietf-tls-subcerts]) as part of CDNi, the MI.ConfDelegatedCredentials becomes pointless. Ideally, we should generate a new CDNi interface dedicated to subcert describing the MI.DelegatedCredentials payload and the protocol between the uCDN and dCDN.

There is however a possible complementary solution to this. The dCDN may advertise about supporting the subcert capability through a dedicated new FCI object named e.g., FCI.delegatedCredentials. The latter would indicate the number of required [different] delegated credential objects. The uCDN when configuring the dCDN would then use an MI object (we can name it MI.ConfDelegatedCredentials) to communicate the delegated credentials (i.e. private key +  DelegatedCredential) via an array of MI objects. I.e, MI.ConfDelegatedCredentials would be defines as:
Property: array of MI.DelegatedCredentials objects.

The MI.ConfDelegatedCredentials object would have to be updated/communicated by the uCDN each time any or all of the delegated credential's validity is going to expired and/or each time a new FCI.delegatedCredentials object is updated/created.  With that way to do we stay compatible with the RFC 8006 spirit, do not need an extra CDNi interface and provides a complete/coherent mechanism for configuring the dCDN with the delegated credentials.

Any thoughts on this latter proposal?

Christoph

From: Kevin Ma <[email-masked]>
Sent: vendredi 11 février 2022 07:04
To: Christoph Neumann <[email-masked]>
Cc: [email-masked]
Subject: Re: [CDNi] FW: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt

Hi Christoph,

  (As Chair) I think it is fair to call for adoption of the draft, since it was just a split, though I think it would be good to reaffirm that the WG has an appetite for this work, since it has been a while since we agreed to adopt the original draft.  If folks could please confirm on the list that they believe TLS subcerts are still useful to support in CDNI, that would be great.

  (As an Individual) The actual requirements to support TLS subcerts seem pretty minimal (see my comments on the draft below).  Assuming the TLS subcerts draft is on track to be published (I see that the AD recently requested a revision), I am in favor of adopting the draft.

thanx!

--  Kevin J. Ma

comments:
---------

- does "MI.DelegatedCredentials" need to be defined in this draft?  It is not transferred via the MI?  is "MI.ConfDelegatedCredentials" sufficient for CDNI's purposes?
- in the call flows, it looks like only steps 3 and 4 for "MI.ConfDelegatedCredentials" are related to CDNI?  perhaps we could make that even more clear, so that there aren't a lot of questions about the security of what's being proposed?
- the draft needs security and privacy sections (the security section gets easier if we are clear that the draft only really defines the "MI.ConfDelegatedCredentials" object which is a simple link and subcerts does all the heavy security lifting; the privacy section gets easier if we remove MI.DelegatedCredentials and let the subvert draft deal with passing around a "private key")

On Wed, Jan 26, 2022 at 11:33 AM Christoph Neumann <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,

I submitted a new version of the draft on CDNI Metadata for Delegated Credentials (see below).

As discussed and agreed in the CDNi working group, this draft resulted from splitting the original CDNi extensions for HTTPS delegation draft (draft-ietf-cdni-interfaces-https-delegation) into two:
- one that handles STAR/ACME type delegation, which remained in draft-ietf-cdni-interfaces-https-delegation
- one that handles delegated credentials, described in draft-fieau-interfaces-https-delegation-subcerts

The delegated credentials draft is currently handled as an individual submission, and I would like to ask for adoption of this draft in the CDNi working group.

Best regards,
Christoph

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Sent: mercredi 26 janvier 2022 17:00
To: Christoph Neumann <[email-masked]<mailto:[email-masked]>>; Emile Stephan <[email-masked]<mailto:[email-masked]>>; Frederic Fieau <[email-masked]<mailto:[email-masked]>>; Guillaume Bichot <[email-masked]<mailto:[email-masked]>>; Stephan Emile <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-fieau-interfaces-https-delegation-subcerts-01.txt

A new version of I-D, draft-fieau-interfaces-https-delegation-subcerts-01.txt
has been successfully submitted by Christoph Neumann and posted to the IETF repository.

Name:           draft-fieau-interfaces-https-delegation-subcerts
Revision:       01
Title:          CDNI Metadata for Delegated Credentials
Document date:  2022-01-26
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/archive/id/draft-fieau-interfaces-https-delegation-subcerts-01.txt<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-fieau-interfaces-https-delegation-subcerts-01.txt&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=QFaHDtkpfYfrjAYDDoIXmSdxmjt04eywDjttAdk4FLo%3D&reserved=0>
Status:            https://datatracker.ietf.org/doc/draft-fieau-interfaces-https-delegation-subcerts/<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-fieau-interfaces-https-delegation-subcerts%2F&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=%2FPtgxFHH9o8Ze%2FwpdzoY%2FMRfUKqGhnA%2FcKNEmp7a5%2F4%3D&reserved=0>
Htmlized:            https://datatracker.ietf.org/doc/html/draft-fieau-interfaces-https-delegation-subcerts<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-fieau-interfaces-https-delegation-subcerts&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Wn1%2B4HCdvDzpfYTK3ZEyXnS3Rwi%2BKn6hvusuA02hkqA%3D&reserved=0>
Diff:            https://www.ietf.org/rfcdiff?url2=draft-fieau-interfaces-https-delegation-subcerts-01<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-fieau-interfaces-https-delegation-subcerts-01&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=cG1nvUUcogl7El1rhkA14b1Lltcca%2FpDazw8JTSj6PA%3D&reserved=0>

Abstract:

The IETF Secretariat

_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcdni&data=04%7C01%7CChristoph.Neumann%40broadpeak.tv%7C31b30e046460458449b208d9ed24543b%7C0ebe44eac9c9438da0407e699f358ed4%7C0%7C0%7C637801562557792088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=b1aEa%2FVaj%2Fkyzf8zUJGCX8cUwfWKezIdQLWHA41uMlE%3D&reserved=0>

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Wed, 23 Feb 2022 22:43:28 -0500

Hi Christoph - Thank you for submitting the updated draft. Speaking as an
individual, I do support this work and in favor of adopting this draft (and
assuming subcert draft -
https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ - will progress
to an RFC)

The complimentary suggestion you outlined below might be workable from what
I see, that is,  dCDN advertise  MI.DelegatedCredentials through a
dedicated new FCI object named e.g., FCI.delegatedCredentials and the uCDN
when configuring the dCDN would then use an MI object (we can name it
MI.ConfDelegatedCredentials) to communicate the delegated credentials.

I do have some minor nits in the document:

sec 2.1: discribeq -> describes
sec 3: you can update reference to ACME drafts to RFC, namely RFC 8739 and
RFC 9115, specifically in the text
" There are currently Internet drafts within the TLS and ACME working
groups..."
sec 4: " With FCI the dCDN" -> "with FCI, the dCDN"

Thanks
Sanjay

On Tue, Feb 15, 2022 at 12:13 PM Christoph Neumann <
[email-masked]> wrote:

> MI.DelegatedCredentials may or may not be part of the Metadata Interface
> (MI) described in RFC8006 (In theory, it should not part of it, I agree
> with you here, at least as it is in the current proposal) but it should be
> somehow part of CDNi .
>
>
>
> The way to retrieve MI.DelegatedCredentials as defined in the proposal is
> a bit particular. As only the dCDN knows how many delegated credentials
> (MI.DelegatedCredentials) it needs , it must fetch/request as many
> MI.DelegatedCredentials as required. On the other side, the uCDN may decide
> to respond with different or identical MI.DelegatedCredentials payloads.  I
> also note that there is an error in the current text which can be a bit
> confusing: page 4: second paragraph, we should read:
>
>
>
> “The MI.ConfDelegatedCredentials contains a URI (credentials-location-uri)
> that allows the dCDN to download delegated credentials. The expected
> behavior of this URI is that each time that the dCDN accesses this URI a
> *MI.DelegatedCredentials* object containing a delegated credential with
> its corresponding private key is delivered.”
>
>
>
> I reckon this workflow is not typical to RFC8006 which would favor a
> separate/new interface for describing that process. This drives to the
> possibility of only adding MI.ConfDelegatedCredentials to MI (RFC8006) .
> However, if we cannot describe the protocol to fetch the
> MI.DelegatedCredentials object and its payload structure (i.e. private key
> +  DelegatedCredential as defined in [I-D.ietf-tls-subcerts]) as part of
> CDNi, the MI.ConfDelegatedCredentials becomes pointless. Ideally, we should
> generate a new CDNi interface dedicated to subcert describing the
> MI.DelegatedCredentials payload and the protocol between the uCDN and dCDN.
>
>
>
> There is however a possible complementary solution to this. The dCDN may
> advertise about supporting the subcert capability through a dedicated new
> FCI object named e.g., FCI.delegatedCredentials. The latter would indicate
> the number of required [different] delegated credential objects. The uCDN
> when configuring the dCDN would then use an MI object (we can name it
> MI.ConfDelegatedCredentials) to communicate the delegated credentials (i.e.
> private key +  DelegatedCredential) via an array of MI objects. I.e,
> MI.ConfDelegatedCredentials would be defines as:
>
> The MI.ConfDelegatedCredentials object would have to be
> updated/communicated by the uCDN each time any or all of the delegated
> credential’s validity is going to expired and/or each time a new
> FCI.delegatedCredentials object is updated/created.  With that way to do we
> stay compatible with the RFC 8006 spirit, do not need an extra CDNi
> interface and provides a complete/coherent mechanism for configuring the
> dCDN with the delegated credentials.
>
>
>
> *From:* Kevin Ma <[email-masked]>
> *Sent:* vendredi 11 février 2022 07:04
> *To:* Christoph Neumann <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [CDNi] FW: New Version Notification for
>   (As Chair) I think it is fair to call for adoption of the draft, since
> it was just a split, though I think it would be good to reaffirm that the
> WG has an appetite for this work, since it has been a while since we agreed
> to adopt the original draft.  If folks could please confirm on the list
> that they believe TLS subcerts are still useful to support in CDNI, that
> would be great.
>
>
>
> - in the call flows, it looks like only steps 3 and 4
> for "MI.ConfDelegatedCredentials" are related to CDNI?  perhaps we could
> make that even more clear, so that there aren't a lot of questions about
> the security of what's being proposed?
>
> easier if we are clear that the draft only really defines
> the "MI.ConfDelegatedCredentials" object which is a simple link and
> subcerts does all the heavy security lifting; the privacy section gets
> easier if we remove MI.DelegatedCredentials and let the subvert draft deal
> with passing around a "private key")
>
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Farchive-252Fid-252Fdraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-2D01.txt-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DQFaHDtkpfYfrjAYDDoIXmSdxmjt04eywDjttAdk4FLo-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=s3f77k5Em7VVOqCwNr8SRn6X03iC9nzC8lDsgEujKQ4&e=>
> Status:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fdraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-252F-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D-252FPtgxFHH9o8Ze-252FwpdzoY-252FMRfUKqGhnA-252FcKNEmp7a5-252F4-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=g1N8j2Rc3vHnqvRqPH0IAVdFwM8twr_KCwzIhN1s9qs&e=>
> Htmlized:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fhtml-252Fdraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DWn1-252B4HCdvDzpfYTK3ZEyXnS3Rwi-252BKn6hvusuA02hkqA-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=BsUD_gxsSYpcNVymSV9RKdwwHoB5Cdda0odiSfOf-K4&e=>
> Diff:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Frfcdiff-253Furl2-253Ddraft-2Dfieau-2Dinterfaces-2Dhttps-2Ddelegation-2Dsubcerts-2D01-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DcG1nvUUcogl7El1rhkA14b1Lltcca-252FpDazw8JTSj6PA-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=_h7Jzulev3K3_KSLtGrsLxdKZlZOwbIt0pkisosIldY&e=>
>
> Abstract:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__fra01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.ietf.org-252Fmailman-252Flistinfo-252Fcdni-26data-3D04-257C01-257CChristoph.Neumann-2540broadpeak.tv-257C31b30e046460458449b208d9ed24543b-257C0ebe44eac9c9438da0407e699f358ed4-257C0-257C0-257C637801562557792088-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3Db1aEa-252FVaj-252Fkyzf8zUJGCX8cUwfWKezIdQLWHA41uMlE-253D-26reserved-3D0&d=DwMFAw&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=6f-Vb6IwmHwLh63CJhtn2plNPPirspfcJO7akno7p70&e=>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_cdni&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=XniVbishGiO2Ao9hKqSc-hTVIWCi3T-x6GdHR4ZTgoM&m=QjjUn69il_VLl2_ZtkdTjiIbmyAzWXLQRqnJxCj0t0wC_wR6DWLnpOfaE8JHmcRv&s=r5k5X_b-klPZtRJY_mFktNZ1ofc8eLRXweTh-GMMyBI&e=
>