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

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 28 Apr 2016 09:32:51 -0700

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.

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.

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

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

How is HTTP Authentication done?

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

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.

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

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

---

From: "Murray, Rob (Nokia - GB)" <[email-masked]>
Date: Thu, 28 Apr 2016 20:32:26 +0000

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

Rob.

>https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/

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.

>HTTP/2.0. Adding the above references probably makes this comment

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..." -

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?)

>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.

>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

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

>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 29 Apr 2016 10:53:39 +0100

Hi Rob,

On Thu, Apr 28, 2016, at 09:32 PM, Murray, Rob (Nokia - GB) wrote:
> On 28/04/2016, 17:32, "CDNi on behalf of EXT Alexey Melnikov"
> <[email-masked] on behalf of [email-masked]> wrote:

 [snip]

>   to URL in this document relate to http/https URIs, as defined in

Looks good to me.

> assuming HTTP/1.1. As you say, the reference should cover it.

Right.

>    Commands using a Trigger Status Resource (Section 5.1.2).

Yes, this is much better. Thank you.

> Would RFC 1930 be the right choice?

I think so. Are you using 16bit or 32bit version?

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

I think this section needs more details on how client and server
identities are verified. In particular what should the client side look
for in server certificates?

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

Ok. I think if CDDL nevers gets published, there is still a possibility
of the appendix becoming pointless, but I can live with this.

> with just an intuitive understanding of the notation.

 [snip]

> I don't think it's deployed.

I think it might be useful to stick +json at the end (and update all
examples to match).

> "pending" to "complete" (on page 35).

At the bottom of page 34 there is the following text:

When the CI/T Trigger Command is complete, the contents of the
 filtered collections will be updated along with their Entity Tags.
 For example, when the two example CI/T Trigger Commands are complete,
 the collections of pending and complete Trigger Status Resources
 might look like:

after that there are 2 examples on pages 35 and 36, both with URI
"/triggers/complete". I think one of the should be " /triggers/pending,
I think it is the one on page 35.

Best Regards,
Alexey