Subject: Netconf Notifications: Pre-release (2) of -10

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 15 Oct 2007 15:19:08 -0400

Hi

Attached is a pre-release of version -10 of the Netconf Notifications
draft. Please send me any comments you have. I'd like to submit it soon.

Thanks,

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Oct 2007 22:20:50 +0200 (CEST)

Hi,

I have two comments:

In section 2.1.1:

>       If a <startTime> is requested which is earlier then the current
>       time, the following error is returned:

s/earlier/later/

----------

In section 6.5:

> 6.5.  Modifications to Existing Operations
> 
>    When a <create-subscription> is sent while another subscription is
>    active on that session, the following error will be returned:
> 
>       Tag: operation-failed
> 
>       Error-type: rpc, protocol, application

Error-type should probably be just 'protocol'.

/martin

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

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 24 Oct 2007 15:02:52 +0200

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.

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 think in one of the chapters (or both) we should use stronger words: like MUST, MUST NOT, 
SHALL ...

regards Balazs

---

From: Andy Bierman <[email-masked]>
Date: Mon, 29 Oct 2007 09:26:56 -0700

Balazs Lengyel wrote:
> 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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 29 Oct 2007 17:38:26 +0100

>    Notification subscription.  This means the NETCONF server is able to

Yes that will be fine.
Balazs