Re: [CDNi] Stephen Farrell's No Objection on draft-ietf-cdni-footprint-capabilities-semantics-16: (with COMMENT)

[Kevin Ma J <[e-mail]>]

Hi Stephen,

  In the latest version, the requirement for full IP addresses has been removed, and a we simply reference the forthcoming Metadata draft.  

thanx.

--  Kevin J. Ma 

> -----Original Message-----
> From: Kevin Ma J
> Sent: Thursday, April 21, 2016 12:54 PM
> To: 'Stephen Farrell'; The IESG
> Cc: [e-mail]; cdni-
> [e-mail]; [e-mail]
> Subject: RE: Stephen Farrell's No Objection on draft-ietf-cdni-footprint-
> capabilities-semantics-16: (with COMMENT)
> 
> Hi Stephen,
> 
>   Thanks for the review.  Responses to your comments:
> 
>   - I do not have a response for the IPR question.  :)
> 
>   - The only case I can think of where a /32 might be useful is if you
> know of a network behind a NAT and want to advertise capability changes
> for all clients behind that NAT.  In that case, the single IP is self-
> aggregating?  I don't recall if there were other use cases that were
> raised for /32.
> 
>     wrt the larger CDNI Privacy question on IP addresses, I think the
> Footprint & Capabilities interface (FCI) and the (forthcoming) Metadata
> interface (MI), are different from Logging and Redirection, in that we are
> not using client IP addresses.  The Footprint type (defined in the MI
> document) is intended to be used by MI and FCI to describe, broadly, to
> which clients content may be delivered.  This is different from Logging
> and Redirection where the IP uniquely identifies an individual client
> making a request.  I don't see this violating an individual client's
> privacy; is there another third party privacy concern here?  (disclaimer:
> I do not claim to be a privacy expert, so I am genuinely interested in
> knowing if I missed a privacy angle.)
> 
>   - The value "https1.1" is defined (along with "http1.1") in the
> forthcoming Metadata interface document.  It is defined as "HTTP/1.1 Over
> TLS". The FCI interface will share the protocol types registry defined by
> the Metadata draft, so I copied the value for the example.
> 
> thanx!
> 
> --  Kevin J. Ma
> 
> > -----Original Message-----
> > From: Stephen Farrell [mailto:[e-mail]]
> > Sent: Thursday, April 21, 2016 8:04 AM
> > To: The IESG
> > Cc: [e-mail]; Francois
> Le
> > Faucheur; [e-mail]; [e-mail]; [e-mail]
> > Subject: Stephen Farrell's No Objection on draft-ietf-cdni-footprint-
> > capabilities-semantics-16: (with COMMENT)
> >
> > Stephen Farrell has entered the following ballot position for
> > draft-ietf-cdni-footprint-capabilities-semantics-16: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-
> > semantics/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> >
> > - I wonder if IETF participants know if the phrase "included in
> > a standard adopted by IETF" used in the IPR declaration does
> > or does not apply to this informational document? FWIW, I do
> > not know.  (We see this from time to time and mostly I think
> > it's just a case of using company-standard IPR boilerplate and
> > not considering informational and experimental RFCs, but who
> > knows. I think I do recall one company modifying their IPR
> > boilerplate before when this ambiguity was pointed out to
> > them, so maybe if someone knows someone here, that'd be good
> > info to pass on...:-)
> >
> > - section 4: I don't get why a full IP address is needed here,
> > i.e. the v4 /32 or v6 /128. Why is that? And if it is needed,
> > will it cause the usual CDNI privacy issue for a standards
> > track document?
> >
> > - 7.5: the value "https1.1" is odd - would that really be
> > used?
> >