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

[Kevin Ma J <[e-mail]>]

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

> -----Original Message-----
> From: Kevin Ma J
> Sent: Wednesday, April 20, 2016 6:21 PM
> To: 'Mirja Kuehlewind'; The IESG
> Cc: [e-mail]; cdni-
> [e-mail]; [e-mail]
> Subject: RE: Mirja Kühlewind's No Objection on draft-ietf-cdni-footprint-
> capabilities-semantics-16: (with COMMENT)
> 
> 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:[e-mail]]
> > Sent: Wednesday, April 20, 2016 11:29 AM
> > To: The IESG
> > Cc: [e-mail]; Francois
> Le
> > Faucheur; [e-mail]; [e-mail]; [e-mail]
> > Subject: Mirja Kühlewind's No Objection on draft-ietf-cdni-footprint-
> > capabilities-semantics-16: (with COMMENT)
> >
> > 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.
> >