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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 20 Apr 2016 11:19:51 -0700

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.

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 20 Apr 2016 22:38:14 +0000

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:[email-masked]]
> Sent: Wednesday, April 20, 2016 2:20 PM
> To: The IESG
> Cc: [email-masked]; Francois Le
> Faucheur; [email-masked]; [email-masked]; [email-masked]
> Subject: Alissa Cooper's Discuss on draft-ietf-cdni-footprint-
> capabilities-semantics-16: (with DISCUSS and COMMENT)
>

---

From: Jan Seedorf <[email-masked]>
Date: Thu, 21 Apr 2016 09:56:00 +0200

Hi Alissa and Mirja,

just add to Kevin's points below:
-- We are open for suggestions on how to resolve the normative reference 
issue.
-- Indeed a lot of the text explains how the WG arrived at some design 
decisions. Since some of these decisions were not so obvious at the 
beginning (and are the result of lengthy discussions and consensus 
building), the documents tries to capture our reasoning for the future, 
i.e. the time when the CDNI WG will have finished its work. Having said 
that, the text can most likely be shortened and streamlined, Kevin and I 
will try that.

  - Jan

Am 21.04.2016 um 00:38 schrieb Kevin Ma J:
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

-- 
****************************
Prof. Dr. Jan Seedorf
[email-masked]
****************************
Hochschule für Technik Stuttgart
Fakultät Vermessung, Informatik und Mathematik
Schellingstr. 24
D-70174 Stuttgart
www.hft-stuttgart.de
****************************

---

From: Kevin Ma J <[email-masked]>
Date: Sat, 23 Apr 2016 17:14:04 +0000

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

> From: Kevin Ma J
> Sent: Wednesday, April 20, 2016 6:39 PM
> To: 'Alissa Cooper'; The IESG
> Cc: [email-masked]; cdni-
> [email-masked]; [email-masked]
> Subject: RE: Alissa Cooper's Discuss on draft-ietf-cdni-footprint-
>   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.
> 
>   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
>