Subject: Re: [CDNi] Appsdir early review of draft-ietf-cdni-metadata-09

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 11 May 2015 10:50:03 +0100

Hi Matt,

Thanks for the review and apologies for the delay in responding.

I will discuss your review with my co-authors and we'll re-work the document to incorporate your comments.

Thanks again
Ben

> On 14 Apr 2015, at 20:50, ⌘ Matt Miller <[email-masked]> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> I have been selected as the Applications Area Directorate early
> reviewer for this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat
> e
> ).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-cdni-metadata
> Title: CDN Interconnection Metadata
> Reviewer: Matthew Miller
> Review Date: 2015-04-14
> IETF Last Call Date: N/A
> IESG Telechat Date: N/A
> 
> Summary: This draft is not ready for publication as a Proposed
> Standard and should be revised.
> 
> Comments:
> 
> This draft is written expecting multiple encodings in the future, then
> spends very little space discussing the one encoding that is defined
> (JSON).  The end result is a document that, in my opinion, is too
> abstract.  I think it would be more understandable if this draft
> mentioned and used JSON throughout (e.g., a micro-example for each of
> the defined types).  I think it's appropriate to do this and yet still
> reserve the right to support other encoding formats in the future.
> 
> Also, this draft is not very internally consistent (e.g., terminology
> usage, editorial structuring, etc.), which I found made it hard to
> follow at times.  I would recommend that the authors do a round of
> editing to be more internally consistent; I've noted in the nits a
> number of specific examples.
> 
> Major Issues:
> 
> * I think Section 6.4.2. is underspecified.  There are a number of
> quirks and gotchas I noticed that are not discussed:
> 
>  - dealing with large (requiring more than ~53 bits) integers (encode
> as JSON String)
>  - dealing with duplicate keys within a JSON Object (MUST NOT have
> duplicates)
>  - dealing with escaping (see Minor Issue #2)
> 
>  I note that the examples in 6.4.2.1. illustrate some of the
> concerns, but nowhere are they explicitly discussed.  I would strongly
> recommend outlining these concerns, better would be to refer to RFC
> 7492 (I-JSON) and follow its recommendations explicitly.  I don't
> think this is much of a burden since this document appears to already
> follow them implicitly.
> 
> 
> Minor Issues:
> 
> * In Section 3.1., I find Table 2 hard to follow.  I suggest each row
> be broken out to its own item in an unordered list.  It would also
> help to point to each item's full definition.
> 
> * In Section 4.1.5., note that '\' must be escaped as '\\' in JSON,
> which means the JSON string for a  with a literal '\' would have
> '\\\\' (this also applies for literal '?' and '*').  I can understand
> why an alternative form of escaping, such as percent encoding, would
> be undesirable, but it will be surprising to some to see this "extra
> escaping".  This effect on pattern escaping ought to be called out; if
> not in Section 4.1.5. then I suggest in Section 6.4.2.
> 
> * Sections 8.2., 8.3., and 8.5., seem to cover the concerns, but I
> would recommend reviewing and referencing draf-ietf-uta-tls-bcp, as I
> think you would get a more complete picture here.
> 
> Nits:
> 
> * In Abstract, CDN is not expanded on first occurrence.
> 
> * In Abstract, CDNI is not expanded on first occurrence.
> 
> * In Section 1.2., dCDN is not expanded on first occurrence.
> 
> * In Section 1.2., uCDN is not expanded on first occurrence.
> 
> * Reference to HTTPv1.1 (commonly referred to as "HTTP/1.1") (RFC7230,
> et al) comes very late (Section 7.2.), first noted in Section 1.2.
> 
> * No reference to HTTPv2.0 (often referred to as "http/2")
> (draft-ietf-httpbis-http2-17), first noted in Section 1.2.
> 
> * Reference to HTTP over TLS (RFC 2818) comes very late (Section
> 7.2.), first noted in Section 1.2.
> 
> * No reference to JSON (RFC 7159), first noted in Section 2.
> 
> * In Section 3.2., the two tables are not captioned.
> 
> * In Section 4.2.4.1., "protocol" is not capitalized (i.e.,
> "Protocol") like other type references in "Type: List of protocol object
> s"
> 
> * In Section 6. and many of its subsections, "Downstream CDN" is often
> used instead of "dCDN", which is elsewhere in this document.  I would
> recommend more consistency and use "dCDN".
> 
> * In Section 6. and many of its subsections, "Upstream CDN" is often
> used instead of "uCDN", which is elsewhere in this document.  I would
> recommend more consistency and use "uCDN".
> 
> 
> - -- 
> - - m&m
> 
> Matt Miller < [email-masked] >
> Cisco Systems, Inc.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
> 
> iQEcBAEBCgAGBQJVLW9yAAoJEDWi+S0W7cO1g9UIAJIV8yShj/0KiqhC82m/ixk6
> VkW5IZvB8iWp9mVStx+fQtwwm1B7LrvccFnSr5CwmyURjmaljSBKP97F6I/QnjpL
> 6YJkfGyRLTP1r/fpH7N9ptpHZJQpNd5iQlBElWforfBaNHd5xm4mhLkCzlv8UKjk
> TP8SDYeW5pKvUkHtK7fhW7h2eTcs/EuPZr/GlTb9yIWQAAwN0q7JTnwXVN1Lo9uQ
> ap1mqUnG2YdZMuAKqrDUQRywazIuBGPu8DopbKX6Hl9fyuSEnPUry73P+7aK727x
> T+/qHyARqy5PGSgesRYAQdFy3gS4/8SeeYWHpkE+7MPSjTNj4nTralxfcu7uxAU=
> =+QNl
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni