Re: Netconf Notifications: 10 comments

[Andy Bierman <ietf@andybierman.com>]

Balazs Lengyel wrote:
> Hello,
> The draft is in really good shape, ready for prime time, still 2 comments:
>
> Ch 6.5) In the Error-info we have startTime, while the subscription 
> request might not have had startTime at all. I think the rejection of 
> the second suscription is independent of the startTime.

This is probably a cut-and-paste omission:

OLD:

 Error-info: <bad-element>: startTime

NEW:

 Error-info: none




> Ch 1.3 and 6.1) Both with and without the interleave capability we only 
> know that an edit-config during notification delivery MAY receive a 
> response. We do not know that without the capability edit-config will 
> fail. We do not know that with the capability the edit-config will 
> succeed. So what is the reason to have the capability?

I do not agree.
Any of the operations can fail for various reasons in normal mode.
Just because these same errors can occur in interleave mode
does not change the value of the interleave capability.
The capability is there to let the manager know if it should
even try an <rpc> while notifications are being delivered.


> I think in one of the chapters (or both) we should use stronger words: 
> like MUST, MUST NOT, SHALL ...

where exactly?
I think the 1.3 text is fine.

Here is 6.1:

   The Interleave capability indicates that the NETCONF peer supports
   the ability to interleave other NETCONF operations within a
   Notification subscription.  This means the NETCONF server is able to
                                                             ^^^^^^^^^^
   receive, process and respond to NETCONF requests on a session with an
   active notification subscription.

s/is able to/MUST/

I think this addresses your concerns right?


> regards Balazs

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>