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

tom petch <ietfc@btconnect.com> Tue, 14 May 2019 11:47 UTC

Return-Path: <ietfc@btconnect.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 0212B12023E; Tue, 14 May 2019 04:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.248
X-Spam-Level:
X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 YqRHTGlxOHfu; Tue, 14 May 2019 04:47:43 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40136.outbound.protection.outlook.com [40.107.4.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D6C512011D; Tue, 14 May 2019 04:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kwz28VGWEARLQp01ztODptTCgO8hcRfpGm7UyIv44kA=; b=jRn2JYF7qMrYFUPvltAoqCXq0H83TRtatQOGiKfshKB5CFpYZsJQY3vWa5thSt9es2WeqlYi1+jKYKF9PDlQDCwM+n+RcIycqTf1nKFC84x2lfT299XTLrR49owF5JqZ1uyffYPtIY/ar+1I69D2/5S3Hb9dIw2DMXEXNBz/fwU=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB4573.eurprd07.prod.outlook.com (20.177.56.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.5; Tue, 14 May 2019 11:47:40 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::41a4:68a9:d620:d42b%3]) with mapi id 15.20.1900.010; Tue, 14 May 2019 11:47:40 +0000
From: tom petch <ietfc@btconnect.com>
To: "Eric Voit (evoit)" <evoit@cisco.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: AQHVCkrVRLH1NGoaRE+6tKjUhBK41g==
Date: Tue, 14 May 2019 11:47:39 +0000
Message-ID: <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net>
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>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0339.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:d::15) To VI1PR07MB3118.eurprd07.prod.outlook.com (2603:10a6:802:20::28)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-mailer: Microsoft Outlook Express 6.00.2800.1106
x-originating-ip: [86.139.215.234]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dddd2f64-f8b4-4ee9-a425-08d6d861f76e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB4573;
x-ms-traffictypediagnostic: VI1PR07MB4573:
x-microsoft-antispam-prvs: <VI1PR07MB4573F02FEB47F393994E09D1A0080@VI1PR07MB4573.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0037FD6480
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(376002)(366004)(39860400002)(51444003)(51914003)(199004)(189003)(13464003)(53546011)(50226002)(3846002)(476003)(6512007)(110136005)(446003)(54906003)(102836004)(486006)(86362001)(14454004)(9686003)(8936002)(2906002)(81156014)(81166006)(66066001)(71200400001)(229853002)(52116002)(68736007)(6436002)(84392002)(76176011)(386003)(44736005)(81686011)(81816011)(6506007)(6486002)(316002)(61296003)(53936002)(25786009)(305945005)(1556002)(7736002)(4326008)(5660300002)(6116002)(14496001)(86152003)(186003)(99286004)(44716002)(26005)(62236002)(478600001)(14444005)(256004)(66446008)(8676002)(73956011)(66556008)(15650500001)(64756008)(66946007)(66476007)(4720700003)(6246003)(71190400001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4573; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: AheCw2HFrYWbrgbNSbvFmeUZ6hwivuyZF0f8Fr109tE138doL4JEypNM1CPQKL/EV7D0+Bf1EdZ9A+kywxixCAAhpLlVD/RLJvIG1tqaXzOj4ILJG15btcNJ/qm0EzMYLrtvbE3rxQDWP6HQVT3iVsuq1jcsabEPntZEobeLJ50+mtpW0pBRlFQrwzEm7menZ3xNbrjSYrFAGUvJLayokIK3cFroMtFUeMGrN+qewxplqXDkzQPw8Nn7OPu0fdSuLhWoslN1mV7riHrVpxzWmH93bI9XxvyfGr60zwm70sZzCvWxSJudbvIi9j2mR50Hmb6eadOGlC329cGAooaH1jOIlNu5m+M6QH7zsGnaCyuzDwaSo8jnJBisIGYFEL455xA9/6jR52wHVuyiSpf2YSWLDB7oKgtPRRQHyLeInPA=
Content-Type: text/plain; charset="utf-8"
Content-ID: <3883871607C4DE4BA71C674F975A5E31@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: dddd2f64-f8b4-4ee9-a425-08d6d861f76e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2019 11:47:39.8492 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4573
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/KDCLhrDPC2Vt9gPqxqBgay2dsds>
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-17
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: Tue, 14 May 2019 11:47:46 -0000

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].

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]"

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.

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
> > > > > > >
> > > > > > >
> > > > > > >
>