Comments on draft-day-cdnp-scenarios-04

["Mark Day" <markday@cisco.com>]

Since I know Phil wants some comments on his recent edits, here goes.

--Mark

(Sec 1) The introduction needs to say something about what content
internetworking is and what scenarios are before going on to tell what
content internetworking scenarios are good for.

(Sec 1 & throughout) The oft-used phrase "logical scenario" seems redundant
unless there is some offered contrast to illogical scenarios, physical
scenarios, etc.

(Sec 1) The introduction shouldn't use the CAPITAL LETTERS style.  Those
conventions should be noted, along with the reference back to the model
document, after the introduction and before the scenarios themselves, and
the convention shouldn't be used before it's introduced.

(Sec 1) The text starting "Each of the logical internetworking scenarios..."
and ending with "functionality of the three systems" is very obscure to me.
Either it's not really introduction (so should be moved somewhere else) or
it is introductory and needs to be phrased in a way that would be clear to a
person coming to this material for the first time.

(Sec 1) "For specific historical scenarios" --> "For specific examples of
systems"

(Sec 2) This text is interesting but seems to have the wrong title.  Maybe
it should be "Special Cases of Content Networks"?  The section is also not
anticipated in the introduction -- we expect to go straight into scenarios
and instead we get a sort of discussion of content network flavors.  On
first reading, I thought these *were* the scenarios being described.

(Sec 2) At the end of the first paragraph of section 2, it would be nice to
just quickly list the names of the special cases, so that the reader knows
how many there are and roughly what they are.

(Sec 2.1) "This set of assumptions implies multiple things about the PCN's
CONTENT INTERNETWORKING relationships. First, it is implied that the PCN
contains the AUTHORITATIVE REQUEST-ROUTING SYSTEM for the PUBLISHER's
CONTENT. This would allow..."
   -->
   "Several implications follow from knowing that a particular CN is a PCN.
First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING SYSTEM for the
PUBLISHER's CONTENT. This arrangement allows..."

(Sec 2.1) The word "enlisted" is used before it is defined.

(Sec 2.1) "the PCN would only need to participate" --> "the PCN need only
participate"

(Sec 2.2) The description of a BCN doesn't have an "implications" paragraph
parallel to the ones for PCN and LCN.

(Sec 2.3) The description of implications for LCN needs to have a
passive-ectomy performed on it, in much the same way as described for
section 2.1 above.

(Sec 2.4) The discussion of regional vs. global CNs seems pretty
unconvincing, and I am a little unclear about its role in the document. Even
if we want to make the distinction that is made here, does the distinction
belong in the scenarios document?  It feels like more of an issue for the
model document.  And is the right terminology "global" vs. "regional"?

(Sec 2.4) "Naturally, there" --> "There"

(Sec 2.4) "pigeonholed" --> "classified"

(Sec 3) "CLIENT REQUEST" -- was this supposed to be CONTENT REQUEST?

(Sec 3) Definitions of "enlisted" and "originating" should probably move to
model, be used consistently across CDI.

(Sec 3) Just before starting section 3.1, it would be great to have a short
list of the scenario names. Again, the reader would be cued as to how many
there are and roughly what they cover.

(Sec 3.1) "these CIs would be interconnect" --> "these CIs would
interconnect"

(Sec 3.1) I was a little surprised that the "general scenario" said nothing
about how the internetworking arrangements would be set up or torn down.
Whether that's folded into the "general scenario" or treated on its own, I
think we need to describe how that happens.

(Sec 3.1) "SURROAGTE" --> "SURROGATE"

(Sec 3.2) "are separate" --> "there are separate"

(Sec 4) I think there are additional security issues just in doing CDI --
requests and/or content potentially being hijacked, etc.  I think we have
usually said that those are to be addressed in the architecture document. At
a minimum you might want to have that reference, or you might want to avoid
that dependency by listing the security issues apparent just within the
scenarios themselves.