Re: [CDNi] I-D Action: draft-ietf-cdni-request-routing-extensions-07.txt

Hi Ori,

  A couple of nits that you may want to cleanup in AUTH48 (final author
review):
  - in all places where AAAA was added, add the Oxford comma: "a DNS A
record, AAAA record, or CNAME record"
  - section 3.4: missing comma "Using the MI" -> "Using the MI,"

thanx!

--  Kevin J. Ma

On Tue, Sep 24, 2019 at 10:00 AM Ori Finkelman (IETF) <
ori.finkelman.ietf@gmail.com> wrote:

> Hi All,
> This submission fixes the comments from all reviewers, I would like to
> thank all reviewers for taking the time and sharing their comments.
> Please note the diff should be against revision 05 rather than 06 as most
> of the changes were submitted in 06.
>
>
> Here is the full list of comments that were fixed in this version:
> =====================================================================
>
> ****************************************************************
> Reviewer: Barry Leiba (AD)
>
> 1. Please use the new BCP 14 boilerplate and references: see RFC 8174.
> >> fixed
>
> 2. Abstract vs Introduction:  The sentence about the SVA seems out of
> place in the Abstract, and is oddly missing from the Introduction.  I
> would add the first two sentences of the Abstract to the Introduction.
> Then remove the first sentence from the Abstract and also remove “In
> that aspect,” from the second sentence.
>
> >> fixed
>
> 3. RFC 6707 defines necessary terminology, so it probably should be
> normative.  I will note a downref in the last-call notice in
> anticipation of that.
> >> fixed
>
>
> ***************************************************
> Reviewer: Dan Romascanu (Genart)
>
> 1. Several non-obvious acronyms are not expanded: FCI, FQDN
> >> fixed and removed the ones not used
> 2. Section 3 - typo in the first paragraph '...the uCDN MUST be differnet
> ...'
> >> fixed
>
> *************************************************
> Reviewer: Zitao Wang (Opsdir)
>
> #1: There are a lot of abbreviations that are not provided with
> explanations or
> citations, such as uCDN, dCDN, CFI, etc.
> >> fixed and remove the ones not necessary
>
> #2: The example of of a Redirect Target capability object serialization,
> is it
> encoded as json? Please present its encoding format.
> >> fixed
>
> #3: In section 2.1, the "Mandatory-to-Specify" attributes of dns-target and
> http-target, it describes that "No, but at least one of dns-target or
> http-target MUST be present and non-empty." I wonder whether there should
> be a
> detection mechanism. For example, if the requirements are not met, an error
> message will be returned. And if there are existing mechanisms, please
> briefly
> introduce them.
>
> >> That one is a great catch, thanks. I have changed it so it is not an
> error anymore. Instead we have defined a default behavior for the case
> it is not present or empty, see the fixed draft.
>
> ******************************************************************
> Reviewer: Linda Dunbar (Secdir)
>
> The terminology RR (Request Router) and CP (Content Provider) specified
> by the
> Terminology are not used for the entire document. I assume that RR would
> be the
> one request content, isn't? is RR same as Client?  Is RR part of
> Downstream CDN
> Provider? is the CP same as Downstream CDN provider or Upstream CDN
> Provider?
>
> >> In the new version RR appears in a few locations. I have added more
> explanations and references to the relevant CDNI docs where it was defined.
>
> who issued the Redirect Target?
>
> It would be good for the document to clearly specify the relationship of
> all
> the entities, such as who makes request and who respond, and who use the
> Redirect Target capability, etc.
>
> >> we have added drawings of sequences that explain it all, I hope it will
> be clearer now.
>
> *******************************************************************
> Reviewer: Michael Tüxen (Tsvart)
>
> To improve readability, you might want to
> * resolve acronyms on first occurence like CDN, CDNI,...
> >> fixed
> * Remove section 1.1, since the introduced abbreviations are not used in
> the text.
> >> fixed
> * add a graphical representation of the involved nodes and the messages
> being exchanged between them
> >> Added sequence diagrams sections for both extensions.
>
> Typos:
> * Section 3: the uCDN provide a fallback -> the uCDN provides a fallback
> * Section 6: Nir B.  Sopher -> Nir B. Sopher (no double space after period)
> * Section 6: Kevin J.  Ma -> Kevin J. Ma (no double space after period)
> >> fixed
>
> *******************************************************************
> Reviewer: Ben Niven-Jenkins (CDNI)
>
> Is there a reason that IPv6 addresses (AAAA records) are excluded from
> being allowed as DnsTargets, or is this an oversight?
>
> >> fixed. references to ipv6 and AAAA record were added in the relevant
> places.
>
> *******************************************************************
>
> Thanks,
> Ori
>
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Tue, Sep 24, 2019 at 4:49 PM
> Subject: [CDNi] I-D Action:
> draft-ietf-cdni-request-routing-extensions-07.txt
> To: <i-d-announce@ietf.org>
> Cc: <cdni@ietf.org>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Content Delivery Networks Interconnection
> WG of the IETF.
>
>         Title           : CDNI Request Routing Extensions
>         Authors         : Ori Finkelman
>                           Sanjay Mishra
>         Filename        : draft-ietf-cdni-request-routing-extensions-07.txt
>         Pages           : 17
>         Date            : 2019-09-24
>
> Abstract:
>    Open Caching is a use case of Content Delivery Networks
>    Interconnetion (CDNI) in which the commercial Content Delivery
>    Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer
>    serves as the downstream CDN (dCDN).  The extensions specified in
>    this document to the CDNI Metadata and FCI interfaces are derived
>    from requirements raised by Open Caching but are also applicable to
>    CDNI use cases in general.
>
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-cdni-request-routing-extensions/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-cdni-request-routing-extensions-07
>
> https://datatracker.ietf.org/doc/html/draft-ietf-cdni-request-routing-extensions-07
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-request-routing-extensions-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
>