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

[Alexey Melnikov via Datatracker <[e-mail]>]

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.

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

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.

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


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

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.

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. For clarity you can say "the HTTP
status-line".