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

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

On 29/04/2016, 10:53, "EXT Alexey Melnikov" <[e-mail]> wrote:

[snip]

>> >In 4.6: a normative reference that defines AS is needed here.
>> 
>> Would RFC 1930 be the right choice?
>
>I think so. Are you using 16bit or 32bit version?

I don't think it matters. AS number was chosen as a unique identifier for the network, it's not being used by CI/T or any of the other CDNI protocols as an AS number.



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

The Security Considerations text has been the subject of a lot of wordsmithing and rounds of security review in several CDNI drafts, CI/T is aligned with those other drafts (logging, redirection, metadata). I think the feeling is that CDNI drafts are not the place to try to define TLS best practice, which changes over time and is discussed authoritatively elsewhere by people who know what they're talking about (!).

So, like the other CDNI drafts, as well as the "including authentication of the remote end" para above the draft currently says:

    When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
    followed.

Does that cover it for you? If not, what specifics are you thinking about?


[snip]


>> >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.
>
>I think it might be useful to stick +json at the end (and update all
>examples to match).

Ok.


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

Ah, yes I see, thank you - looks like I've pasted in the wrong example. I'll find the right one while I'm "+json"-ing them.


>
>Best Regards,
>Alexey