Subject: [CDNi] Mirja Kühlewind's No Objection on draft-ietf-cdni-footprint-capabilities-semantics-16: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Wed, 20 Apr 2016 08:29:14 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-cdni-footprint-capabilities-semantics-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I did enter enter 'No Objection' because non of my comments should hold
up publication, however, I really would like to see another revision of
this doc to make it easier to read and understand.

1) Intended status
This documents contains two things
   a) Requirements (or here called Design Decision) for a FCI protocol
   b) Definition of the mandatory base object as well as  needed
registries
While a) would clearly be an informational document, I would see b)
rather as being a Standards track document.
Further, the document reads as if b) was added late in the process. 
So my question is: was the intended status discussed in the working group
and why was it decided to go for information?

2) footprint vs. capabilities
I'm sure (I hope) these terms are well understood in the wg, however, for
me it is still not clear why a footprint is not just a capability but
something special. I understood that other capabilities can be bounded to
a footprint, however, can this not also be true for other capabilities?
E.g. a certain protocol is only supported for a certain content type...
or something like this?
Further, I still don't understand why you need a new term called
footprint. In 2.2 you only talk about coverage which would be the better
(more easy to understand) term for me. Also if you don't support
something because of resource restrictions, this would still simple mean
that you don't cover something.
If those terms are well understand and use in the wg, I do understand if
you don't want to apply any changes anymore here. However, for the
readability it might be helpful to at least add a terminology section at
the very beginning of the doc.

3) Reduce Redundancy
I think it would help the readability if the requirements and the
specification bits would be more clearly separated. I guess all
requirements are listed and explained well in section 2. Therefore all
reasoning given in the later section can simply be removed (and if needed
replaced by a reference to the respective subsection in 2). Further, it's
a little confusion that the requirements are phrased as if they should be
addressesd in a future doc, while some of the requirements are already
addressed in this doc by the given definitions.

4) Requirements
   a) It is mentioned a few times that the additional network load by
sending these information must be limited to a reasonable amount,
however, there is no explicit requirement in section 2 that is saying
this. Would it make sense to add one more requirement here?
   b) Not sure if Focusing on Main Use Cases can/should actually be a
requirement. The question might be rather but are the restrictions you
will have by only focusing on the main use case/what cannot/does not have
to be supported (overlapping coverage?)... however, that might only be a
wording thing.

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 20 Apr 2016 22:20:15 +0000

Hi Mirja,

  Thank you for the review.  Some responses to your comments:

  1. You are correct, the base object definition was added later.  The WG had agreed that this draft would create a registry for capabilities (which we later aligned with the forthcoming Metadata interface draft to use the Payload Type registry) and register the mandatory capabilities listed in the document.  The discussion with the AD was that just creating a registry was not a reason to make it Standards Track.  The Payload Type registry, though, requires an object definition and serialization example, so the objects were added to this document.

     I guess I see three options:

     a) Leave the document as Informational,
     b) Change the document to Standards Track, or
     c) Move the object definitions and Payload Type registrations to another draft.

     I'm open to suggestions as to what the best approach here would be?

  2. Footprint is the term used in the Problem Statement (RFC6707), Use Case (RFC6770) and corresponding Metadata (draft-ietf-cdni-metadata-13) documents, so I'd prefer to keep the term, but I can add a Terminology section in the next version.

  3. Understood.  A lot of the sections are there for historical context, but I'll give it another read through and try to remove some redundancy in the next version.

  4. a) The WG spent a lot of time debating what is the correct amount of data to send, which was the reason we wrote this document.  I don't think we want to limit the sending of more data; our goal was to limit the problem scope WG.  I'm not sure we need to add another requirement for network load; I'm also not sure how we would quantify it.
     b) I agree that there is probably more emphasis than necessary on the Main Use Case.  As a historical note, that was there to help move us forward toward a decision.  I can try to wordsmith that in the next version.

thanx!

--  Kevin J. Ma

> -----Original Message-----
> From: Mirja Kuehlewind [mailto:[email-masked]]
> Sent: Wednesday, April 20, 2016 11:29 AM
> To: The IESG
> Cc: [email-masked]; Francois Le
> Faucheur; [email-masked]; [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-cdni-footprint-
> capabilities-semantics-16: (with COMMENT)
>

---

From: Kevin Ma J <[email-masked]>
Date: Sat, 23 Apr 2016 17:13:59 +0000

Hi Mirja,

  We have restructured the document, removing the focus on the main use case and moving the main use case and other historical stuff to appendices and trying to make clear just what the decisions were and what the requirements are.  This should address the redundancy issue.  We have also added a terminology section to better clarify what we mean by footprint and capability.  Finally, we changed the document from Informational to Standards Track and moved over the two missing object definitions from draft-ma-cdni-capabilities.

  I think the document is much more readable and functional now.  Thank you for your input.

thanx!

--  Kevin J. Ma

> From: Kevin Ma J
> Sent: Wednesday, April 20, 2016 6:21 PM
> To: 'Mirja Kuehlewind'; The IESG
> Cc: [email-masked]; cdni-
> [email-masked]; [email-masked]
> Subject: RE: Mirja Kühlewind's No Objection on draft-ietf-cdni-footprint-
>   1. You are correct, the base object definition was added later.  The WG
> had agreed that this draft would create a registry for capabilities (which
> we later aligned with the forthcoming Metadata interface draft to use the
> Payload Type registry) and register the mandatory capabilities listed in
> the document.  The discussion with the AD was that just creating a
> registry was not a reason to make it Standards Track.  The Payload Type
> registry, though, requires an object definition and serialization example,
> so the objects were added to this document.
> 
>   2. Footprint is the term used in the Problem Statement (RFC6707), Use
> Case (RFC6770) and corresponding Metadata (draft-ietf-cdni-metadata-13)
> documents, so I'd prefer to keep the term, but I can add a Terminology
> section in the next version.
> 
>   3. Understood.  A lot of the sections are there for historical context,
> but I'll give it another read through and try to remove some redundancy in
> the next version.
> 
>   4. a) The WG spent a lot of time debating what is the correct amount of
> data to send, which was the reason we wrote this document.  I don't think
> we want to limit the sending of more data; our goal was to limit the
> problem scope WG.  I'm not sure we need to add another requirement for
> network load; I'm also not sure how we would quantify it.
>      b) I agree that there is probably more emphasis than necessary on the
> Main Use Case.  As a historical note, that was there to help move us
> forward toward a decision.  I can try to wordsmith that in the next
> version.
> 
> thanx!
> 
> --  Kevin J. Ma
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 26 Apr 2016 14:11:59 +0200

Hi Kevin,

thanks a lot for performing these changes. The document is much clearer now. Did you confirm these changes on the wg mailing list to make the wg aware of it?

There are a few minor nits the RCF editor will for sure care about. I only have three remaining comments/questions:

1) section 2.5. reads still a little weird because it rather seems to be a summary or conclusion of the previous sections than a new subsection on the same level than the previous ones. However, I don’t have a real suggestion how to fix that. Maybe just add one more introductory sentence. But t’s also okay to leave it as it is.

2) In section 6 I found the term "hop-by-hop transport-layer security mechanisms“. Shouldn’t this be „end-to-end …“?

3) Please also check the references again. I’ve added this comment later to my ballot position, so you’ve probably have not seen it. I still believe that probably the second half of the normative references should be informative and 1-2 of the CDNi informative ones should be normative. Please check again!

Mirja

> Am 23.04.2016 um 19:13 schrieb Kevin Ma J <[email-masked]>:
> 
> Hi Mirja,
>

---

From: Kevin Ma J <[email-masked]>
Date: Tue, 26 Apr 2016 17:40:30 +0000

Hi Mirja,

  Thanks for the (re)review!

  The changes were announced on the list; we will make sure folks have a chance to comment.

  1. We will try and clean up the transition in 2.5.
  2. I think we were thinking of hop-by-hop as CDN-to-CDN, in a cascaded CDN scenario, not router-to-router.  We can update the text to clarify.
  3. We will go back and recheck the references.

thanx!

--  Kevin J. Ma

> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Tuesday, April 26, 2016 8:12 AM
> To: Kevin Ma J
> Cc: The IESG; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-cdni-footprint-
> thanks a lot for performing these changes. The document is much clearer
> now. Did you confirm these changes on the wg mailing list to make the wg
> aware of it?
> 
> 1) section 2.5. reads still a little weird because it rather seems to be a
> summary or conclusion of the previous sections than a new subsection on
> the same level than the previous ones. However, I don’t have a real
> suggestion how to fix that. Maybe just add one more introductory sentence.
> But t’s also okay to leave it as it is.
> 
> 2) In section 6 I found the term "hop-by-hop transport-layer security
> mechanisms“. Shouldn’t this be „end-to-end …“?
> 
> 3) Please also check the references again. I’ve added this comment later
> to my ballot position, so you’ve probably have not seen it. I still
> believe that probably the second half of the normative references should
> be informative and 1-2 of the CDNi informative ones should be normative.
> Please check again!
> 
> Mirja
> 
> 
> >  We have restructured the document, removing the focus on the main use
> case and moving the main use case and other historical stuff to appendices
> and trying to make clear just what the decisions were and what the
> requirements are.  This should address the redundancy issue.  We have also
> added a terminology section to better clarify what we mean by footprint
> and capability.  Finally, we changed the document from Informational to
> Standards Track and moved over the two missing object definitions from
> draft-ma-cdni-capabilities.
> >
> >>> Cc: [email-masked];
> Francois
> >> Le
> >>> https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-
> capabilities-
> >>> semantics/
> >>>
> >>>
> >>>

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 28 Apr 2016 17:12:54 +0000

Hi Mirja,

  The latest -18 should address your other comments.
  1. I made the summary its own section and added an intro clause to ease the transition.
  2. I removed "hop-by-hop" and clarified that we mean "between CDNs".
  3. I made the CDNI Framework reference normative and the HTTP/TLS references informative.

thanx!

--  Kevin J. Ma

> Sent: Tuesday, April 26, 2016 1:42 PM
> To: 'Mirja Kuehlewind (IETF)'
>   2. I think we were thinking of hop-by-hop as CDN-to-CDN, in a cascaded
> CDN scenario, not router-to-router.  We can update the text to clarify.
> > There are a few minor nits the RCF editor will for sure care about. I
> only
> > have three remaining comments/questions:
> >
> > >> but I'll give it another read through and try to remove some
> redundancy
> > in
> > >> the next version.
> > >>
> > >>> I'm sure (I hope) these terms are well understood in the wg,
> however,
> > >> for
> > >>> something special. I understood that other capabilities can be
> bounded
> > >> to
> > >>> If those terms are well understand and use in the wg, I do
> understand
> > if
> > >>> readability it might be helpful to at least add a terminology
> section
> > at
> > >>> a little confusion that the requirements are phrased as if they
> should
> > >> be
> > >>> to be supported (overlapping coverage?)... however, that might only
> be
> > a
> > >>> wording thing.
> > >>>
> > >