Re: [Netconf] LC on subscribed-notifications-10

[Robert Wilton <[e-mail]>]

Hi,

Some minor comments on this draft.  I've not read/reviewed all of it 
yet, so some more comments may follow.  But generally I am supportive of 
publishing this draft.

   I'm happy to leave it to the authors discretion on whether and how 
they want to address these.

1. I noted that neither the title nor abstract mention YANG or network 
configuration.  Nor do they mention that they define a YANG data model.

2. Intro:
  - Should security be somewhere in the intro section?

3. Section 1.1:
- Operational counters and instrumentation, it wasn't really clear to me 
whether, or how the draft really addresses this point.

- State change notification => "Subscription state change notifications"?

4. Sec 1.2:
- Configuration isn't necessarily persistent across reboots.  E.g. a 
configured subscription over something like I2RS.  Perhaps expand that 
configured subscriptions are normally persistent across reboots, but 
that depends on the behavior of the configuration subsystem.

- Steam: Is this really a set, or a sequence.  Perhaps ... "A continuous 
chronologically ordered sequence of events ..."?  If you change this, 
then perhaps grep for usage of "set" in the draft to see if they should 
be changed to sequence.

- I found the description of "Subscription" to be somewhat unclear.

5 Sec 1.3:

- I would have moved section 1.3 to the start of section 2.

- "starts pushing notification messages" -> "starts pushing notification 
messages to the subscriber/receiver".

- In paragraph starting "The lifetype or a dynamic" ... "running 
configuration" -> "applied configuration".

- In para starting "Configured subscriptions".  Should mention that 
subscriptions can also be killed by someone else with appropriate 
permissions.

- In para starting "The publisher MAY",  "MAY decide to" => "MAY", in 
two places.  In general I would suggesting checking all the MUST/MAYs 
and perhaps try to term them more explicit things that they 
MUST/MAY/SHOULD do.

6 Sec 2.

- Does this section need an intro, perhaps if section 1.3 moved here 
that would help?

- Sec 2.1 last paragraph.  Is this right that it must have access to all 
event records?  I wasn't sure how this tied in with YANG push where a 
client may not have access to read some nodes.  In that case, nodes that 
can't be read are left out (e.g. like a NETCONF GET request).  I know 
that YANG push covers this is more detail, but didn't know whether this 
paragraph correctly stands on its own?

7. 2.3 Qos, para starting "a dscp": "Where provided, this marking" => 
"Where provided, and supported, this marking" ...

8 2.4. Dynamic subscriptions

- Would writing "event streams" be better than "targets"?

- Diagram in 2.4.1, I found this diagram a bit tricky to 
read/interpret.  One particular question: Can you modify a subscription 
for a suspended receiver.

- In para starting "Failed modify", 'modify' => '"modify subscription"'.

9 2.4.2. Establishing a subscription:
  "It MUST be possible to support" => "A publisher MUST support". I 
would suggest changing both cases.

10. In para starting "an optional start time", perhaps also describe 
what happens if no start time has been provided.  Or perhaps just keep 
the first sentence and refer to 2.4.2.1 for more details.

11. In para starting "In the publisher", "it provides an identifier" => 
"it replies with an identifier"?

12. Sec 2.4.2.1, first paragraph:
   "then be followed by event records" => "then be followed by a replay 
complete event and then by event records"?

13. Sec 2.4.3, modify description tree output.  Identifier is optional, 
should be marked as mandatory?  Or otherwise what happens if it is not 
provided?

14. Sec 2.4.4.
- I would have called this "ending a subscription, or terminating a 
subscription" rather than "delete" because the subscription wasn't 
created, it was established.

- The text mentions the publisher rejecting a subscription, when can 
this happen?  Presumably only if the subscription id is not valid, or if 
it doesn't own it.  Perhaps check that this is consistent with how the 
text describes killing a subscription.

15 Sec 2.4.6
- Perhaps tweak the wording for "specifically ... specific".

16. Sec 2.5
"persistence across reboots" => "persistence across publisher reboots"?

Now skipping to Section 5.3 Security considerations!
- "all RPC requests" => "all subscriber RPC requests"?

- "MUST have the ability" => Something along the lines => Publishers 
MUST ensure that they have sufficient resources to fulfill a dynamic 
subscription request or otherwise reject the request, and provide ...

- "excessive use of system resources" => "excessive use of system 
resources on publisher or receiver".

- "No notification messages SHOULD be sent" => "Notification messages 
SHOULD NOT be sent".  Doesn't => Does not.

- Last paragraph, "it SHOULD NOT be assumed" => it cannot be assumed.


I will try and provide further comments between sec 2.5 and 5.3, but I'm 
somewhat short of time.

Thanks,
Rob


On 28/02/2018 23:09, Kent Watsen wrote:
> WG,
>
> The authors of netconf-event-notifications have indicated privately that they believe this document is now ready for Last Call.
>
> This starts a 2.5-week Last Call on draft-ietf-netconf-subscribed-notifications-10 [1]
> The LC will end on March 17, or when active threads peter out.
>
> Please send your comments on this thread. Reviews of the document, and statement of support, are particularly helpful to the authors.  If you have concerns about the document, please state those too.
>
> Authors please indicate if you are aware of any IPR on the document.
>
>
> [1] https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-10
>
>
> Kent & Mahesh
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
> .
>