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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 18 February 2021 02:39 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F203A1F13 for <netconf@ietfa.amsl.com>; Wed, 17 Feb 2021 18:39:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbacTm3xB3-p for <netconf@ietfa.amsl.com>; Wed, 17 Feb 2021 18:39:04 -0800 (PST)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B999F3A1ECB for <netconf@ietf.org>; Wed, 17 Feb 2021 18:39:04 -0800 (PST)
Received: by mail-pg1-x530.google.com with SMTP id o7so244948pgl.1 for <netconf@ietf.org>; Wed, 17 Feb 2021 18:39:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LHHR6gTfej93tkpT7eCLjaPF3JahTjZ+PIY88hfzxjY=; b=rdoYUxtLPi/bQYivRoKhKRBS1tqIv/Zxt/9n8DPXLrA9C8ov+SVZ4mUKQzwb8vsd+m Y4PXAsleXuvX5wlf8jeAUlkmPaa92WxmvWtsuNZDb/5u+a+pnsVyRDoWxt25yW/E2p/+ 305yBWJX1dYHmbngtZNJN5UZLjXj/9u3vxFnMID+PjOBFdYlGC3ZpbsMjk8VC6mKByrm Sk8rUfQ+A4YUhenwig4yfOcmA7cv1Z2ychlWTiVbvHvFVurUu5RoI5q0eAfdf/+yaO9L O/dTKYr6Suo1i1lgUVEHdLvEDTPKbhxhrfJfp4doApO1v0SusPAj3JdNYth69pq5rG0c z6HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LHHR6gTfej93tkpT7eCLjaPF3JahTjZ+PIY88hfzxjY=; b=lE0XbZfsESF1X4ODjpBqWJ92VQl7nZo2UCBkZjDmcPf3TJXmF0lowZPr9KSv32bJv1 r/apyp+kotZJvHCEk1LciaLx3IeSLvrODn73Kki5pSqTpxBHp0AUWRysC2Zp/e62I+QT 7um1pKBNOzZXvSJt2ubanQrRpPg+Rv99Lzv9Zn515qYnCmxS2pSykKHvM38Bts0JkYtM knlF0M4XIvUX9mWYzNhPD8exFnIZ/sw7vjcKYjr3VmMlQQ37K9KyA6OYZJ4afgnFjYyB METQARlslSFN9FiyF9RGGcM+TgKw0vggoeaiKHMM8VhFaLCRczeB2+n10fR0rORX11vd cFFA==
X-Gm-Message-State: AOAM530U+t19JiWwKzftoWDZTP3gZf2YVBD46KB+iQz6bH7ZsgjFyeqc 1vFb8C+xs/wwFEJPUpN7aEg=
X-Google-Smtp-Source: ABdhPJzYQ6Al6I2Z146VErCczUCFRdQdStcB/6gS/nv7h1QRLpNe03nmuJJ9wRzcfn8j5OCGdnyAtQ==
X-Received: by 2002:a05:6a00:2b3:b029:1ec:adc7:645d with SMTP id q19-20020a056a0002b3b02901ecadc7645dmr2301149pfs.30.1613615943984; Wed, 17 Feb 2021 18:39:03 -0800 (PST)
Received: from ?IPv6:2601:647:5600:5020:9559:eaee:bbd7:a39e? ([2601:647:5600:5020:9559:eaee:bbd7:a39e]) by smtp.gmail.com with ESMTPSA id x17sm3802349pfq.132.2021.02.17.18.39.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Feb 2021 18:39:03 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <57300FBC-8FDF-437A-87F5-B54579AFA687@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B5D152C-9200-483E-AE86-BEC10368CF32"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Wed, 17 Feb 2021 18:39:01 -0800
In-Reply-To: <20210204.203944.1533922869570231478.id@4668.se>
Cc: kent+ietf@watsen.net, netconf@ietf.org
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>, Jan Lindblad <jlindbla@cisco.com>
References: <01000177588220b4-e69a027b-360a-4e2b-af1c-e681d9bd881e-000000@email.amazonses.com> <A979E7E5-1F85-4D6D-8560-1321589800B9@yahoo.com> <0100017764e15a93-b0ee5a7e-cf50-436c-be80-9cc488e5f7e4-000000@email.amazonses.com> <20210204.203944.1533922869570231478.id@4668.se>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/7R66z0el2IzYg9gxy7fFIkAl-lg>
Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 02:39:08 -0000

Hi Martin/Jan,

Thanks first of all for doing the review of the document. 

See responses inline.

> On Feb 4, 2021, at 11:39 AM, Martin Björklund <mbj+ietf@4668.se> wrote:
> 
> Hi,
> 
> I have reviewed this document (-07), and I just have some minor
> comments.  The document is well written and easy to understand.
> 
> 
> o  Abstract
> 
>   [...] It also presents an example
>   module for configuration without using the data model defined in RFC
>   8639.
> 
>  Is this such an important example that it should be mentioned in the
>  abstract?  Does this mean that the NETCONF WG doesn't think that the
>  data model defined in RFC 8639 is useful anymore?  Why is a
>  "simpler" module needed?

Good point. Here is the current Abstract.

   This document defines a protocol for sending notifications over
   HTTPS.  YANG modules for configuring publishers are also defined.
   Examples are provided illustrating how to configure various
   publishers.

   This document requires that the publisher is a "server" (e.g., a
   NETCONF or RESTCONF server), but does not assume that the receiver is
   a server.

> 
> 
> o  3.1.  Applicability
> 
>   For publishers using Subscription to YANG Notifications [RFC8639],
>   dynamic discovery of a receiver's supported encoding is necessary
>   only when the "/subscriptions/subscription/encoding" leaf is not
>   configured, per the "encoding" leaf's description statement in the
>   "ietf-subscribed-notification" module.  FIXME: do they need to
>   discover *any* capabilities?
> 
>  Note that the "encoding" leaf has a when expression and is
>  present only if the chosen transport is derived from
>  sn:configurable-encoding.  The "https" transport identity is not
>  derived from sn:configurable-encoding, so the "encoding" leaf will
>  never be present.

Thanks for catching this. We have dropped the applicability section because we choose that the “encoding” leaf not be defined, specifically because we think it is better for operators to rely on dynamic discovery of capabilities over static configuration.

In making some of these changes, we realize that we should put a must statement around the augment statement for "transport-type” that gets evaluated only when the transport-type is https. Do you think you could help us with that must statement?

> 
> 
> 3.2.  Request
> 
>   To learn the capabilities of a receiver, a publisher can issue an
>   HTTPS GET request to the "capabilities" resource under a known path
>   on the receiver
> 
>  I think you should mention what this "known path" is.  After reading
>  the data model in detail I understand how it works, but it would be
>  good with an early explanation (the path is configured per
>  receiver).

We have updated the first paragraph of Section 2 to say:

   The protocol consists of two HTTP-based target resources presented by
   the receiver.  These two resources are sub-paths of a common resource
   that the publisher must know (e.g. specified in its configuration
   data model).


> 
> 
> o  3.3
> 
>     leaf-list receiver-capability {
>       type string {
>         pattern "urn:ietf:capability:https-notif-receiver:*";
>       }
> 
>  What's the point of the "urn:..." prefix if it is required?  It
>  would be simpler to just have the "*"-part in the registry.
> 
>  But I think a better solution would be
> 
>     leaf-list receiver-capability {
>       type inet:uri;
>     }
> 
>  This would be more extensible.

Another good point. Have updated the example accordingly. 

Also added a statement saying that “The publisher MUST ignore any capabilities that it does not recognize”.

> 
> 
> o  3.4.  Example
> 
>   The publisher can send the following request to learn the receiver
>   capabilities.  In this example, the "Accept" states that the receiver
>   wants to receive notifications in XML but, if not supported, to use
>   JSON encoding.
> 
>  Copy&paste error?  The "Accept" header states that the client wants
>  to get the capabilities as xml, json.

Another good catch. Here is what the paragraph now looks like:

   The publisher can send the following request to learn the receiver
   capabilities.  In this example, the "Accept" states that the receiver
   wants to receive the capabilities response in XML but, if not
   supported, then in JSON.

> 
> 
> o  5.2
> 
>   <CODE BEGINS> file "ietf-subscribed-notif-receivers@2021-02-02.yang"
>   [note: '\' line wrapping for formatting only]
> 
>   module ietf-subscribed-notif-receivers {
> 
>  Remove the "note" line (no "\" is used, and this line should not be
>  part of the <CODE BEGINS>).

Hmm. I do not see the note or a “\” being added to the line anymore.

   <CODE BEGINS> file "ietf-subscribed-notif-receivers@2021-02-17.yang"
   module ietf-subscribed-notif-receivers {


> 
> o  6.2
> 
>  As above, but also remove the  "\" in the module; they are not
>  needed.

Ditto.

> 
> 
> o 6.2
> 
>  feature receiver-identity {
>    description
>      "Indicates if the server supports filtering notifications
> 
>  s/if/that/

Fixed.

> 
> 
> 
> o  Appendix
> 
>  The examples would be easier to read if the "\"-line wrapping
>  convention was used only when absolutely needed.  For example, this
>  doesn't look right:
> 
>                  <cleartext-password>my-password</cleartext-password\
>> 

That line now shows up as follows.

                     <cleartext-password>my-password</cleartext-passwor\
   d>

> 
>  And this:
> 
>  <subscriptions xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-n\
> otifications">
> 
>  would be easier on the eye as:
> 
>  <subscriptions
>    xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications">

Tried that, and now the “\” character appears as follows.

     <subscriptions
         xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio\
   ns”>

Thanks.

> 
> 
> 
> 
> 
> /martin
> 
> 
> 
> 
> Kent Watsen <kent+ietf@watsen.net> wrote:
>> NETCONF,
>> 
>>      The just posted -07 addresses issues raised thus far.
>>      https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07 <https://tools.ietf.org/html/draft-ietf-netconf-https-notif-07>
>> 
>> Henning, Eric, Reshad,
>> 
>>      Please re-review as your comments are important to us.
>> 
>> Everyone else,
>> 
>>      The hasn’t been many reviews as yet.  Please review this
>>      version, as it is significantly better (ready for publication?)
>>      than the prevision version.
>> 
>> K.
>> 
>> 
>> 
>>> On Feb 1, 2021, at 11:33 AM, Reshad Rahman <reshad@yahoo.com> wrote:
>>> 
>>> Good with me.
>>> 
>>> Regards,
>>> Reshad.
>>> 
>>> From: Kent Watsen <kent+ietf@watsen.net>
>>> Date: Sunday, January 31, 2021 at 7:54 AM
>>> To: Reshad Rahman <reshad@yahoo.com>
>>> Cc: "netconf@ietf.org" <netconf@ietf.org>rg>, "draft-ietf-netconf-https-notif@ietf.org" <draft-ietf-netconf-https-notif@ietf.org>
>>> Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
>>> 
>>> 
>>>> 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.
>>> 
>>> 
>>> 
>>>> 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.";
>>>>            }
>>> 
>>> 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?
>>> 
>>> 
>>>> Formatting nit:
>>>>           Trust anchors (i.e. CA certs) that are used to authenticat\
>>>> e
>>> 
>>> 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.
>> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com