Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-footprint-capabilities-semantics-16: (with DISCUSS and COMMENT)

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

Hi Alissa,

  We have restructured the document, moving the historical stuff to appendices and trying to make clear just what the decisions were.  This should address the redundancy issue as well.  The mandatory-to-implement footprint text has also been removed.

  We also changed the document from Informational to Standards Track and moved over the two missing object definitions from draft-ma-cdni-capabilities.

  I think the document is much more readable and functional now.  Thank you for your input. 

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Kevin Ma J
> Sent: Wednesday, April 20, 2016 6:39 PM
> To: 'Alissa Cooper'; The IESG
> Cc: [e-mail]; cdni-
> [e-mail]; [e-mail]
> Subject: RE: Alissa Cooper's Discuss on draft-ietf-cdni-footprint-
> capabilities-semantics-16: (with DISCUSS and COMMENT)
> 
> Hi Alissa,
> 
>   Thanks for the review.  Some responses to your comments:
> 
>   As mentioned in the response to Mirja's comments, a lot of the text is
> historical and was intended to document how we came to the decisions that
> we did, after having spent a lot of time in circular discussions, to try
> and avoid getting into those discussions again in the future.
> 
>   wrt normative references to this document, your hunch is correct, and in
> my latest version of draft-ma-cdni-capabilities-08 I did make the
> reference to this document normative.  As mentioned in the response to
> Mirja's comments, I'm open to suggestions on the best resolution.
> 
>   1. I can try to edit the doc for better flow/readability.
> 
>   2. The footprint discussion in CDNI has a long history (of arguing about
> what is a "good" footprint), but we agreed to take these 3 footprint
> types, which we agreed would be useful, and start with them; we also then
> agreed to have a registry where we could define new (better, more
> flavourful) footprint types in the future.  The footprint types in this
> document match the footprint types defined in the forthcoming CDNI
> Metadata interface document (which creates the registry and registers
> these types).  I think what we mean by "mandatory-to-implement" is that
> all implementations must understand how to parse these footprint types.
> The question of how to interpret them, i.e., how to map a US country code
> footprint, or a specific AS number footprint, to a client request is
> beyond the scope of the document.  I could try to clarify that in the
> text.
> 
> thanx!
> 
> --  Kevin J. Ma
> 
> > -----Original Message-----
> > From: Alissa Cooper [mailto:[e-mail]]
> > Sent: Wednesday, April 20, 2016 2:20 PM
> > To: The IESG
> > Cc: [e-mail]; Francois
> Le
> > Faucheur; [e-mail]; [e-mail]; [e-mail]
> > Subject: Alissa Cooper's Discuss on draft-ietf-cdni-footprint-
> > capabilities-semantics-16: (with DISCUSS and COMMENT)
> >
> > Alissa Cooper has entered the following ballot position for
> > draft-ietf-cdni-footprint-capabilities-semantics-16: Discuss
> >
> > 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/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I agree with Mirja's point #1, and I think it is DISCUSS-worthy. The
> > document seems to be a mix of almost stream-of-conscious reasoning for
> > how the WG arrived at particular design decisions (which probably
> doesn't
> > need to be in the document at all), requirements on the CDNI FCI,
> > requirements on CDNs (Sec. 5), and then the definition of objects the
> FCI
> > will use. At a minimum, the last two of these seem like they need to be
> > in a standards-track document if interoperability is to be achieved.
> > Thinking about it another way, when an FCI solution document does get
> > written, won't it need a normative reference to this document because of
> > Section 7? My hunch is that the answer is yes.
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > (1) In line with Mirja's points #1 and #3, I also that the intermingling
> > and redundancy in the text makes the document unclear and probably not
> > too easily accessible for implementers (e.g., burying requirements about
> > what CDNs should and shouldn't advertise in the middle of a document
> that
> > up to that point seemed to be mostly about the motivations for designing
> > footprints/capabilities in particular ways). I would suggest
> streamlining
> > the text so that the requirements on the FCI are clearly enumerated, and
> > the motivation text is stripped or moved later in the document.
> >
> > (2) Section 4: "For all of these mandatory-to-implement footprint types
> > ..." seems like a misuse of the term "mandatory-to-implement." I thought
> > this section was specifying requirements for the FCI which is to be
> > specified, but this implies that all conforming implementations would
> > also have to implement all of the footprint types (country code, AS, and
> > IP prefix). Has that already been decided as well? If so, it could be
> > explained more clearly in the text.
> >