Subject: [CDNi] TR: New Version Notification for draft-fieau-cdni-interfaces-https-delegation-01.txt

From: <[email-masked]>
Date: Mon, 3 Jul 2017 17:31:33 +0000

Hi,

Just posted a proposal to update metadata Interface to support HTTPS delegation in CDNI.

https://tools.ietf.org/html/draft-fieau-cdni-interfaces-https-delegation-01

Abstract:
   The delivery of content over HTTPS involving multiple CDNs raises
   credential management issues.  This document recalls the methods
   under study at the IETF.  Then it specifies the updates needed in
   CDNI Control and Metadata interfaces to setup HTTPS delegation
   between an uCDN and dCDN.

Frédéric

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : lundi 3 juillet 2017 19:27
À : Sanjay Mishra; STEPHAN Emile IMT/OLN; STEPHAN Emile IMT/OLN; FIEAU Frédéric IMT/OLN
Objet : New Version Notification for draft-fieau-cdni-interfaces-https-delegation-01.txt

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

Name:		draft-fieau-cdni-interfaces-https-delegation
Revision:	01
Title:		CDNI interfaces update for HTTPS delegation
Document date:	2017-07-03
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-fieau-cdni-interfaces-https-delegation-01.txt
Status:         https://datatracker.ietf.org/doc/draft-fieau-cdni-interfaces-https-delegation/
Htmlized:       https://tools.ietf.org/html/draft-fieau-cdni-interfaces-https-delegation-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fieau-cdni-interfaces-https-delegation-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fieau-cdni-interfaces-https-delegation-01

Abstract:
   The delivery of content over HTTPS involving multiple CDNs raises
   credential management issues.  This document recalls the methods
   under study at the IETF.  Then it specifies the updates needed in
   CDNI Control and Metadata interfaces to setup HTTPS delegation
   between an uCDN and dCDN.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_________________________________________________________________________________________________________________________

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.

---

From: Kevin Ma J <[email-masked]>
Date: Mon, 3 Jul 2017 18:10:30 +0000

Hi Frederic,

  (as an individual) I had a quick read through the updated draft.  I'm not sure why you need the SecuredDelegation object?  I would expect the delegateddomain to just be an actual HostMatch object, against which the client request would be matched, in order to find the relevant PathMatch hierarchy.  I would further expect the SecuredDelegation object to just be part of the PathMetadata associated with an already existing PathMatch (found via the HostMatch, and containing the pathpattern), and that the timewindow would just be a TimeWindowACL generic metadata object in the same PathMetadata list/hierarchy as the SecuredDelegation object?  That would leave only the delegationmethod property of SecuredDelegation object; but I don't see a point in having the SecuredDelegation object, just to say that another generic metadata object exists (e.g., AcmeStarDelegationMethod).

  I have not read the ACME STAR draft, but assuming the AcmeStarDelegationMethod object has all the necessary information, the AcmeStarDelegationMethod object might be a useful extension to CDNI.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, July 03, 2017 1:32 PM
> To: [email-masked]
> Subject: [CDNi] TR: New Version Notification for draft-fieau-cdni-
> interfaces-https-delegation-01.txt
> 
> Hi,
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> __________________________________________________________________________
> _______________________________________________
> 
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni