Re: [Netconf] LC on subscribed-notifications-10
Kent Watsen <kwatsen@juniper.net> Thu, 15 March 2018 01:51 UTC
Return-Path: <kwatsen@juniper.net>
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 8B965126D45 for <netconf@ietfa.amsl.com>; Wed, 14 Mar 2018 18:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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=juniper.net
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 X-7TfD_mu3a9 for <netconf@ietfa.amsl.com>; Wed, 14 Mar 2018 18:51:40 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A0B1242F7 for <netconf@ietf.org>; Wed, 14 Mar 2018 18:51:40 -0700 (PDT)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w2F1nWps006129 for <netconf@ietf.org>; Wed, 14 Mar 2018 18:51:40 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=oDUvA3pTMMFOW5As7YP6BLgdH/N3vHbucofyy8tguXA=; b=t4TvuMzDYR417eRRalieqKpcfDEdF3T7bfawjh+hkj7DIqJ3ECMKgpMGDW1FUclaejDw rRtOMH3kcgE76qqKrmkpqlRcUIpJm/9JPTRPZI4fUHWz/nQv6L+bpc6v/lUZEzuLbfe0 zul7tDjDiFhe+jDgUleyxn1jZbqmuHX6IWJNcPWCrU5GDnJLIWAL0Jw9i/3LgmpJypPH JirXBWTR/EsnXY3hcbZPILMPaQ7NjHT+0uOPUjuatwyZhljn9TL4rI0VHtl/1rehvn/R bh+idzLrkPE9SxwgZx0OIo9OkIecDg4vZkhugGC3QrjEeKvUT9uir8BMRD51UY4pcEDZ Eg==
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0053.outbound.protection.outlook.com [207.46.163.53]) by mx0a-00273201.pphosted.com with ESMTP id 2gqdrar5u4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <netconf@ietf.org>; Wed, 14 Mar 2018 18:51:40 -0700
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2844.namprd05.prod.outlook.com (10.168.175.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.6; Thu, 15 Mar 2018 01:51:38 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::d13e:bdcf:3798:c34f]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::d13e:bdcf:3798:c34f%2]) with mapi id 15.20.0609.006; Thu, 15 Mar 2018 01:51:38 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] LC on subscribed-notifications-10
Thread-Index: AQHTvAAnlMdwSaUGiEGsguuFvEIgrw==
Date: Thu, 15 Mar 2018 01:51:38 +0000
Message-ID: <17B884BF-0BB8-4B7C-BFBB-0AAFBEA857F6@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB2844; 7:ahwSZScHYpNRk1LtkS21f4Q9wac93EVzMnPQs3gC56cVshcjUiVqP3d6zTMi1Oj8dvKsMw3NVHp+VEfSXLy/vlaEx9BP9OBqDvnkvECSFT2rYSH67HtEDhKZFBZmf/Hi+XDWx3AiUSes0VeHhN49iWQcturOZ/lkwsKK4GYeP1y29dyrpDIK4htvOu+QiXaBRaxmI2JTtuSSR0NcUGHd6DpEtawWyGC3qPnaHjFDvU12Vn6xL1FHqwbtX3JNFG6K
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: cd09a9b9-5b10-42a2-41ce-08d58a174a83
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DM5PR05MB2844;
x-ms-traffictypediagnostic: DM5PR05MB2844:
x-microsoft-antispam-prvs: <DM5PR05MB28446BF307108EFB35456F55A5D00@DM5PR05MB2844.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(72170088055959)(192374486261705)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501244)(52105095)(93006095)(93001095)(6055026)(6041310)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB2844; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2844;
x-forefront-prvs: 0612E553B4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(39380400002)(396003)(346002)(189003)(199004)(51444003)(6116002)(6246003)(68736007)(6306002)(59450400001)(53946003)(25786009)(97736004)(26005)(66066001)(53936002)(2351001)(106356001)(186003)(105586002)(6506007)(6512007)(7736002)(102836004)(305945005)(15650500001)(81166006)(8936002)(8676002)(1730700003)(58126008)(99286004)(33656002)(81156014)(36756003)(86362001)(3280700002)(6916009)(2900100001)(14454004)(6486002)(3660700001)(478600001)(83716003)(966005)(6436002)(3846002)(5250100002)(2501003)(5660300001)(229853002)(82746002)(316002)(2906002)(5640700003)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2844; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: DFDpSBrSlk1bi3KvbuLBAK4Ar/GJyVmuluOyN/r3p6SZlRGdWsOEeRxqgxByCfdFQtD62cNVuvWkLNN9ASI7+F3eEATwCZWMWBogJcT0Z4m/W2VCtTppB9efRXxMNdadfDXNOHbcPiFfoGiAT9iqpd06s6SouMjDOzPwCF0X6w42s2q+e89BAxA1tYRQDnQ60z9NujcaLjQQ31+XpT3VfKKLu5pnAXZZzHDrbaxXRg18X1GR3y1rzB3Cg+H2wfLdbSvGOEDfmCv+/4x3lEeFUBtnoxn/aJs9n06uvqtuPBJiRY7vdG2Dgzghreug8RaBE7NnNwLhoS8AEDOvK08BFg==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9BA38412E0F19F41928863D2099F65A7@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: cd09a9b9-5b10-42a2-41ce-08d58a174a83
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2018 01:51:38.1399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2844
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-14_13:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803150019
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/czXSLwUoimAYYtctQYJ4ObLruJ0>
Subject: Re: [Netconf] LC on subscribed-notifications-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing 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, 15 Mar 2018 01:51:44 -0000
Here's my review of this draft. I'm aware that there may be some overlap with recent messages from Rob and Martin. Please respond to them anyways, if only to explain the resolution made. BTW, when I make an open-ended question, what I'm many times looking for draft-text that answers the question. Yes, I want to know the answer but, more importantly, I want the answer recorded in the draft. PS: I'm prioritizing reviewing all three drafts over trying to reply to responses from earlier reviews. Thanks, Kent // contributor (but revving-up for shepherd write-up) <chair-hat> Authors, can you please start planning a presentation to review any of the larger open issues during the meeting in London? </chair-hat> Title: the word "custom" is throwing me, what does it mean? I see the word in the Abstract and similar text in the Introduction. In total, the substring "custom" appears six times in the draft, all in the Title, Abstract, and Introduction, so the word doesn't seem to carry much weight in the body of the draft itself. Is there a better word? Perhaps "Subscriber-specific" or "Receiver-specific"? Or maybe you want to say "Customized Subscriptions to a Publisher's Event Streams"? Abstract: The first sentence has three issues: first, there's the custom/subscriber-specific comment from before; second, the word "capabilities" in the first sentence is unclear (if you mean NETCONF/yang-library capabilities, this document does not define any); and third, the word "operations" is ambiguous, the draft uses this word sometimes to mean RPCs, but other times not. Putting it all together, maybe this is better? This document defines mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Also, in the last sentence, s/Effectively/Combined/ and s/request/request for/? Introduction: Similar issues with the first sentence as with the Abstract. Also, missing is a statement regarding this draft's compatibility to NMDA (see rfc6087bis) Motivation: How about this? OLD: There are various [RFC5277] limitations, many of which have been exposed in [RFC7923] which needed to be solved. NEW: Various limitations in [RFC5277] are discussed in [RFC7923]. Resolving these issues is the primary motivation for this work. s/document includes/document include/ in the 2nd bullet, remove "statically"? the word "static" hardly appears... in the 3rd bullet point: would appending "in progress" be okay? Terminology: I think you want to use this one: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. For the "Configured subscription" term, I think that replacing "a configuration interface which" with "configuration that" is clearer. If necessary, we could import the term "configuration" from the revised-datastores draft. For the "Event" term, remove the parenthesis and spell out "e.g."? Remove the term "NACM", since it only appears in the Security Considerations section. For the "Notification message" term, is the beginning important? Maybe s/A set of transport encapsulated information/Information/? For the "Publisher" term, why is "Subscription" capitalized? Is it (and all other terms) capitalized consistently throughout the draft? For the "Stream" term, I'm wondering if this should be renamed "Event stream" (matching what's in the title), and then search/replace instances of just "stream" with "event stream" everywhere else in the document. This seems better, less ambiguous. For the "Subscribed event records" term, I recommend removing it, as it only appears three times in the draft and, besides, you already have the "Event record" term. For the "Subscriber" term, shouldn't you have a 2nd sentence like in the "Receiver" term? Since the tree diagrams are scattered throughout the document, it would be good to add the following here: Tree diagrams used in this document follow the notation defined in [I-D.ietf-netmod-yang-tree-diagrams]. Solution Overview what does "instantiated" mean in the 1st paragraph. suggest removing if not needed. in (1), s/RPC/an RPC/. Also, is "wants" the right word, maybe "is able"? same with "wish" in the next sentence. Also, in the last sentence, s/ which would have been accepted/ that, had they been present, would have enabled the dynamic subscription request to be accepted/? in (2), s/a configuration interface/configuration/. Also, replace "this capability" with "configured subscriptions", and maybe append "based on the use of a YANG feature"? "For connection-oriented stateful transport" : s/For/For a/ or s/transport/transports/? Looking at "Also note that transport specific transport drafts based on this specification MUST detail the life cycles of both dynamic and configured subscriptions." - do the netconf-event-notifications and restconf-event-notifications drafts do this? Last paragraph, s/The publisher/A publisher/ Relationship to RFC-5277: In the first bullet point, the "data model" for what, configuration or a notification? (same issue is in the last bullet point as well) The 4th bullet point isn't true (see Event Streams below) Solution: Can you add a paragraph here to introduce what all is in Section 2, how it's organized, or whatever might be helpful? Event Streams: The 2nd paragraph says "except for where it has been explicitly indicated that this the event record MUST be excluded from the NETCONF stream". This is a redefinition of what RFC5277 says, has this been discussed? How is this done (syntax/text)? Has it been done already? s/treated a distinct/treated as a distinct/ Event Stream Filters The 1st and 2nd sentences seems to be at odds with each other. QoS What does " MUST work identically" mean? - is HTTP a mandatory transport? RFC 7540 Section 5.3.3 talks about a PRIORITY frame, which is defined in Section 6.3 of that draft. How is this suppose to work in a transport-agnostic way? Dynamic Subscriptions s/RPC/RPCs/ Please provide more detail about how extensibility is accomplished, or an example showing the augmentation occurring. For all the subsections, should the title be s/Subscription/Dynamic Subscription/? Dynamic Subscription State Model What does "asserted" mean? - remove/replace? I'm confused by the diagram and subtitle's use of the word "receiver", when the first sentence of the paragraph above says that the SM is for the publisher... Only two notifications? Looking at the graphic, how is the reader to distinguish these as notifications? The last sentence of the last bullet doesn't square with what's in the graphic. is "modify-subscription" suppose to be bidirectional? Establishing a Subscription I take it that the last two sentences of the first paragraph are intended as requirements for transport-bindings. Is that correct? If so, then please say so. The tree diagram is not identified as a tree diagram. Nowhere in this document is the tree-diagrams draft referenced. This needs to be fixed. Are your tree diagrams dynamically-generated? - is there any concern that they are out-of-date? Since you're not describing the contents of the data model here, the text should say that a complete description of all the nodes is provided in the YANG module, with a reference. why is this "establish-subscription-error-stream" yang-data name having "-stream" at the end? (same issue with the other yang-data). It's a rather confusing name. Maybe "-info" would be better? Also, just so I'm clear, each transport-binding needs to indicate if and how the yang-data structs are returned, right? Where is this done in the netconf-notif and restconf-notif drafts? Replay Subscription Should the title being "Replaying Subscriptions", to match the verb tense of the other subsections? s/Replay puts no/Supporting replay puts no/ or /The document puts no/? Current text says: """ The inclusion of a replay-start-time within an "establish- subscription" RPC indicates a replay request. If the "replay-start- time" contains a value that is earlier than content stored within the publisher's replay buffer, then the subscription MUST be rejected, and the leaf "replay-start-time-hint" MUST be set in the reply. """ Why not just start with what you have, prepended by a special "event record" that says there is a gap? OLD: it MAY also be earlier than the current time and MUST NEW: it MAY be earlier than the current time, but MUST "subscribers can perform a get on" - rephrase, and use "RPC" somewhere Modifying a Subscription First sentence, no need for the word "previously" s/one or multiple times/multiple times -or- any number of times/? s/via RPC using/via an RPC on/? The tree diagram is not identified as a tree diagram. And since the data model isn't explained, there should be a statement for the reader to look at the YANG module for details, ideally with a hyperlink. Deleting a Subscription First sentence, no need for the word "previously" Under what conditions could a publisher reject a delete-subscription request? should there delete-subscription-error-stream hints? The tree diagram is not identified as a tree diagram. And since the data model isn't explained, there should be a statement for the reader to look at the YANG module for details, ideally with a hyperlink. Last paragraph, no need for the word "previously" Killing a Subscription Regarding: "This operation MUST be secured so that only connections with sufficiently privileged access rights are able to invoke this RPC." This needs to be in the Security Considerations section and, given that, doesn't need to be here, right? If you really want it here, then please indicate that such guidance is provided in the SC section. Replace the paragraph beginning with "The tree structure of" with the actual tree diagram for this RPC. RPC Failures Please also call-out RESTCONF error handling (RFC8040 Section 7.1). The 2nd paragraph is confusing. mechanism? how are the 1st and 2nd sentences related? What does the 2nd sentence really mean, esp. wrt. the MUST? I can't find any examples of these errors in use. The netconf-event-notifications draft only has examples for the "establish-subscription-error-datastore" and "modify-subscription-error-datastore" errors. Perhaps the examples in that draft need to be split into examples related to yang-push vs examples related to subscribed-notifications. Configured Subscriptions 1st paragraph: s/configuration interface/configuration/g (two cases) the note under the 3rd bullet point seems unnecessary but, if keeping it, then just say that receivers are unaware of the existence of any other receivers. s/In addition to subscription/In addition to the subscription/ s/as described in/described in/ where is the tree diagram for the configuration data model?! I don't understand the last bullet point. First, I'm having trouble parsing the implicit parentheses. Next, the last sentence seems complicated, maybe just say "unless directed otherwise, the notification messages MUST egress the publisher's default interface towards the receiver."? Configured Subscription State Model A better first sentence is needed, something introducing that there exists a state machine for each configured subscription, and states that there are three states (VALID, INVALID, and CONCLUDED), etc. Also should state where this state machine is maintained (publisher, receiver, both?) s/publisher evaluation/evaluation by the publisher/? Please move text regarding how to interpret the diagram (uppercase, dashed boxes, parantheses, etc.) into a preamble or postamble element. s/itself might itself/itself might/ s/in no longer/is no longer/ The first paragraph under the diagram doesn't match what the diagram shows. Looking at the diagram, I also see two possible sequence of transitions that get VALID to INVALID, but I'm unsure how they relate to the two mentioned in the text. The text should call out which parts of the diagram it's referring to. Many times I number labels in diagrams and then, under the diagram, provide a more thorough explanation for each number. Is it "any active or suspended receivers" or "any receivers for an active or suspended subscription"? s/During any times a/When a/? Regarding "Below is the state machine for each receiver of a configured subscription." - where is this state machine maintained, on the publisher or on the receiver? why is "receiver" in each box? Again, you might look to having a preamble or postamble to describe the syntax used in the diagram. 1st paragraph below diagram: s/to connecting/to "connecting" -or- to CONNECTING/? Regarding "and event records are not being dropped due to a publisher buffer overflow" - this seems like it's from out of nowhere. If not normative, then maybe delete? This text is again difficult to reconcile with the diagram. I again recommend numbering labels and then describe the numbers below. s/ mechanisms described above is/ mechanisms described above are/ What does this mean, how are mechanisms mirrored for RPCs and notifications? Regarding " provides an example of such an extension" - which section? Creating a Configured Subscription 1st paragraph: let the first sentence be its own paragraph as with the other 2.5.x sections. For the remainder, I think this is the 3rd time that the draft has discussed the differences between configured and dynamic subscriptions. Please eliminate unnecessary redundancy. Factor out into another section if needed. Regarding 2nd/3rd paragraphs, how resilient is the solution to the resumption of the underlying transport? If messages lost in the write-buffer are lost, could the receiver ever be helplessly out of sync without a full restart? Modifying a Configured Subscription s/ ././ ;) Resetting a Configured Receiver But *how* is it reset? - via a configuration operation? which one? Should this be part of "Modifying a Configured Subscription"? Event Record Delivery First paragraph, last sentence. I think I commented on similar text before. Is this a requirement for the transport binding? Do the netconf-notif and restconf-notif drafts satisfy this requirement? where? 2nd paragraph: "able to traverse" --> "not blocked by"? Also, for the 3rd sentence, call out the "RPC response" is for dynamic and "state-change notification" is for configured? Last two paragraphs, this text needs to be removed, or else we might need to block this draft on notification-messages. What do you mean by " this document will be updated to indicate support". Subscription State Notifications OLD In addition to subscribed event records, a publisher MUST send subscription state notifications to indicate to receivers that an event related to the subscription management has occurred. NEW In addition to sending event records to receivers, a publisher MUST also send subscription state notifications when events related to the subscription management has occurred. ??? 2nd paragraph: s/directly// Also, I'm unsure about the "subscription-state-notif" extension, how is it expected to be used by a YANG processor? Perhaps a generic notification-filtering GUI is envisioned whereby the logic could automatically remove these notifications from selection, but coding for this extension has very limited use, as no other drafts are ever likely to define any. I suppose it does no harm, but I also think that the text sure be clear. Personally, I'd rather the extension be removed unless there is a good reason to keep it. subscription-started: Regarding the 2nd paragraph, Section 2.4.2.1 implies a contradiction to this statement. The tree diagram is not identified as a tree diagram. And since the data model isn't explained, there should be a statement for the reader to look at the YANG module for details, ideally with a hyperlink. Why is all this sent to the receiver? Doesn't it already know the protocol and encoding? What about the other parts? Which parts are actually useful? subscription-modified 1st paragraph: the same parameters, or data model / tree diagram? Also, is "provided" the right word? Maybe it would be better to have the tree diagram itself, even though only the name changes? Last two paragraphs, why put "First" and "Second" when they are bullet points. Maybe you want to use a numbered-list or otherwise rephrase these? Last paragraph, the last sentence doesn't flow with the first. It seems as if it was copy/pasted from somewhere else. Is this intended to be a normative statement here? subscription-terminated 1st paragraph, 1st sentence: -e a/The publisher/A publisher/ and also s/the pushing of/pushing/? 1st paragraph: "Such a decision may be made for" - should this be "A publisher may terminate a subscription for" ? 1st paragraph, for the "first type of reason": does the subscription terminate when the first or last referenced objects are no longer accessible? BTW, what do you mean by "via the YANG model", aren't these instance objects in <operational>? 1st paragraph, what do you mean by " Identities within the YANG model"? Can the text be more clear that it is referring to the "reason" identityref in the tree diagram? The tree diagram is not identified as a tree diagram. last paragraph: remove "established". Also, the first 2 sentences would benefit moving to singular, as plural leads to some ambiguity. subscription-suspended Please replace the 2nd paragraph with the actual tree diagram, and then speak to that. subscription-resumed The tree diagram is not identified as a tree diagram. subscription-completed Please replace the 2nd paragraph with the actual tree diagram, and then speak to that. replay-completed 2nd paragraph: s/ If subscription/ If a subscription/ and s/which/that/ Please replace the last paragraph with the actual tree diagram, and then speak to that. Subscription Monitoring 1st paragraph: s/Container/The container/. How can container "subscriptions" (config true) contain entries for dynamic subscriptions? Are you assuming in <operational>? Also, does it include configured subscriptions that are currently not active for whatever reason? You mention NETCONF's <get> (wait, I thought this draft was suppose to be transport agnostic), but not NMDA's <get-data>, so it make me wonder if this paragraph regards the contents of <running> or <operational>... The 2nd paragraph would make more sense if I was looking at a tree diagram. But then I realize that this would be the same tree-diagram that should've been presented in Configured Subscriptions. Advertisement The second paragraph seems to be mostly NETCONF specific and therefore belongs in the netconf-binding draft. In a transport- agnostic draft, maybe only features should be discussed? YANG Data Model Trees s/top level YANG Data Node containers/protocol-accessible nodes/ " If you would rather see" - please use more formal language. Event Streams Container 1st paragraph, last sentence: perhaps rephrase as "This enables clients to discover what streams a publisher supports."? BTW, is the " and against which subscription is allowed" part important, if so, why? This tree-diagram does not match what I generate. This indicates that the tree diagrams are not being dynamically-generated. I strongly suggest updating your build script to dynamically generate the tree diagrams. We cannot afford to have them be out of alignment. Event Stream Filters Container "and validated" - is this needed, since *all* configuration is validated? s/ which/ that/ "referenced and used" - is there a difference? - can you just use one? Subscriptions Container This tree-diagram does not match what I generate. This indicates that the tree diagrams are not being dynamically-generated. I strongly suggest updating your build script to dynamically generate the tree diagrams. We cannot afford to have them be out of alignment. Data Model I going to skip this part, for now at least, as I assume the YANG Doctor will scrutinize it. Implementation Considerations s/ For a deployment/To support deployments/ s/split subscription/it is recommended to split subscription" is " unlikely" the right word? doesn't it eliminate the concern altogether? Regarding the 2nd-half of the 1st paragraph, is it necessary for interoperability reasons for this draft to define how to split the subscription identifiers into static and dynamic parts. Is the normative text needed here? Maybe just describe the current approach as a possible way to go about doing it? - I think it achieves the same goal without using normative text. For the 2nd paragraph, this sounds like normative text from earlier in the document. If so, then is it needed here again? For the 3rd paragraph, I'm not sure if the second sentence needs to be said at all, but at least s/SHOULD/should/ so it's not normative. Security Considerations Regarding the 1st paragraph, aren't *all* operations (configuration or RPCs) always authenticated and authorized? Please restructure to follow, in part, the template provided here: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-3.7.1 Regarding the 2nd and 3rd paragraphs, this sounds good, but isn't this behavior already defined by the draft? (or should be?) Regarding the 4th paragraph, why would the publisher need to the terminate the transport session? wouldn't it have started to reject dynamic subscriptions when it became overloaded? Or is this trying to say something specific about dropping the transport session as a club? ;) Re: the 5th paragraph, this is better than the 1st paragraph, but may not be needed if following the template. Re: the 6th paragraph, I'm surprised that requirements for transport- bindings wasn't discussed before in its own section. It seems like a new thing here, that a receiver's transport might not be secure. I'm okay with and support this, btw, as its sometimes better to offload devices thru the use of a local collector node, for which encryption may not be needed... Re: the 7th paragraph, this was said before also, right? Re: 2nd to last paragraph, what is the " very-secure" tag? Kent // contributor
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] subscribed-notifications-12 Eric Voit (evoit)
- Re: [Netconf] subscribed-notifications-12 Martin Bjorklund
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Xufeng Liu
- Re: [Netconf] LC on subscribed-notifications-10 Jeff Tantsura
- Re: [Netconf] LC on subscribed-notifications-10 Tim Jenkins (timjenki)
- Re: [Netconf] LC on subscribed-notifications-10 Igor Bryskin
- Re: [Netconf] LC on subscribed-notifications-10 Qin Wu
- Re: [Netconf] LC on subscribed-notifications-10 Tianran Zhou
- Re: [Netconf] LC on subscribed-notifications-10 JEFERSON CAMPOS NOBRE
- Re: [Netconf] LC on subscribed-notifications-10 Henk Birkholz
- Re: [Netconf] LC on subscribed-notifications-10 Robert Wilton
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Robert Wilton
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Martin Bjorklund
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Martin Bjorklund
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Andy Bierman
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Qin Wu
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 r… Balazs Lengyel
- Re: [Netconf] LC on subscribed-notifications-10 Rohit R Ranade
- Re: [Netconf] LC on subscribed-notifications-10 Alexander Clemm
- Re: [Netconf] [SPAM?] RE: LC on subscribed-notifi… alex
- Re: [Netconf] [SPAM?] RE: LC on subscribed-notifi… Rohit R Ranade
- Re: [Netconf] [SPAM?] RE: LC on subscribed-notifi… Juergen Schoenwaelder
- Re: [Netconf] [SPAM?] RE: LC on subscribed-notifi… Randy Presuhn
- Re: [Netconf] [SPAM?] RE: LC on subscribed-notifi… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [Netconf] LC on subscribed-notifications-10 r… Eric Voit (evoit)
- Re: [Netconf] [SPAM?] RE: LC on subscribed-notifi… Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 r… Martin Bjorklund
- Re: [Netconf] LC on subscribed-notifications-10 r… Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Alexander Clemm
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- [Netconf] subscribed-notifications-12 t.petch
- Re: [Netconf] subscribed-notifications-12 Eric Voit (evoit)
- Re: [Netconf] subscribed-notifications-12 t.petch
- Re: [Netconf] subscribed-notifications-12 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)
- Re: [Netconf] LC on subscribed-notifications-10 Kent Watsen
- Re: [Netconf] LC on subscribed-notifications-10 Eric Voit (evoit)