Subject: [CDNi] AD review of draft-ietf-cdni-footprint-capabilities-semantics-11

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Mar 2016 12:32:05 +0000

I only have two substantive comments, which come out as questions I'd
like you to answer for me:

In Section 5:

   Advertiseing support
   for mandatory-to-implement GenericMetadata types SHOULD be supported
   but would be redundant.  CDNs SHOULD NOT advertise support for
   mandatory-to-implement GenericMetadata types.

I don't understand this combination of requirements.  It appears to
say that you SHOULD be able to advertise support for MtI types, but
that you SHOULD NOT do it.  Is that correct?  What/why?  (Also,
"advertising" only has one "e".)

In the 8.1 subsections:

   Encoding: see Section 7

Where in Section 7 is the information about encoding?

--------

The rest are only some minor editorial suggestions, which you can
disagree with and ignore if you prefer.  If you choose to accept my
suggested changes, just queue them up for the next version -- there's
no need for an update now unless my questions above result in one.

-- Section 2 --

   Some CDNs aspire to cover the entire world, which we will henceforth
   call global CDNs.

That sounds like it's "the entire world" that you'll be calling
"global CDNs".  Consider this:

NEW
   Some CDNs aspire to cover the entire world; we will call those
   "global CDNs".
END

-- Section 4 --

   One
   can imagine that such additional information is implicitly associated
   with a given footprint, e.g., due to contractual agreements (e.g.,
   SLAs), business relationships, or perceived dCDN quality in the past.

This is my kookiness: I generally dislike "i.e." and "e.g." because
they're so often overused and unnecessary ("i.e." can almost always be
removed, and "e.g." is usually better rendered in plain English).  But
I especially dislike nesting them, as here: it just seems awkward.
May I suggest this?:

NEW
   One
   can imagine that such additional information is implicitly associated
   with a given footprint, due to such things as SLAs and other contractual
   agreements, business relationships, or past perceptions of dCDN quality.
END

   It is reasonable to assume that a significant part of the actual
   footprint advertisement will happen in contractual agreements between
   participating CDNs, i.e., prior to the advertisement phase using the
   CDNI FCI.  The reason for this assumption is that any contractual
   agreement is likely to contain specifics about the dCDN coverage
   (i.e., the dCDN footprint) to which the contractual agreement
   applies.  In particular, additional information to judge the delivery
   quality associated with a given dCDN footprint might be defined in
   contractual agreements (i.e.  outside of the CDNI FCI).  Further, one
   can assume that dCDN contractual agreements about the delivery
   quality associated with a given footprint will probably be based on
   high-level aggregated statistics (i.e., not too detailed).

Take this or leave it, as you please, but I just want to demonstrate
what I mean when I say that "i.e." is almost always unnecessary and
can be removed.  I would have written that this way:

NEW
   It is reasonable to assume that a significant part of the actual
   footprint advertisement will happen in contractual agreements between
   participating CDNs prior to the advertisement phase that uses the
   CDNI FCI.  The reason for this assumption is that any contractual
   agreement is likely to contain specifics about the dCDN coverage
   (the dCDN footprint) to which the contractual agreement applies.
   In particular, additional information to judge the delivery quality
   associated with a given dCDN footprint might be defined in contractual
   agreements outside of the CDNI FCI.  Further, one can assume that dCDN
   contractual agreements about the delivery quality associated with a
   given footprint will probably be based on high-level aggregated
   statistics, and will not be too detailed.
END

Do you not think it reads better without the parentheses and Latin?
(If not, take heart: Alexey likes the Latin abbreviations, and won't
be making these sorts of comments...)

   For each of these footprint types, there are capabilities associated
   with a given footprint, i.e., the capabilities (e.g., delivery
   protocol, redirection mode, metadata) supported in the coverage area
   for a "coverage/reachability" defined footprint, or the capabilities
   of resources (e.g., delivery protocol, redirection mode, metadata
   support) for a "resource" defined footprint.

Another suggestion along the same lines, because of "e.g." nested within "i.e.":

NEW
   For each of these footprint types, there are capabilities associated
   with a given footprint:
     o  capabilities such as delivery protocol, redirection mode, and
        metadata, which are supported in the coverage area for a
        "coverage/reachability" defined footprint, or
     o  capabilities of resources, such as delivery protocol, redirection
        mode, and metadata support, which apply to a "resource" defined
        footprint.
END

One more example:

   Multiple footprint constraints are additive, i.e., the
   advertisement of different types of footprint narrows the dCDN
   candidacy cumulatively.

In this case, I would replace "i.e." with a colon:

NEW
   Multiple footprint constraints are additive: the
   advertisement of different types of footprint narrows the dCDN
   candidacy cumulatively.
END

-- Section 8.1 --
I suggest adding the section numbers into the table, so, for example,
the Specification column for FCI.DeliveryProtocol would be "RFCthis,
Section 8.1.1".

-- 
Barry, ART Director

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 8 Mar 2016 14:42:51 +0000

Hi Barry,

  Thanks for the review.  Responses to your two substantive comments inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Barry Leiba
> Sent: Tuesday, March 08, 2016 7:32 AM
> To: [email-masked]
> Cc: <[email-masked]>
> Subject: AD review of draft-ietf-cdni-footprint-capabilities-semantics-11
> 

The thought here was that we want to be able to advertise when a dCDN does not support a given MtI metadata; it could be a temporary outage, in a limited footprint, but such a capability advertisement would be valid.  The dCDN would also need to be able to advertise when support was reestablished.  There was also a thought that we might want a full capability state dump command, in which case we would send MtI metadata as well.  In the typical case, however, we wanted to not waste the bandwidth sending MtI metadata information when we figured they would all be supported.

Would it help to make the second sentence a RECOMMEND, rather than a SHOULD, and add some text as to the reasoning (i.e., saving bits)?

> Where in Section 7 is the information about encoding?

Section 7.5 has the example of the capability serialization of the three objects described in sections 7.2, 7.3, and 7.4 (corresponding to the registrations in sections 8.1.1, 8.1.2, and 8.1.3)

Would it help to make the section references 7.2 and 7.5, 7.3 and 7.5, and 7.4 and 7.5, in sections 8.1.1, 8.1.2, and 8.1.3, respectively?

We will address the other editorial comments in the next version.

thanx!

--  Kevin J. Ma

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Mar 2016 15:33:22 +0000

Thanks for the quick reply, Kevin.

> The thought here was that we want to be able to advertise when a dCDN
> does not support a given MtI metadata; it could be a temporary outage,
> in a limited footprint, but such a capability advertisement would be
> valid.  The dCDN would also need to be able to advertise when support
> was reestablished.  There was also a thought that we might want a full
> capability state dump command, in which case we would send MtI
> metadata as well.  In the typical case, however, we wanted to not
> waste the bandwidth sending MtI metadata information when we figured
> they would all be supported.
>
> Would it help to make the second sentence a RECOMMEND, rather than a
> SHOULD, and add some text as to the reasoning (i.e., saving bits)?

Well, RECOMMEND and SHOULD mean the same thing (see RFC 2119); they're
just different parts of speech.  Yes, it would help to rephrase and
explain what the issue is here.

> Section 7.5 has the example of the capability serialization of the
> three objects described in sections 7.2, 7.3, and 7.4 (corresponding
> to the registrations in sections 8.1.1, 8.1.2, and 8.1.3)
>
> Would it help to make the section references 7.2 and 7.5, 7.3 and 7.5,
> and 7.4 and 7.5, in sections 8.1.1, 8.1.2, and 8.1.3, respectively?

It would.  Thanks.

I'll watch for an update, and will request last call then.

Barry

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 8 Mar 2016 15:47:48 +0000

Hi Barry,

  I'll make the updates and submit a new version.

thanx!

--  Kevin J. Ma

> Sent: Tuesday, March 08, 2016 10:33 AM
> To: Kevin Ma J
> Cc: [email-masked];
> <[email-masked]>
> Subject: Re: AD review of draft-ietf-cdni-footprint-capabilities-
> semantics-11
>

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 8 Mar 2016 18:16:58 +0000

Hi Barry,

  I've posted -12, which hopefully addresses your comments.  I took all but one of the editorial suggestions, and fixed a couple of random typos.  Please let me know if you see anything further that needs addressed.

thanx!

--  Kevin J. Ma

> From: Kevin Ma J
> Sent: Tuesday, March 08, 2016 10:48 AM
> To: 'Barry Leiba'
> Subject: RE: AD review of draft-ietf-cdni-footprint-capabilities-
> semantics-11
> 
> Hi Barry,
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Mar 2016 18:35:04 +0000

Looks great; thanks.  Last call going out...

Barry