Re: [CDNi] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-13: (with COMMENT)

["Murray, Rob (Nokia - GB)" <[e-mail]>]

Hi Alexey - thank you for the review. Responses inline...

Rob.


On 28/04/2016, 17:32, "CDNi on behalf of EXT Alexey Melnikov" <[e-mail] on behalf of [e-mail]> wrote:

>Alexey Melnikov has entered the following ballot position for
>draft-ietf-cdni-control-triggers-13: Yes
>
>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-control-triggers/
>
>
>
>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>Below is my AD review. I am sorry if my comments are a bit cryptic, feel
>free to ask for clarifying questions.
>
>First mention of HTTP, its methods or response codes needs to have a
>reference to RFC 7230. This applies to section 2.
>
>Similarly, the first reference to URL should clarify that you only mean
>http/https URLs and use RFC 7230 as well.

How about I add this paragraph to section 2? ...

  The CI/T interface builds on top of HTTP/1.1 [RFC7230]. References
  to URL in this document relate to http/https URIs, as defined in
  [RFC7230] section 2.7.


>In Section 4 you are referencing generic HTTP without any version number
>and saying that any HTTP feature can be used. I think you really need to
>have at least a version number here, because I don't think you mean
>HTTP/2.0. Adding the above references probably makes this comment
>unimportant.

I don't think there's any reason CI/T wouldn't work under HTTP/2.0 but
yes, for interop we need to pick a version - and I think we've all been
assuming HTTP/1.1. As you say, the reference should cover it.


>In 4.1, at the bottom of page 10: "dCDN SHOULD track and report..." -
>how?

I guess you mean how should it report, not how should it track (which
is down to the implementation of course).

Section 2 already says:

   The CI/T interface is a web service offered by the dCDN.  It allows
   CI/T commands to be issued, and triggered activity to be tracked.
   When the dCDN accepts a CI/T Command it creates a resource describing
   status of the triggered activity, a Trigger Status Resource.  The
   uCDN can poll Trigger Status Resources to monitor progress.

So I could change section 4.1's sentence:

   The dCDN SHOULD track and report on progress of CI/T Trigger
   Commands. 

To:

   The dCDN SHOULD track and report on progress of CI/T Trigger
   Commands using a Trigger Status Resource (Section 5.1.2).


>In 4.6: a normative reference that defines AS is needed here.

Would RFC 1930 be the right choice?


>How is HTTP Authentication done?

Sorry, not sure what the context is. Section 8.1 says:

   TLS MUST be used by the server-side (dCDN) and the client-side (uCDN)
   of the CI/T interface, including authentication of the remote end [...]

(But I think I'm missing your point?)


>Does CBOR-CDDL reference needs to be Normative? While the Appendix is
>Informative, CBOR-CDDL need to be understood in order to interpret it.

I don't think so. It's an informative section, so if the reader wants to
be informed they can read the informative reference. It doesn't affect
the normative spec of the interface.

Making the JSON formalisation and its ref non-normative was the outcome
of discussion on the list, following Barry's AD review...

  https://mailarchive.ietf.org/arch/msg/cdni/c_UwFN-pCAJ9GyE_0G-i_nR6mAI

Also, if I was implementing CI/T from the draft, I think I'd find it handy
with just an intuitive understanding of the notation.


>In 5.2.2: is the list of trigger types extensible? If yes, does it need
>an IANA registry?
>
>Similar: 5.2.7 (error types). I suspect the answer is yes here.

Not sure on either of those, especially the error types. Any views from
folks on the list?


>Media type: should it have +json suffix? Is the currently defined media
>type deployed?

Not sure, I thought it was JSON by-definition, but happy to be corrected.
I don't think it's deployed.


>On page 36 - should the URL include "pending", not "complete" (as per the
>description before this and the previous request/response).

That's section 6.2.5, the example where "/triggers/0" gets deleted?

I think "complete" is right, section 6.2.4 follows it through
"pending" to "complete" (on page 35).


>_______________________________________________
>CDNi mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/cdni