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

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Wed, 01 May 2019 06:15:09 -0700

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

---

From: <[email-masked]>
Date: Thu, 2 May 2019 05:25:23 +0000

Hi Alexey, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Alexey Melnikov via Datatracker [mailto:[email-masked]]
> Envoyé : mercredi 1 mai 2019 15:15
> À : The IESG
> Cc : [email-masked]; Roman Danyliw; dots-
> [email-masked]; [email-masked]; [email-masked]
> Objet : Alexey Melnikov's Discuss on draft-ietf-dots-data-channel-28: (with
> DISCUSS and COMMENT)
> 

[Med] Thank you. 

> is not correct.

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

 It is either "status-line" or "header field".
> The same issue is pretty much in every example in your document.

[Med] Fixed. 

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

[Med] We don't have any restriction. 

> are missing the empty line before the payload.

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

> Again, drop "header" after status-line. 

[Med] Fixed. Thanks.

For clarity you can say "the HTTP

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 2 May 2019 13:05:50 +0000

> -----Original Message-----
> From: Dots <[email-masked]> On Behalf Of
> [email-masked]
> Sent: Thursday, May 2, 2019 10:55 AM
> To: Alexey Melnikov <[email-masked]>; The IESG <[email-masked]>
> Cc: Roman Danyliw <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [Dots] Alexey Melnikov's Discuss on draft-ietf-dots-data-
> channel-28: (with DISCUSS and COMMENT)
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Hi Alexey,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Alexey Melnikov via Datatracker [mailto:[email-masked]] Envoyé
> > : mercredi 1 mai 2019 15:15 À : The IESG Cc :
> > [email-masked]; Roman Danyliw; dots-
> > [email-masked]; [email-masked]; [email-masked] Objet : Alexey Melnikov's
> > Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)
> >
> > 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
> > I have a small set of issues that I would like to be fixed before
> > recommending approval of this document.
> >
> > 1) In 3.1:
> >
> > If I misundestood and this is a part of payload itself, then your
> > document should have an example.
> >
> > Your example is syntactically invalid, as you need an empty line after
> > the Content-Type header field (before the payload).
> >

SRV-ID does not make sense for a DOTS client certificate, DOTS server can use the dNSName type in the DOTS client certificate.

Cheers,
-Tiru

> > This is not a valid response. Firstly, the status-line is missing
> > Secondly, you are missing the empty line before the payload.
> 
> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots