Minutes for CDNI at IETF-93
minutes-93-cdni-1

CDNI Working Group Minutes

IETF-93, Prague, Czech Republic
- Chaired by Francois Le Faucheur and Daryl Malas
- Meeting notes captured by Kevin and Rich Salz, edited by Francois Le Faucheur
- Audio Recording at:
https://www.ietf.org/audio/ietf93/ietf93-karlini_ii-20150720-1300.mp3 - Slides
accessible at: http://www.ietf.org/proceedings/93/cdni.html

Monday, July 20, 2015, 13:00-15:00, Karlin I/II
===================================================
- about 60 people in the room, plus 5 on MeetEcho

Introduction and Agenda (WG chairs)
---------------------------------------------------------------
- Introduction by the WG chairs, and Note Well statement.
- Barry Leiba (AD): The “Note Well” statement applies to participation (any
form of participation), but does not apply if just sitting - Agenda review, no
request to change agenda - No New Published RFCs (since previous IETF meeting)
- Document Update and progress against the charter milestones

        * cdni-logging: in “IESG Review.” Received comments, most addressed,
        the one significant remaining open item is Privacy. * cdni-metadata:
        Ready for WG Last Call, once the MIME type discussion is resolved and
        JSON expert review comments are addressed. * cdni-redirection: Security
        text aligned, Privacy discussion added. Ready to move to IESG review ?
        * cdni-control-triggers: JSON expert review comments addressed,
        security text aligned, privacy text added. Ready for IESG review ? *
        cdni-footprint-capabilities-semantics: Semantics I-D ready for WG Last
        Call once MIME Type discussion is resolved. * cdni-uri-signing: WG made
        a decision in Dallas to include support for segmented content in same
        I-D. Liaison was sent to MPEG to notify them of that decision (and
        respond to their earlier Liaison). As announced by Ray, an IPR
        statement has been issued (http://datatracker.ietf.org/ipr/2603/) that
        needs to be discussed by WG.

- Documents beyond the charter:
        * CDNI rate pacing: not revved up, waiting on other interfaces specs to
        solidify * CDNI handling of HTTPS Delegation: Problem raised and
        discussed in Dallas, 2 Internet-Drafts submitted for IETF-93 that will
        be discussed today.

CDNI Logging, draft-ietf-cdni-logging-19: Iuniana Oprescu
---------------------------------------------------------
- Iuniana: update on ABNF, updated security text re TLS as agreed in Dallas,
Text about order, dependency, sanitization; added examples. - Francois:
Discussion with IESG regarding handling of privacy in logging draft. IESG wants
better guidance to make cdni logging more privacy-friendly. Meeting between
IESG and I-D authors at lunch time just before this meeting. Agreement to put
together a Design Team to assess what is achievable in what timeframes and
recommend how to proceed. WG will decide plan of action  based on these
assessment and recommendations. This “Logging Privacy” Design Team will
comprise folks with CDNI expertise + folks with Privacy/Security expertise
(designated by Stephen Farrell). - Francois: Log aggregation suggest by Stephen
Farrell as one approach that could solve aggregation. One drawback is that it
considerably reduces the ability to do fine-grain
analytics/monitoring/reporting. There are 2 forms of log aggregation: 1)
collapse of all segments log (in HTTP Adaptive streaming) into a single log
entry for the entire movie; and 2) aggregate something like delivery of one
content to 1000 users into a single log entry. Stephen Farrell is thinking
about the latter wrt privacy. 1) has been discussed a lot at the beginning of
the WG and explicitly kept for fuser study as it is tricky and we needed a
simple solution quickly first. - Francois:   Is there WG interest in working on
aggregated logging? - WG: Noone expresses interest. - Ben Niven-Jenkins: Is
aggregation just for privacy? - Francois: Aggregation is both for privacy and
to make logs smaller - Ben: Client issues a request to the uCDN in the first
place; if uCDN subcontracted to dCDN, uCDN still gets logs, and there is no
privacy issue. - Jon Peterson: Aggregation does not necessarily solve privacy
issues; need to define privacy issues first before it can be solved. - Design
Team volunteer in CDNI WG: Kevin Ma, Ray van Brandenburg, Inuiana Oprescu and
Francois Le Faucheur. - Design Team target: make recommendations within 4 weeks
of Design Team being formed (i.e. when privacy/security experts are on-board)

Also anonymization, e.g., of IP addresses such as rfc 6235.  Goal is 4weeks to
come up with the estimate. Volunteers include Ray and Kevin.

CDNI Metadata, draft-ietf-cdni-metadata-10: Ben Niven-Jenkins
------------------------------------------------------------
- Ben: Feedback from Apps Directorate review; lots of comments, nothing seem
hugely major.  About half-done. - Ben: Need to double-check to see it meets the
consensus for security considerations (logging draft is the best statement
thereof) - Francois: I will review the security considerations section and give
guidance - Ben: target to issue a new rev of draft by mid-september - Barry
Leiba: why so many media types, instead of one parameterized? - Ben:  glad to
have input; discussion, see below. - Barry: New media types are cumbersome;
need CDNI review not media type review.  Single media type seems like a more
sensible way to go. - Jan Seedorf: Media type discussion coming up with FCI
discussion.  Would want a media type expert to help.

FCI Documents: Jan Seedorf
draft-ietf-cdni-footprint-capabilities-semantics-06
draft-ma-cdni-capabilities-07
draft-seedorf-cdni-request-routing-alto-06
-------------------------------------------------------------------------------
- Jan: FCI/Metadata had a registry, Metadata switched to mime types, FCI
switched to mime type as well. Meeting on Wednesday at 1pm to talk about
registry vs mime type - Jon: Can we solve the mime type vs registry issues here
and now?
    1. register mime types
    2. create a single mime type and use subtypes
    3. create a registry for CDNI types
- Barry: they are called “media types”, not “mime types” - suggests parameter
for object type, with CDNI controlled registry of object types, with CDNI
experts reviewing. - Ben: Don't think we need that much oversight, but will go
with group consensus. - Barry: Having media type experts review CDNI object
types doesn't make sense. - Jon: Can make the expert review easy to pass; e.g.
have Ben rubber stamp all requests. - Francois: Would it be useful to define
two policies ? - Jon: Not justified to have two policies; just have one. - Ben:
Just use one policy. - Barry: Specification required is probably good enough,
with light oversight suggested to the designated expert. - Jon: Doesn't
“specification required” only require a specification? - Barry: Expert checks
that the spec is suitable for interop. - Jon: Prefers expert review. -
Francois: Everyone seems ok with single media type. Does anyone object to that?
- WG: Noone objects - Jan: So we have concensus - use Wednesday meeting to work
out details.

Routing Request Redirection for CDN Interconnection,
draft-ietf-cdni-redirection-10: Ray van Brandenburg
--------------------------------------------------------------------------------------------------
— Ray van Brandenburg: Redirection Draft Update - AppsDir comments
- Ray: Privacy - dCDN can learn client IP without serving content. Text says
users of the RI can mask IP before sending the request. No comment from the
room - Francois: RI works for subnets; and the delegated request will come to
the dCDN anyway so it will see the full IP address - Jon: wrt HTTPS, RI
discusses HTTP redirections well, but not DNS redirection (problems noted by
HTTPS use case drafts). - Francois: Good point, Ray to reflect this in next
update and then we can submit to IESG (once Media-type conclusion is reflected)

CDNI Control Interface, draft-ietf-cdni-triggers-08: Rob Murray
-------------------------------------------------------
- Rob: addressed Appsdir review comments, addressed comments from Francois
(aligned TLS text + added privacy section). No known issue - Rob: where will
the single Media Type be defined. - Ben: it can be defined in metadata I-D and
other CDNI spec refer to that. - Francois: Media Type decision needs to be
reflected in next rev of cdni-triggers. After that, document can go to IESG
review.

CDNI URI Signing, draft-ietf-cdni-uri-signing-04: Ray van Brandenburg
-------------------------------------------------------------
Ray: URI Signing IPR discussion
Francois: IPR disclosure only applies to segmented content (that was added
according to Dallas decision, following MPEG DASH liaison) Daryl: Segmented
content not strictly required to meet the CDNI WG requirements (segmented
content is for “phase 2”); MPEG asked us to pursue segmented content. Jon: Did
we get a liaison statement asking us to add content to URI signing?
Francois/Daryl: We got a liaison statement saying it would be useful and the
working group decided to do the work. Francois: presented key aspects of
http://datatracker.ietf.org/ipr/2603/ including the fact that the licensing
declaration mentions “possible royalties/fees” Francois: Options:
         1. publish as is
         2. split into two documents: segmented (stays WG document) vs
         non-segmented (individual I-D) 3. change the solution to no longer be
         IPR encumbered 4. drop the IPR encumbered segmented content altogether
Kent Leung: Options 2 and 4 are essentially the same?
Francois: With option 4, the working group drops work on segmented content all
together. Jon: Does the working group care about segmented content.  Why not
just option 4? Francois: Solution is not just for MPEG; working group wanted to
solve the problem if possible. Jon: If we care about segmented content, do
option 2, else do option 4. Kevin: The work is done; not sure why we would't do
option 2. Kent: Option 3 is probably not feasible (i.e. difficult to reliably
circumvent IPR). Preference for option 2. Phillip Sorber: I like option 3. 
Segmented content is important; worth looking at the IPR to see if we can get
around it. Francois (as an individual): I vote for Option 2.  No reason to drop
the work.  Option 2 does not preclude changing the solution to not be IPR
encumbered if we realise we can do that later. Francois: Would Phillip
volunteer to look into a non-IPR-encumbered solution? Phillip: yes Rick Salz:
Go for option 1 but make segmented content support optional. Iuniana: I
recommend Option 2 and Option 3.  Separate and try to un-IPR-encumber. Daryl:
Separate charter requirement for segmented content URI Signing. Jon: Move to a
separate document (option 2). Daryl (as an individual): Option 2. Barry: There
seems to be a strong consensus for Option 2. Ask who can't live with option 2.
Francois: Hum if uncomfortable with option 2.
         no one hummed.
Daryl: Ray to submit segmented content work as an individual draft, and reissue
draft-ietf-cdni-uri-signing without the segmented content support. Kent: What
is the next step for the WG draft?  Revert, then what? Daryl: Revert and do an
in-depth review. Leif Hedstrom: volunteered to do the URI Signing in-depth
review.

HTTPS and delegation of encrypted traffic,
draft-fieau-https-delivery-delegation-00: Iuniana Oprescu
--------------------------------------------------------------------
Iuniana: Redirection methods, Need clarification on manifest rewrite issues,
Need to consider DNS redirection issues and topology hiding, DNSSEC

HTTPS and delegation of encrypted traffic,
draft-slovetskiy-cdni-https-delegation-approaches-00: Sergey Slovetsky
--------------------------------------------------------------------
Sergey: HTTP->HTTPS works, but not secure; HTTPS->HTTPS works, but may not be
secure ; DNS HTTPS redirect doesn't work Daryl: We agreed to discuss in Dallas;
so let’s assume we want to work on that and discuss the details of the two
drafts. Can authors combine their drafts? Jon: What does DANE and the token
give beyond DNSSEC Sergey: ? Jon: Not sure what the token buys. Ben: What is
the use case that is solved by the solution? Is it the redirection that doesn't
work?  Is it a desire to not have to share keys? you shoudl describe the high
level problem you are solving (e.g. is it redirection that does not work? or is
it that CDNs d not want to share keys?) Sergey: It kind of works; but do we
need something stronger? Jon: What extra security does the token provide over
redirect over TLS? Iuniana: HTTP redirect works; DNS is the problem Daryl: When
issuing new rev of draft, clearly identify the perceived problem and then
define the solution to address that problem. Jon: This is about redirection; so
make sur the redirection document mentions the limitations of current support.

Meeting closes
--------------