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

tom petch <ietfc@btconnect.com> Tue, 21 May 2019 09:46 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 D996E1200CC; Tue, 21 May 2019 02:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.247
X-Spam-Level:
X-Spam-Status: No, score=0.247 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] 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 TOe1d90T9yJ4; Tue, 21 May 2019 02:46:32 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00091.outbound.protection.outlook.com [40.107.0.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4676A12011C; Tue, 21 May 2019 02:46:32 -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=F1K8irG0xXv58GFIRhbJvcwy4fIyNthJy6Nwwbzf324=; b=pHsrpje+BTsShnNm7Zk/xjy+PiM1kwV0HikoXhtWqBtGsRo0yQIsPTX0APd7lmiAktK57IkK27F8lHW6y929d+j61PrR8JySlaYRTDk2jEXgy98saY4ZiujiYarTBrWeiS0vTrGHWNJBwz675jKqyJMp0hOKfo0qRoiHnnbYT7E=
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com (10.175.242.156) by VI1PR07MB5326.eurprd07.prod.outlook.com (20.178.11.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.9; Tue, 21 May 2019 09:46:29 +0000
Received: from VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d]) by VI1PR07MB3118.eurprd07.prod.outlook.com ([fe80::7537:44ee:88c1:dd6d%7]) with mapi id 15.20.1922.013; Tue, 21 May 2019 09:46:29 +0000
From: tom petch <ietfc@btconnect.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>
CC: "draft-ietf-netconf-netconf-event-notifications.all@ietf.org" <draft-ietf-netconf-netconf-event-notifications.all@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-21
Thread-Index: AQHVD7oQaflczmem80CO42kqbYL/XQ==
Date: Tue, 21 May 2019 09:46:29 +0000
Message-ID: <057401d50fb9$855e16c0$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> <058801d50a4a$4f3308e0$4001a8c0@gateway.2wire.net> <23a9e41d7bcb41d7a6b7a9eeb50aaa18@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: LNXP265CA0006.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::18) 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: 2d900107-eb9f-4562-2cc4-08d6ddd132db
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:VI1PR07MB5326;
x-ms-traffictypediagnostic: VI1PR07MB5326:
x-microsoft-antispam-prvs: <VI1PR07MB53261FC4907A4CEB37B835E8A0070@VI1PR07MB5326.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0044C17179
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(376002)(39860400002)(136003)(51914003)(13464003)(51444003)(189003)(199004)(99286004)(316002)(26005)(52116002)(54906003)(14454004)(81686011)(81816011)(53936002)(6246003)(61296003)(76176011)(6916009)(486006)(5660300002)(386003)(6506007)(53546011)(68736007)(102836004)(2906002)(6116002)(478600001)(71200400001)(84392002)(30864003)(186003)(86362001)(446003)(476003)(14496001)(71190400001)(3846002)(1556002)(305945005)(7736002)(50226002)(44736005)(6486002)(8676002)(229853002)(6436002)(8936002)(81166006)(81156014)(86152003)(4720700003)(66066001)(62236002)(44716002)(256004)(6512007)(9686003)(73956011)(66946007)(14444005)(15650500001)(25786009)(66446008)(64756008)(66556008)(4326008)(66476007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5326; H:VI1PR07MB3118.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0;
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: DuiN4sVi/Tt4NWQdMzqUyPgIHPTgs3grR8hJNy2D/IrCwuIV/o/Czu3bZliDdqBY+aF1oyAsD2fO6t0ZAO1ehpgD29eGym+Z6EXjgs76W6UMnmwlNHI0aDeuVHjH9TeeUNNDa0u7QBL3dR96fn/UfYIBoZMSF+tGnHwPGSD2yFCFvc+kVJq24w1Wsl+iNxVZbC9jw3dxes4mPDaaj4VNyuDPhFS3erHKmx9P2Aa/w2Sc7zX2UasKYsUxqzVfGBj/1lstDHc4k2eFMuFe5CbRI8Cv2yB/rJzMJ10NxKxlSS33mBpjwdsBdlomlHdi4kLo33gi0TJD4S1Fi8lifC1NscT6BOMuz3PSYeWfEkxEqY3qrjPyt6yxH9dpALhOHJb/xayvDSlN5e5QP+j+FrRhK6mZiY+cBS/4LsBP5yPNnx4=
Content-Type: text/plain; charset="utf-8"
Content-ID: <063C44D8CE7D4549A6A46CD8BB45B179@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2d900107-eb9f-4562-2cc4-08d6ddd132db
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2019 09:46:29.5768 (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-CrossTenant-userprincipalname: ietfc@btconnect.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5326
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/oYkDFw8afnsDrer503w6m3T6Lwk>
Subject: Re: [netconf] RtgDir review: draft-ietf-netconf-netconf-event-notifications-21
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, 21 May 2019 09:46:36 -0000

Eric

Looks good but I do agree with Benjamin about the grammar of

"And per [RFC5277]'s "eventTime" object definition, the
   "eventTime" populated with the event occurrence time."

I cannot make that into a sentence. 'populated' seems to be a past
participle making ' populated with the event occurrence time' into an
adjectival clause and the whole lacking a main verb; IMHO it needs a
verb before 'populated' such as 'is', 'will be', 'MAY be',  ' MUST be'
etc.  I await with interest the views of the RFC Editor whose word on
these matters I treat as gospel.

Tom Petch

----- Original Message -----
From: "Eric Voit (evoit)" <evoit@cisco.com>;
Sent: Tuesday, May 14, 2019 3:59 PM

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