Re: Comments on draft-day-cdnp-scenarios-04

["Phil Rzewski" <philr@inktomi.com>]

(Before I get on with the proper content of this message, I should indicate
that the minutes from the IETF52 CDI BOF should be on their way soon.
Michael Speer of Sun actually sent them to me weeks ago, but for some odd
reason, they never arrived in my inbox. We're trying again tomorrow morning.)

As indicated by the prior message, I've sent in another revision of the
Scenarios draft. I unfortunately haven't gotten any response other than
Mark Day's comments that came in right at the beginning of IETF52. Well, he
provided enough to chew on, and I had a couple minor changes of my own to
make, so I figured a new revision might be a way to stir things up.

Below I detail each one of Mark's suggestions and what change was made. In
addition to those changes, the other things I've taken care of in this
revision include:

- Improved abstract. I remember seeing an IETF-wide grump message saying
the abstracts are bad everywhere, so I'm reacting to that.

- I changed the use of the word "MAY" to the less formal "may", since we're
not defining a protocol here nor are we defining strict rules of use.

Anyway, the interesting stuff is all below.


At 12:09 PM 12/12/2001 -0500, Mark Day wrote:
>(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.

I'm now pointing to the Model draft right off the bat so people will get
the definition of content internetworking, because I want to avoid
excessive repeated text. As for "what scenarios are", Webster's does a fine
job of defining the word, but I tried to weave their definition into the
intro without sounding too pretentious. Let me know if it works.

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

Removed.

The only motivation for having the word there in the first place was to
reinforce that we're not trying to be exhaustive... but I say that in more
detail later in the document.

>(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.

Fixed.

>(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.

I shortened this and moved it to the end of the intro, making it a general
reference to the Architecture document.


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

Changed.

>(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.

Changed. Hopefully the changes to the intro will also make this section
less of a surprise.

>(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.

Changed.

>(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..."

Changed.

>(Sec 2.1) The word "enlisted" is used before it is defined.
>
>(Sec 3) Definitions of "enlisted" and "originating" should probably move to
>model, be used consistently across CDI.

I actually forget if we made a decision on this at IETF52 (I hope to have
the minutes in my possession soon), but I'll assume this is still your
position. I've capitalized the terms and deleted my definition. So you have
it for Model, the definitions I'd like to go with (expanded slightly to
have a more "Model-y" feel to them):


ENLISTED
Describes a CONTENT NETWORK that, as part of a NEGOTIATED RELATIONSHIP, has
accepted a DISTRIBUTION task from another CONTENT NETWORK, has agreed to
perform REQUEST-ROUTING on behalf of another CONTENT NETWORK, or has agreed
to provide ACCOUNTING data to another CONTENT NETWORK. Contrast with
ORIGINATING.

ORIGINATING
Describes a CONTENT NETWORK that, as part of a NEGOTIATED RELATIONSHIP,
submits a DISTRIBUTION task to another CONTENT NETWORK, asks another
CONTENT NETWORK to perform REQUEST-ROUTING on its behalf, or asks another
CONTENT NETWORK to provide ACCOUNTING data. Contrast with ENLISTED.

Of course, if people would like to propose different definitions, I'm
open-minded. These are longer than they were previously (when I was
defining them only in terms of distribution, which I realize now is an
error if we want to allow for CNs that provide only a subset of the three
interfaces, and yet still want to offer services to each other).

>(Sec 2.1) "the PCN would only need to participate" --> "the PCN need only
>participate"
>
>(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.

Changed, I think. I wasn't sure just how many cases of this you thought
need changing, so let me know if I've still got it wrong in some way.

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

I was a little lacking on ideas of what to put in such a section, but I did
put something in there that kinda jives with what I did for the other CN
types. Any other thoughts are welcomed.


>(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"

Deleted.

I only added it because, in discussing a past version of Scenarios, we
ended up talking about some very different types of Content Networks and
what you could do with them in terms of Request-Routing... such as the
example I mentioned there: the difference between a cable modem service
provider (such as the bankrupt "@" company) and a "tier 1" CDN (such as the
"A" company). We argued for a couple days before realizing that we were
thinking about completely different example networks, so I figured that it
should be captured somewhere so we don't go reinventing the wheel every
time we debate.

That confusion hasn't come up since (though we've admittedly been debating
less than we used to), and I don't use the terms elsewhere in the
document... so I've deleted it. I'd like to hear if anyone else found the
terms useful/confusing and use that as a basis for deciding whether to move
it to Model.

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

Changed.

>(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.

Added.

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

Changed.

>(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.

Ok, I took a stab at writing this as a new section (now Section 3). Since
it's a first pass, I welcome people's suggestions on how to expand/improve.

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

Changed.

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

Changed.

>(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.

Yeah. Well, the one I had there about a BCN possibly doing fraud detection
and/or auditing was the only one I could think of that was apparent from
the specific scenarios. If others disagree, I can remove it and just have
the reference to the architecture document. As it is, I added a reference
to the architecture document.

--
Phil Rzewski - Senior Architect - Inktomi Corporation                  
650-653-2487 (office) - 650-303-3790 (cell) - 650-653-1848 (fax)