Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06

From: Reshad Rahman <[email-masked]>
Date: Sat, 30 Jan 2021 17:18:29 -0500

Hi,

I've reviewed this document and I think the document will be ready once the changes planned by the authors (regarding notification-messages) are made.

I have a question on the following YANG description. Section 4.1 mentions 'path-absolute' for the URI but the description below says "Relative URI...". Should this description be clarified/corrected or am I missing something?

             augment "transport/tls/tls/http-client-parameters" {
               leaf path {
                 type string;
                 description
                   "Relative URI to the target resource.";
               }
               description
                 "Augmentation to add a path to the target resource.";
             }

Formatting nit:
            Trust anchors (i.e. CA certs) that are used to authenticat\
  e

Regards,
Reshad.

On 2021-01-22, 6:27 AM, "netconf on behalf of Rob Wilton (rwilton)" <[email-masked] on behalf of rwilton=[email-masked]> wrote:

    Just to bump this thread as a reminder that the WGLC finishes in 6 days.

    Please make time to review this document.

    Regards,
    Rob

    > -----Original Message-----
    > From: netconf <[email-masked]> On Behalf Of Rob Wilton (rwilton)
    > Sent: 14 January 2021 13:12
    > To: [email-masked]; [email-masked]
    > Subject: [netconf] WGLC: draft-ietf-netconf-https-notif-06
    > 
    > This message begins a two-week WGLC for draft-ietf-netconf-https-notif-06
    > ending on Jan 28.  Here is a direct link to the HTML version of the draft:
    > 
    > 	https://tools.ietf.org/html/draft-ietf-netconf-https-notif-06
    > 
    > Positive comments, e.g., "I've reviewed this document and believe it is
    > ready for publication", are welcome!  This is useful and important, even
    > from authors.  Objections, concerns, and suggestions are also welcomed at
    > this time.
    > 
    > Please note, the reason that I am making this request rather than the
    > WG chairs is because both chairs are listed as authors on this document.
    > 
    > Thank you,
    > Rob Wilton, OPS AD
    > 
    > _______________________________________________
    > netconf mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/netconf

    _______________________________________________
    netconf mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/netconf

---

From: Kent Watsen <[email-masked]>
Date: Sun, 31 Jan 2021 12:54:19 +0000

> I've reviewed this document and I think the document will be ready once the changes planned by the authors (regarding notification-messages) are made.

Thanks, but a couple more problems:

1) the URLs are bad.  Specifically, the example in the “Learning Receiver Capabilities” section uses a nonsensical URL (‘/‘).   The authors propose to instead use a sub-resource to the user-configured “path” (e.g., GET /some/path/capabilities) and move the POST URL to another sub-resource (e.g., /some/path/relay-notification).  [see below for more on this]

2) the media-types are bad: “application/yang-data+[xml/json]” is used for notifications, which is wrong since they are not YANG-defined, and the custom media-types for capabilities (application/ietf-https-notif-cap+[xml/json]) is a way overkill.  The authors propose to use “application/[xml/json]” for both cases.

>                 "Augmentation to add a path to the target resource.";

Agreed.  How about this?

        leaf path {
          type string;
          mandatory true;
          description
            "URI prefix to the target resources.  Under this
             path the receiver must support both the 'capabilities'
             and 'relay-notification' resource targets, as described
             in RFC XXXX.";
        }

So, if path==“/som/path”, capability-discovery would be to "/some/path/capabilities” and notifications would be sent to “/some/path/relay-notification”.

Thoughts?

>            Trust anchors (i.e. CA certs) that are used to authenticat\

Fixed, but the other example cannot be fixed because the “xmlns” strings alone are too long, and XML doesn’t internally support folding, and the “string” type doesn’t allows for whitespace (include ‘\n’) both at the beginning and end of strings (recall my request for rfc6991-bis to define a “token” type that would enable the parser to discard any found, so our examples could more often be manually-folded).

K.