Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17

Kent Watsen <kent+ietf@watsen.net> Wed, 01 May 2019 22:39 UTC

Return-Path: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@amazonses.watsen.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9109120025; Wed, 1 May 2019 15:39:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 trsbGbmu6G_o; Wed, 1 May 2019 15:39:13 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ACAD120019; Wed, 1 May 2019 15:39:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1556750352; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=V5KtbbfevQ1KLEhpE4cJ8IG5qHOTzaOnf3eukJTczVA=; b=PmK8qQjAA0n+3GR3HDIYnHennmx2Ky79Li9t0D49zvCFTf2vesOW1eJScyTJNIgs WGmxiPZkwtc4qMp4BX4FgNpJ/39+/aUUovOQ5m5ZAssCUEuMncIZodLzezORPBQORr0 WYWnD8OACBkanmzTPYf0p6PH14X11fh+4d/Dqq30=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_70111C22-DA5F-4E78-A41B-CD6A03381CB3"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 01 May 2019 22:39:11 +0000
In-Reply-To: <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" <draft-ietf-netconf-netconf-event-notifications.all@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, Dhruv Dhody <dhruv.dhody@huawei.com>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
To: "Eric Voit (evoit)" <evoit@cisco.com>
References: <CAB75xn4HiqYqeWu2tiOsfDwU4ePc+-6ym+4EpowqZ-YMgkRRMA@mail.gmail.com> <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-SES-Outgoing: 2019.05.01-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/y6TYAlt75JS5LOruPQQdXcXUMOg>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 May 2019 22:39:17 -0000


> On Apr 30, 2019, at 1:44 PM, Eric Voit (evoit) <evoit@cisco.com> wrote:
> 
> Hi Dhruv,
> Hi Kent,
> 
> Thanks very much for the comments Dhruv.  Thoughts in-line, with one question to Kent...
> 
>> From: Dhruv Dhody, April 30, 2019 12:53 AM
>> 
>> Hello,
>> 
>> I have been selected as the Routing Directorate reviewer for this draft. The
>> Routing Directorate seeks to review all routing or routing-related drafts as they
>> pass through IETF last call and IESG review, and sometimes on special request.
>> The purpose of the review is to provide assistance to the Routing ADs. For more
>> information about the Routing Directorate, please see
>> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>> 
>> Although these comments are primarily for the use of the Routing ADs, it would
>> be helpful if you could consider them along with any other IETF Last Call
>> comments that you receive, and strive to resolve them through discussion or by
>> updating the draft.
>> 
>> Document: draft-ietf-netconf-netconf-event-notifications-17
>> Reviewer: Dhruv Dhody
>> Review Date: 2019-04-29
>> IETF LC End Date: 2019-04-12
>> Intended Status: Standards Track
>> 
>> Summary:
>> --------
>> I have some minor concerns about this document that I think should be resolved
>> before publication.
>> 
>> Comments:
>> ---------
>> This document provides a binding for events streamed over the NETCONF for
>> dynamic subscriptions. This is a companion document to draft-ietf-netconf-
>> subscribed-notifications and this capability for RESTCONF is defined in draft-ietf-
>> netconf-restconf-notif.
>> 
>> The document is overall well written, it makes an assumption that the reader is
>> well versed in this area and thus sparse in providing details in the Introduction
>> section. The appendix provides good examples.
>> 
>> I don't see any Routing Yang model specific issue.
>> 
>> Major Issues:
>> -------------
>> Note - An IETF process issue, but worth handling right away.
>> 
>> Section 11 says -
>> 
>> 11.  Notes to the RFC Editor
>> 
>>   This section can be removed by the RFC editor after the requests have
>>   been performed.
>> 
>> It further says -
>> 
>>   RFC 6241 needs to be updated based on the needs of this draft.
>>   RFC-6241 section 1.2 bullet "(2)" targets RFC-5277 (actually it
>>   identifies RFC 5717, but that was an error fixed after RFC
>>   publication).  Anyway the current phrasing in RFC-5277 says that a
>>   notification message can only be sent after a successful "create-
>>   subscription".  Therefore the reference text must be modified to also
>>   allow notification messages be sent after a successful "establish-
>>   subscription".  Proposed text for bullet (2) of RFC-6241 would be:
>> 
>>     (2)  The Messages layer provides a simple, transport-independent
>>          framing mechanism for encoding RPCs and notifications.
>>          Section 4 documents the RPC messages, [RFC5277] documents
>>          Notifications sent as a result of a <create-subscription> RPC,
>>          and [RFC xxxx] documents Notifications sent as a result of
>>          an <establish-subscription> RPC.
>> 
>>      (where xxxx is replaced with this RFC number)
>> 
>> I am not sure if this is correct. I don't think RFC editor can do the action you are
>> asking them to do on their own. They would need an errata (which is not correct
>> here) or another document that updates RFC 6241. In my view this document
>> should just update RFC 6241 (and mark that in this document's
>> header) and do necessary text changes to reflect that.
> 
> I am happy to follow whatever process is cleanest.   
> 
> Kent, are you comfortable with this document directly revising  wording of RFC-6241 section 1.2 bullet "(2)" above?    If yes, it would be great to have your thoughts on what needs to go into this document.   Especially as RFC-6241 section 1.2 bullet "(2)" already had a fix applied against it. 


Dhruv is correct, the RFC Editor cannot make the requested change, and an Errata is also not correct, as there is nothing wrong with the way that RFC 6241 was written at the time it was written.

To answer the question, if this draft is to "update" RFC 6241, the steps are 1) declare the update in the draft's header (see Section 2.33.10 of RFC 7749), 2) so so in the Abstract, and 3) have a new section (either before of after the current Section 3 called "Update to RFC 6241" that describes the desired modification.

However, it is unclear if an "update" is appropriate either, given that the "update" is informative in nature and, while it is true that this document cannot be used without RFC 6241, that is also true for so many documents that don't update RFC 6241.

From now obsolete RFC 2223 (I couldn't find a current reference):

   Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

and from expired draft-rfc-editor-rfc2223bis-08:

         Updates

            Specifies an earlier document whose contents are modified or
            augmented by the new document.  The new document cannot be
            used alone, it can only be used in conjunction with the
            earlier document.

Is an "update" overreaching?

Another option is to not update RFC 6241 and instead just mention it, similar to what was done here: https://tools.ietf.org/html/rfc8071#section-1.4 <https://tools.ietf.org/html/rfc8071#section-1.4>.   Note that RFC 8071 originally "updated" RFC 4253, but Benoit (AD at the time) recommended downgrading it to what it is now.


A couple more thoughts:

1) if an update is needed, would it be better coming from draft-ietf-netconf-subscribed-notifications, which defines the "establish-subscription" RPC?

2) whatever the outcome of this discussion, it seems that a similar outcome should be applied to draft-ietf-netconf-restconf-notif and its relation to RFC 8040.


[also see my comment below]



>> Minor Issues:
>> -------------
>> (1) Abstract & Introduction, It is not clear what does the 'binding' mean and who
>> are the parties to this binding? If this is the document that mentions 'binding'
>> first, so please add some more clarifying text.
>> 
>> (2) Section 3, since you use MUST in the error handling, isn't it better to use
>> normative in below sentence as well -
>> OLD:
>>                                                       However a single
>>   NETCONF transport session cannot support both this specification and
>>   a subscription established by [RFC5277]'s "create-subscription" RPC.
>> NEW:
>>                                                       However a single
>>   NETCONF transport session MUST NOT support both this specification and
>>   a subscription established by [RFC5277]'s "create-subscription" RPC.
> 
> Makes sense.  I have made the change, and will post the update when the "Major issue" from above is resolved.
> 
>> (3) Section 6, You have -
>> 
>>   And per [RFC5277]'s "eventTime" object definition, the
>>   "eventTime" MUST be populated with the event occurrence time.
>> 
>> Is this a new requirement, or just re-stating RFC5277? RFC5277 says -
>> 
>>      eventTime
>> 
>>         The time the event was generated by the event source.  This
>>         parameter is of type dateTime and compliant to [RFC3339].
>>         Implementations must support time zones.
>> 
>>      Also contains notification-specific tagged content, if any.  With
>>      the exception of <eventTime>, the content of the notification is
>>      beyond the scope of this document.
>> 
>> Maybe remove MUST? If you are trying to refine the text from RFC5277, then
>> please re-word.
> 
> You are correct.  The MUST is redundant with RFC-5277's XSD definition.   Therefore I have removed "MUST be".
> 
>> Nits:
>> -----
>> (1) Abstract
>> 
>>   RFC Editor note: please replace the four references to pre-RFC
>>   normative drafts with the actual assigned RFC numbers.
>> 
>> I see two drafts in the reference section. Why four?
> 
> You are correct.  I removed the word "four".  
> 
>> Also, since those two are normative references, these would be published as a
>> cluster as a part of normal RFC editor processing right?
> 
> Yes.
> 
>> (2) Regarding NETCONF, the RFC editor says [1] -
>> 
>> NETCONF    - Network Configuration Protocol (NETCONF)
>>               [Not typically expanded in titles, but expand in abstract]
>> 
>> Please expand.
> 
> Done.
> 
>> (3) s/[I-D.draft-ietf-netconf-subscribed-notifications]
>>     /[I-D.ietf-netconf-subscribed-notifications]
> 
> Actually I changed the [I-D.ietf-netconf-yang-push]  to  [I-D.draft-ietf-netconf-yang-push]
> 
> This makes it consistent across all four drafts.


The issue isn't consistency so much as meeting expectations, per `xml2rfc`, the document should have something like the following in the References section, which then auto-expands to the correct reference text, as well as defining the anchor "I-D.ietf-netconf-subscribed-notifications":

        <?rfc include="reference.I-D.ietf-netconf-subscribed-notifications"?>



Kent // shepherd


> 
> Thanks again!
> Eric
> 
>> Just so that you have the same style of draft reference in the document. I get
>> that it would be replaced with a RFC number anyways :)
>> 
>> [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt <https://www.rfc-editor.org/materials/abbrev.expansion.txt>
>> 
>> Thanks!
>> Dhruv