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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 18 February 2021 22:17 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 ACB433A191B for <netconf@ietfa.amsl.com>; Thu, 18 Feb 2021 14:17:31 -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 RPU5xAhKR6E3 for <netconf@ietfa.amsl.com>; Thu, 18 Feb 2021 14:17:29 -0800 (PST)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 90E963A1919 for <netconf@ietf.org>; Thu, 18 Feb 2021 14:17:29 -0800 (PST)
Received: by mail-pj1-x1035.google.com with SMTP id gx20so2557531pjb.1 for <netconf@ietf.org>; Thu, 18 Feb 2021 14:17:29 -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=NFXhSntL5RYN1kx4nBwv+m60EFtwpeu5UTFboi3McPU=; b=Gq9+sm8Kl1Fnnb868RKRw7Z4D4QyuUzL1+7ho6nYZHybr6VQS/ZUiRbMFH/5aqPF3z kC7x/KvmD6dUTMqK6HEAdQNHPiGcX3anPdRtfaWODjGACl05qKMXHRDFzYnoWy9SM1Hx O8c1USWFRr9zI6vLE9g2EGWHf4xnvJKKyxEhei0o/ycFHmYqTdoccF1R/o7VxXPYRQWO RSDXM3sab7nbyP8I95pdndg0At+7llu6p+7JpjhBQ15l1vxIFWPXXmUZR7MNTy2/LkJb Tq+8h/1qit2IYSndNXO6tt/SiwN/zpR08JIgN82xTHSAnRhlNO/MU6wCqoBRlP8gk26I z9SA==
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=NFXhSntL5RYN1kx4nBwv+m60EFtwpeu5UTFboi3McPU=; b=LmiiNIldV2Yh3BLpWXrucz60mjv6j3c+WDxco97n0+iRcqCYOOVFiUBrVYB5tV/e3P 9xmK5K5LPhLCBKX20DC+CwPWbTKDvQJ2v9VxpbZcPqq8gB0qj5FGBvbX2girkrZRjgbp 9OYdQ8yPYvaIGQnqDTV0sjkezR4ksaYzQ+edyn+sW7VHZtCzUvJqZGTGYSkSTb0MC4sr uG0HTIgvwciqYUN3F6s4ZANbdtRCCsjTQ5pKU8d1rug72TVo2dNxcmWrFU2u0wPfmu+9 NaRj9CgfmC3n2NvfZ1TJZsK9FN2jKR+xwYrhrKPNr1Jdy8k4FvpQzeuwfyy4/WrV6eDu nGTQ==
X-Gm-Message-State: AOAM530WeMBgsYfliZnAy247HzpM7WgTVS3apBg1St0bHVQjXTX2nVsJ 1NY5SxGQJpeNBGqREQEHvXk=
X-Google-Smtp-Source: ABdhPJxhSCTQkZBqrwcID1PGa33NBhSkYR6Q5H1kLnuzmU1tPGbDPEZez9ANgzaqjmE9oI7Wx2gwWA==
X-Received: by 2002:a17:90a:d998:: with SMTP id d24mr5882402pjv.169.1613686649128; Thu, 18 Feb 2021 14:17:29 -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 j34sm6600015pgi.62.2021.02.18.14.17.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Feb 2021 14:17:28 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <6BAA2A61-9E30-43F2-9F94-8D4FCB258009@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6E9140A7-C401-410A-8C6C-4BB0B8B02E2F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Thu, 18 Feb 2021 14:17:27 -0800
In-Reply-To: <cb57b46caf25410dacb1e37b6ce91393@huawei.com>
Cc: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
To: "maqiufang (A)" <maqiufang1@huawei.com>
References: <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6.ref@yahoo.com> <3F58C70C-C0AD-4FBA-9E89-650CC347FEF6@yahoo.com> <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> <cb57b46caf25410dacb1e37b6ce91393@huawei.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/pRaHr7S9T3-bk8Y6EQ4S3j9dENo>
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 22:17:32 -0000

Hi Ma,

See inline with [mj]

> On Feb 3, 2021, at 11:28 PM, maqiufang (A) <maqiufang1@huawei.com> wrote:
> 
> Hi, Kent:
>  
> I have read the latest version and find it more flexible.
> Here comes a few suggestions:
> 1、 You have got a wrong link at the end of section 1.1. It supposed to be Appendix A.2, rather than Section 8.2.

[mj] Corrected.

> 2、 It seems that you are mix-using HTTP and HTTPS somewhere, for example,  "The protocol consists of two HTTP-based target resources presented by the receiver"(Should be “HTTPS-based”, I think).

[mj] Fixed.

> 3、 Section 3.3/4.2: Will the receiver return a HTTP 200/204 definitely? Should we consider some other extreme situations( e.g., not supported/implemented) ? Just my individual opinion.:)

[mj] There is an e-mail from Andy that gets into this topic. Allow us to address your question when we respond to that e-mail.

> 4、 Section 4.3: You should replace "<event-class>fault</fault>" with "<event-class>fault</event-class>".

[mj] Fixed.

Thanks.

>  
> Qiufang Ma
>  
> From: netconf [mailto:netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org>] On Behalf Of Kent Watsen
> Sent: Wednesday, February 3, 2021 6:34 AM
> To: netconf@ietf.org <mailto:netconf@ietf.org>
> Subject: Re: [netconf] WGLC: draft-ietf-netconf-https-notif-06
>  
> 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 <mailto:reshad@yahoo.com>> wrote:
>  
> Good with me.
>  
> Regards,
> Reshad.
>  
> From: Kent Watsen <kent+ietf@watsen.net <mailto:kent+ietf@watsen.net>>
> Date: Sunday, January 31, 2021 at 7:54 AM
> To: Reshad Rahman <reshad@yahoo.com <mailto:reshad@yahoo.com>>
> Cc: "netconf@ietf.org <mailto:netconf@ietf.org>" <netconf@ietf.org <mailto:netconf@ietf.org>>, "draft-ietf-netconf-https-notif@ietf.org <mailto:draft-ietf-netconf-https-notif@ietf.org>" <draft-ietf-netconf-https-notif@ietf.org <mailto: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 <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>
Mahesh & Kent {as co-authors)