Subject: [CDNi] Working Group Last Call on draft-ietf-cdni-uri-signing (take 2)

From: Kevin Ma <[email-masked]>
Date: Wed, 24 Jul 2019 01:46:10 -0400

Hi All,

  Today will begin the two-week WGLC on:
https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-18

  Please send any comments, questions, or concerns to the CDNI mailing
list: [email-masked]

 The WGLC will end on Wednesday August 7, 2019, at which time,
assuming there are no objections, we will submit the draft to the IESG

thanx!

--  Kevin, Phil, and Francois

---

From: Jan Seedorf <[email-masked]>
Date: Thu, 25 Jul 2019 22:22:13 +0200

Dear CDNI folks,

some time ago it was agreed (in the CDNI WG) that the transport of CDNI 
FCI objects defined in RFC8008/8006 will be done via a new ALTO service. 
The corresponding work was thus transferred to the ALTO WG. We are now 
finalizing this document and would like to have CDNI experts to have a look:

https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-06

The FCI JSON objects and their semantics from RFC8008/8006 have not 
changed; the draft cited above defines a new ALTO service to transport 
such objects.

We plan to issue a WGLC on this document soon, so please have a look and 
let us know any comments you might have. We would also appreciate if 
during the upcoming  2-week WGLC we could have one individual reviewer 
from the CDNI WG (Kevin?).

Let us (the authors and the ALTO WG) know if you have any questions or 
comments.

  - Jan

-- 
****************************
Prof. Dr. Jan Seedorf
Chief Information Security Officer (CISO)
[email-masked]

Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de
****************************

---

From: Chris Lemmons <[email-masked]>
Date: Fri, 26 Jul 2019 14:23:21 -0400

So I was reviewing all the extension points. I noticed that although
the s-uri-signing logging field is added to the IANA registry, the
field itself is defined by a list of numbers that are themselves part
of no registry. Since there's a one-to-one mapping between all failure
types and a logging code, any extension claims cannot record an
associated code. This will cause implementations to try to pick a
"related" or "generic" logging code for validations that fail on
account of a supported extension. (Unsupported extensions, of course,
would record 409.) Is there a reasonable way to provide a registry for
these codes?

As an editorial note, the header provided in the example for cdni
metadata is not valid: "jwt-header": "1234abcd". That 1234abcd should
probably be a valid jwt header instead.

On Wed, Jul 24, 2019 at 1:46 AM Kevin Ma <[email-masked]> wrote:
>
> Hi All,
>
>   Today will begin the two-week WGLC on: https://tools.ietf.org/html/draft-ietf-cdni-uri-signing-18
>
>   Please send any comments, questions, or concerns to the CDNI mailing list: [email-masked]
>
>  The WGLC will end on Wednesday August 7, 2019, at which time, assuming there are no objections, we will submit the draft to the IESG
>
> thanx!
>
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni