RE: WG Last Call: draft-ietf-cdi-scenarios-00.txt

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

This was the only feedback received during WG last call on this draft, so
I'll respond to these points in-line below.


At 03:42 PM 4/5/2002 -0800, Reinaldo Penno wrote:
>Comments on the scenarios draft...
>
>1 - The expression "real world" could be replaced by "effectively" or
>"production networks" or "commercial networks". Real World only means that
>there is protocols designed for the unreal world (whatever this definition
>maybe).

Good point. I went with "production networks".

>2 - "Terms in ALL CAPS are defined in [1]". IMO this is should be removed.
>There are tons of drafts that use definitions/terminology contained in some
>other draft and do not use this all caps stuff. Besides it makes the draft
>awkward to read since there is a profusion of all caps terms. Besides all
>caps are usually used in titles, names, drawings, etc

In CDI, there's enough words that could cause a sentence to have a
completely different meaning based on whether we meant to use the word in a
CDI context or a Webster's context (e.g. "request"). While in most of these
cases the reader could figure it out based on context, if we're trying to
get across basic concepts to an audience that's seeing CDI for the first
time, I think it's safer to make no assumptions. Therefore, I think there
is a need to provide emphasis with certain words.

You're correct that not all drafts do this the ALL CAPS way, but all the
CDI drafts currently use this notation. Speaking as a co-chair and editor,
I'd prefer to keep ALL CAPS because we already went through the work of
making it ubiquitous. While I can't say I love it, I think it's as good as
or better than not having it. In RFCs, we don't have much to work with to
show emphasis. My personal preference would be for RFCs to be in a richer
format so we could use things like italics. But that's another discussion
entirely. With the tools we have today, emphasis could be shown by
capitalizing the first letter, doing ALL CAPS, putting something in
parentheses after the term, putting **stars** around it, putting 'quotes'
around it... in my opinion, they all kinda stink. So I say we just pick one
and stick with it. :)


Incidentally, while there are tons of RFCs that don't use ALL CAPS
notation, there are some that do. One of them was written by Mark Day. :)

In conclusion, if there's popular opinion for doing something different
with these terms, people should speak up ASAP since these drafts are
starting to pass last call. But I'd want to see rough consensus across a
reasonably large sample size before embarking on changing this notation in
all our drafts.

>3 - "For example, a BCN only interested in aggregating ACCOUNTING data". a
>BCN (is) only interested

I changed the sentence to: "For example, if a BCN is only interested in
aggregating ACCOUNTING data on behalf of other CNs, it would only need to
have an ACCOUNTING INTERNETWORKING interface on its CIGs." (Just adding
"is" didn't finish the job.)

>4 - "Note that once it's participating in
>   DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, the
>   SERVERS within the LCN effectively take on the role of SURROGATES"
>
>   I suggest "Note that once SERVERS participate in distribution and
>accounting internetworking, they effectively take the role of surrogates"

Changed.

>5 - "  The next step would be to configure CONTENT INTERNETWORKING
>   protocols on the CIGs of the respective CNs in order to technically
>   support the terms of the NEGOTIATED RELATIONSHIP". 
>
>   I doubt that a CI protocol would uphold all parameters in a negotiated
>relatioship since a lot of them are subjective, and other (even technically)
>are measured by others means which has nothing to do with a routing protocol
>(the easiest example is SLAs). Actually a routing protocol cannot enforce
>them since a routing protocol resides on the control plane, not on teh data
>plane.

I don't think the sentence is meant to imply that *all* terms are upheld by
the protocol, though I suppose it could be read that way. To try and add
clarity, I added a brief paragraph in that section:

"Note also that some terms of the NEGOTIATED RELATIONSHIP would be upheld
through means outside the scope of CDI protocols. These could include
non-technical terms (such as financial settlement) or other technical terms
(such as SLAs)."


Let me know if you think this gives the improvement you're looking for.

>6 - "That is, first the
>   protocol configurations would be changed to cease the movement of
>   ADVERTISEMENTS and/or ACCOUNTING data between the networks. After
>   this, the NEGOTIATED RELATIONSHIP would be legally terminated."
>
>IMO it could be the other way around. You terminate the relatioship and this
>is the key to unhook whatever is hooked. 

True. I changed the wording so that we don't imply any particular order:

"In the event that the controlling interests of two CNs no longer wish to
have their networks interconnected, it is expected that these tasks would
be undone. That is, the protocol configurations would be changed to cease
the movement of ADVERTISEMENTS and/or ACCOUNTING data between the networks,
and the NEGOTIATED RELATIONSHIP would be legally terminated."

>7 - "2.  Commands affecting the DISTRIBUTION of CONTENT may be issued
>       within the ORIGINATING CN, or may also be issued within the
>       ENLISTED CN."
>
>      But they are different commands, right? a enlisted CN can filter the
>distribution of content, but cannot stop the distribution on the origin
>itself. My point is an enlisted CN would have authority over its side of the
>distribution, not the origin side.

You're correct. I spent a fair amount of time trying to figure out how to
get this point across. To those of us working in CDI, it's pretty obvious.
To someone new to the material, it may not be.

I added a sentence so it now reads:

"Commands affecting the DISTRIBUTION of CONTENT may be issued within the
ORIGINATING CN, or may also be issued within the ENLISTED CN. The latter
case allows local decisions to be made about DISTRIBUTION within the
ENLISTED CN, but such commands would not control DISTRIBUTION within the
ORIGINATING CN."

It's more wordy, but it's the best I could come up with. If anyone has
another proposal, please speak up.


Anyway, I'll send in the version with all these changes as an
Internet-Draft, and if nobody has further input on the final changes listed
above, it'll be ready to go to the IESG.

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