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

From: ⌘ Matt Miller <[email-masked]>
Date: Tue, 14 Apr 2015 13:50:10 -0600

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.