Re: [RTG-DIR] [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
"Eric Voit (evoit)" <evoit@cisco.com> Tue, 14 May 2019 15:00 UTC
Return-Path: <evoit@cisco.com>
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 E562D120139; Tue, 14 May 2019 08:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 vh1U3TASQvtS; Tue, 14 May 2019 08:00:09 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E61612013A; Tue, 14 May 2019 07:59:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14106; q=dns/txt; s=iport; t=1557845985; x=1559055585; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xBhrQ00WbNdEEd4CkbWCM0qyYYsDnjaf+x8oK4VBzAA=; b=OERUWC9C+MbutOy5DQBf0AgE1gIMfDt2F5Xuw6g8mPgGN5e5Wzc3J8XV /5lxfheKtjMkIdYu6B+EPYg/fLTZawRCz38H8Ktzzqg/UObPN9DusDRLA RJ6Rx9OkuFB+QqGyEGoub2RxR4czzW7rkbjOsVFO2NWaDEX4H9xGl7IF8 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D7AgC+1tpc/4kNJK1kHAEBAQQBAQcEAQGBZYFnKoE9MCgKhAeVH5pOCQEBAQwBAS8BAYRAAheCBiM4EwEDAQEEAQECAQRtKIVKAQEBAwEjEUMCBQcEAgEIFQECAgIJGgMCAgIwFAEQAgQBDQUIgk9LgXwPrlCBL4oxgQsoi08XgUA/hCM+hEszglCCWASLHgOCO5l9CQKCCZJWI4IUhkwFjQmDIIkUgSKTaAIRFYEwNiGBV3AVgyeQUUExj06BIQEB
X-IronPort-AV: E=Sophos;i="5.60,469,1549929600"; d="scan'208";a="270275950"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 May 2019 14:59:44 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x4EExidI021780 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 May 2019 14:59:44 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 14 May 2019 10:59:43 -0400
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1473.003; Tue, 14 May 2019 10:59:43 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: tom petch <ietfc@btconnect.com>, Dhruv Dhody <dhruv.dhody@huawei.com>, Kent Watsen <kent+ietf@watsen.net>
CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" <draft-ietf-netconf-netconf-event-notifications.all@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
Thread-Index: AQHU/xC8WbWTXSPvekeZmlnK7/xOtqZqyZ/Q
Date: Tue, 14 May 2019 14:59:43 +0000
Message-ID: <23a9e41d7bcb41d7a6b7a9eeb50aaa18@XCH-RTP-013.cisco.com>
References: <CAB75xn4HiqYqeWu2tiOsfDwU4ePc+-6ym+4EpowqZ-YMgkRRMA@mail.gmail.com> <7395d7e5db4b48e1ba582c9c48c29913@XCH-RTP-013.cisco.com> <0100016a758d3dec-7b7a305f-30f6-4234-b66e-d48960cddef6-000000@email.amazonses.com> <1cf686e76a314553842305bc97baeb3d@XCH-RTP-013.cisco.com> <0100016a944613e1-766a1ada-f1a1-44a3-bced-4ed28baa8797-000000@email.amazonses.com> <CAB75xn4vcHcu3pNBCntWjhw9s6RkgspsfWkQuW4AF3=P8v16cw@mail.gmail.com> <e488c7df0d8049b8aed02b3d240ebe35@XCH-RTP-013.cisco.com> <CAB75xn4it5rABU362p6--wECsc2NVvZqu-4Np1ZhLD72DB_s3Q@mail.gmail.com> <e68ea032d2c04a6383f9291080f33256@XCH-RTP-013.cisco.com> <23CE718903A838468A8B325B80962F9B8DA56A70@BLREML503-MBX.china.huawei.com> <5e89a05b0eb6492abee9cedfe3134031@XCH-RTP-013.cisco.com> <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net>
In-Reply-To: <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/5ezBtJ3Mns2uFK-9wwKNGVIU2Sg>
Subject: Re: [RTG-DIR] [netconf] 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: Tue, 14 May 2019 15:00:12 -0000
Hi Tom, > From: tom petch, May 14, 2019 7:48 AM > > Eric > > A quick browse tells me that in the RFC I regularly refer to, 'binding' > is used in over 300 of them but that in all those that I looked at, it is always > binding an element of a set to an element of the same or a different set, where > the sets are similar in nature. Thus ARP binds an IP address to a MAC address or > a bidirectional MPLS LSP binds one unidirectional LSP to another and so one. > > What I do not learn here is what is being bound to what. > > Perhaps > This document specifies the binding of a stream of events which form part of a > dynamic subscription to the NETCONF > protocol [RFC6241]. Dynamic subscriptions are defined in > [I-D.draft-ietf-netconf-subscribed-notifications]. I am assuming that you are referring to the first sentence of the Intro here, as document references are not in abstracts. This text works for me. Any objections anyone? > The crux is "binding ... to ..." which is currently lacking. > > More generally:-( > I do find this I-D hard to understand. I think that the key is that this I-D, more > than any other I can think of, is so dependent on one of its Normative > References, to whit, subscribed notifications; I think that that needs calling out > so I would add "This memo assumes that the reader is familiar with the > terminology and concepts defined in [subscribed-notifications]" As the last sentence in the Intro section, I have added: "This document assumes that the reader is familiar with the terminology and concepts defined in [I-D.draft-ietf-netconf-subscribed-notifications]." > Yes, that is what a Normative Reference means but I find this example so > extreme that I think it needs calling out. Each time in the past six months I have > turned to this I-D (it is the smallest of the very large set of netconf I-Ds:-), I have > given up, eventually working out that first I must master the 80 pages of > subscribed notifications. This may not be so obvious to those involved at Last > Call time. Understood. And it is true that understanding subscribed-notifications is a prerequisite. Eric > Tom Petch > > > ----- Original Message ----- > From: "Eric Voit (evoit)" <evoit@cisco.com> > Sent: Friday, May 10, 2019 7:39 PM > > > > Hi Dhruv, > > Hi Kent, > > > > > From: Dhruv Dhody, May 9, 2019 11:28 PM > > > > > > Hi Eric, > > > > > > > -----Original Message----- > > > > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > > > > Sent: 10 May 2019 02:18 > > > > Hi Dhruv, > > > > > > > > > From: Dhruv Dhody, May 9, 2019 12:03 AM > > > > > > > > > > Hi Eric, > > > > > > > > > > Thanks for the update. I see one minor comment that is not > handled. > > > > > Maybe you missed it? Or you disagree, that some more text is > required? > > > > > > > > > > > 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. > > > > > > > > This is not the first document which mentions 'binding' first. > The > > > > document which does this first is draft-ietf-netconf-subscribed- > > > > notifications. > > > [[Dhruv Dhody]] draft-ietf-netconf-subscribed-notifications says > this in the > > > Introduction - > > > > > > While the functionality defined in this document is transport- > > > agnostic, transports like NETCONF [RFC6241] or RESTCONF [RFC8040] > can > > > be used to configure or dynamically signal subscriptions, and > there > > > are bindings defined for subscribed event record delivery for > NETCONF > > > within [I-D.draft-ietf-netconf-netconf-event-notifications], and > for > > > RESTCONF within [I-D.draft-ietf-netconf-restconf-notif]. > > > > > > I think this is only time binding is used in this context. > > > And now this I-D says - > > > > > > This document provides a binding for events streamed over the > NETCONF > > > protocol [RFC6241] for dynamic subscriptions as defined in > > > [I-D.draft-ietf-netconf-subscribed-notifications]. > > > > > > And you don’t use this term ever again. > > > > > > To me this is bit circular and the term binding is used loosely. And > thus I flagged > > > it. I will let you and Kent decide the right approach. > > > > I really am ok with many options here: > > (a) keep the current text. > > (b) use previous versions of the abstract. > > (c) replace the word binding with some other text. > > > > Getting the right words here nailed down hasn't been from lack of > effort. To give you an idea, below are four previous attempts at the abstract. > > > > From -v5 > > > > This document defines how to transport network subscriptions and > > event messages on top of the Network Configuration protocol > > (NETCONF). This includes the full set of RPCs, subscription state > > changes, and subscribed content needing asynchronous delivery. > > > > > > From -v6 > > > > This document provides a NETCONF binding for > > [I-D.draft-ietf-netconf-subscribed-notifications]. Included are: > > > > o Transport mappings for subscription RPCs, state change > > notifications, and notification messages > > > > o Functionality which must be supported with NETCONF > > > > o Examples in appendices > > > > > > From -v7 > > > > This document provides a NETCONF binding for > > [I-D.draft-ietf-netconf-subscribed-notifications] and > > [I-D.ietf-netconf-yang-push]. Included are: > > > > o transport mappings for subscription RPCs, state change > > notifications, and notification messages, > > o functional requirements, and > > o examples > > > > > > From -v8 > > > > This document provides a NETCONF binding to subscribed > notifications > > and to YANG push. > > > > > > Honestly I like the v5 version. But previous reviewers have > incrementally driven things to the current text. If Kent you prefer > something other than the current text, let me know what it is. I am sure I will > like it too. > > > > Eric > > > > > > > Thanks! > > > Dhruv > > > > > > > > > > In the abstract of this document, that draft is not explicitly > listed > > > > by reference (as I understood we are not supposed to use > references in > > > > abstracts). But it is listed in the Introduction. > > > > > > > > To make this clearer for you in this document, perhaps "transport > binding" > > > > instead of "binding"? I really don't have many alternatives I > can think > > > > of which also keeps the text brief. This particular text has > been > > > > frequently tweaked in the past. > > > > > > > > Thanks. > > > > Eric > > > > > > > > > > > > > Thanks! > > > > > Dhruv> > > > > > On Wed, May 8, 2019 at 9:14 PM Eric Voit (evoit) > <evoit@cisco.com> wrote: > > > > > > > > > > > > Update posted as -v20. With the corresponding change to > draft-ietf- > > > > netconf- > > > > > subscribed-notifications posted as -v25. > > > > > > > > > > > > Eric > > > > > > > > > > > > > From: Dhruv Dhody, May 8, 2019 2:21 AM > > > > > > > > > > > > > > Hi Kent, Eric, > > > > > > > > > > > > > > Fine with me! > > > > > > > > > > > > > > Thanks! > > > > > > > Dhruv > > > > > > > > > > > > > > On Wed, May 8, 2019 at 3:19 AM Kent Watsen > > > > > > > <kent+ietf@watsen.net> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > <eric> Based on my reading of your process suggestions > Kent, I > > > > > > > > like best the > > > > > > > “mention” approach which you used for RFC-8071, Section 1.4. > > > > > > > > > > > > > > > > What I think could be done to cover this is: > > > > > > > > > > > > > > > > (A) Remove Section 11: Notes to the RFC Editor > > > > > > > > > > > > > > > > (B) Per Kent’s desire to also cover > > > > > > > > draft-ietf-netconf-restconf-notif, place the > > > > > > > following statement into > > > > > > > draft-ietf-netconf-subscribed-notifications > > > > > > > directly after Figure 10 > > > > > > > > > > > > > > > > [RFC-5277] Section 2.2.1 states that a notification > message is > > > > > > > > to be sent to a > > > > > > > subscriber which initiated a "create-subscription". With > this > > > > specification, > > > > > this > > > > > > > RFC-5277 statement should be more broadly interpreted to > mean > > > > > > > that notification messages can also be sent to a subscriber > > > > > > > which initiated an "establish-subscription", or a configured > > > > > > > receiver which has been sent a “subscription-started”. > > > > > > > > > > > > > > > > Does this work for both of you? > > > > > > > > > > > > > > > > > > > > > > > > Works for me. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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"? > > > > > > > > > > > > > > > > > > > > > > > > > <Eric> That definitely makes things easier than what I > have > > > > > > > > been doing. I am > > > > > > > hitting an xml2rfc error trying this right now, but I will > get there. > > > > > > > > > > > > > > > > > > > > > > > > Yes, it was an eye-opener when I figured it out. Be > aware that, > > > > though > > > > > some > > > > > > > external sources (e.g., ITU standards) are supported, many > are > > > > > > > not, and so hand- coding the <reference> is still sometimes > > > > required... > > > > > > > > > > > > > > > > > > > > > > > > Kent // shepherd > > > > > > > > > > > > > > > > > > > > > > > > > >
- [RTG-DIR] RtgDir review: draft-ietf-netconf-netco… Dhruv Dhody
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Eric Voit (evoit)
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Kent Watsen
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Eric Voit (evoit)
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Kent Watsen
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Dhruv Dhody
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Eric Voit (evoit)
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Dhruv Dhody
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Eric Voit (evoit)
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Dhruv Dhody
- Re: [RTG-DIR] RtgDir review: draft-ietf-netconf-n… Eric Voit (evoit)
- Re: [RTG-DIR] [netconf] RtgDir review: draft-ietf… tom petch
- Re: [RTG-DIR] [netconf] RtgDir review: draft-ietf… Eric Voit (evoit)