Re: [Dots] Alexey Melnikov's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

[<[e-mail]>]

Hi Alexey, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alexey Melnikov via Datatracker [mailto:[e-mail]]
> Envoyé : mercredi 1 mai 2019 15:15
> À : The IESG
> Cc : [e-mail]; Roman Danyliw; dots-
> [e-mail]; [e-mail]; [e-mail]
> Objet : Alexey Melnikov's Discuss on draft-ietf-dots-data-channel-28: (with
> DISCUSS and COMMENT)
> 
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-dots-data-channel-28: Discuss
> 
> 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-dots-data-channel/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thank you for a well written document. It was a pleasure to read.
> 

[Med] Thank you. 

> I have a small set of issues that I would like to be fixed before
> recommending
> approval of this document.
> 
> 1) In 3.1:
> 
>    DOTS data channel configuration information as well as state
>    information can be retrieved with the GET method.  An HTTP status-
>    line header field is returned for each request to report success or
> 
> I know this text is copied from RFC 8040, but "status-line header field"
> is not correct.

[Med] Fully agree. I deleted "header field".

 It is either "status-line" or "header field".
> (A header field always has ":" in it and HTTP status-line doesn't).
> I think you meant the former.
> 
> If I misundestood and this is a part of payload itself, then your document
> should have an example.
> 
>    failure for RESTCONF operations (Section 5.4 of [RFC8040]).  The
>    "error-tag" provides more information about encountered errors
>    (Section 7 of [RFC8040]).
> 
> 2)
> 
> 5.1.  Registering DOTS Clients
> 
>    In order to make use of DOTS data channel, a DOTS client MUST
>    register to its DOTS server(s) by creating a DOTS client ('dots-
>    client') resource.  To that aim, DOTS clients SHOULD send a POST
>    request (shown in Figure 11).
> 
>     POST /restconf/data/ietf-dots-data-channel:dots-data HTTP/1.1
>     Host: {host}:{port}
>     Content-Type: application/yang-data+json
>     {
>       "ietf-dots-data-channel:dots-client": [
>         {
>           "cuid": "string"
>         }
>       ]
>     }
> 
> Your example is syntactically invalid, as you need an empty line after the
> Content-Type header field (before the payload).
> 
> The same issue is pretty much in every example in your document.

[Med] Fixed. 

> 
> 3) In the same section 5.1:
> 
>    DOTS servers can identify the DOTS client domain using the 'cdid'
>    parameter or using the client's DNS name specified in the Subject
>    Alternative Name extension's dNSName type or SRV-ID in the client
>    certificate.
> 
> SRV-ID needs a Normative reference to RFC 6125.

[Med] Done.

> 
> Also, can you give an example of how SRV-ID is going to be used?

[Med] We will discuss this in the signal channel draft. 

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> In 6.1:
> 
>    name:  Name of the alias.
> 
>       This is a mandatory attribute.
> 
> Are there any restrictions on which characters can appear in aliases?

[Med] We don't have any restriction. 

> 
> In 7.1 (on page 49):
> 
>     Content-Type: application/yang-data+json
>     {
>      "ietf-dots-data-channel:capabilities": {
> 
> This is not a valid response. Firstly, the status-line is missing Secondly,
> you
> are missing the empty line before the payload.

[Med] This a response message body. Clarified this in the text. 

> 
> In 7.2 (on page 52):
> 
>    The DOTS server indicates the result of processing the POST request
>    using the status-line header.
> 
> Again, drop "header" after status-line. 

[Med] Fixed. Thanks.

For clarity you can say "the HTTP
> status-line".
>