Subject: Issues for a bit more Discussion - Netconf Notifications

From: "Sharon Chisholm" <[email-masked]>
Date: Sun, 15 Oct 2006 13:27:48 -0400

Hi

As promised, here is the list of issues I think require a bit more
discussion. Note that this does not mean that I, as a technical
contributor, necessarily disagree with the person who raised the issue
or proposed a change.

1.	In section 5.2.1.2, do we need this new construct? As this is
related to the Beep transport mapping which is currently not properly
understood, it is difficult to say for sure. (source Balazs & Andy)
a.	We should remove any reference to non-existent BEEP
modifications in this document.  This is not an option.  Stuff like this
will only get stuck later anyway in the publication process. - The
NETCONF over BEEP authors (and others clueful in BEEP)  need to provide
input on all of sec. 5.2
2.	In section 5.3, paragraph 2 seems a bit unclear, and needs
punctuation. Explain why it is more important. (source Andy)
a.	This text came from someone. I don't remember what it means
3.	In section 3.2.6.2, it talks about opening either a new session
or a new channel on an existing session. Is this appropriate (source:
Martin)
a.	The reason channels were mentioned is that connection
conservation is more of an issue with the loss of 'mix-mode'
			b.	Technically, do I run a different
session on each channel, rather then how it is currently worded? So, it
would be more correct to just talk about sessions and leave multiple
channels out of it?
4.	In section 3.4, an object called 'lastModified' exists. Should
this not be called 'creationTime' instead since we lost the
modifySubscription command? (source Martin)
a.	lastModified is more consistent with SNMP
			b.	What if an implementation defined their
own way to modify the subscription. (They could always add their own
object later I suppose)
5.	In section 3.4, the number of messages sent is defined to be an
xs:integer which is not bound, but later in the document (section 4),
there is discussion about how sequence numbers roll over the message
counter when it reaches its capacity, which is also defined as an
xs:integer. These are inconsistent. Change to unsignedInt  (Source
Martin & Andy)
a.	In Netconf we have been taking a general policy of not setting
limits to things
			b.	Is there any value in forcing
implementations to keep this in a number larger then a 32 bit integer?
6.	In section 7, replay has a startTime associated with it, which
leads to some time-related questions. Is the time associated with the
event the time it is logged or the time it was generated, or the time
was sent out via Netconf? (source Martin)
a.	From our implementations perspective, we expect all
notifications to contain an event timestamp and we expect logging to
happen before it reaches to netconf stack. So, this means we could
probably support either the time it was generated or the time it was
logged. My preference is the latter.
7.	In section 7, why isn't their a symmetrical stopTime.
a.	From the use cases I've seen, stopTime is present time, so I
don't think we need an explicit stopTime to be able to specify something
else.
8.	Do we still need an identifier called subscription ID (source
Andy)
a.	Given that the base definition of notifications does not support
multiple subscriptions per session, do we still need this
			b.	I only have one Netconf session per
connection, but still have a session identifier don't I?
			c.	There are a couple of reasons why this
is needed. One is to support retrieval of subscription information. We
need an identifier that uniquely identifies it. You could argue that
this only needs to exist within the XML Schema.
			d.	Yes, as much as we hate to talk about
future features, it will be necessary for some optional capabilities
that some implementations may choose to support 
			e.	Are we using this in more ways then the
use cases require?
9.	The documentation currently defines appinfo to annotate
information in the document. Primarily the maxAccess clause and some
module Identity. We can't publish with a dependency on this document
since it would block us. 
a.	We talked about just publishing a short little document that
would define the appInfo bits we needed, as appose to full data
specification
			b.	Andy has suggested instead of maxAccess,
moving to config or not config, which I think could also work.  State
versus statistics would also be a nice distinction to be able to make,
but perhaps that can wait.
10.	In section 3.1, the URN for Netconf Notifications, is this
defined correctly? (source Bert)
a.	Currently: urn:ietf:params:xml:ns:netconf:notification:1.0
			b.	Should it be:
urn:ietf:params:xml:ns:netconf:capability:notification:1.0
11.	Should the XML Schema for retrieving stuff be defined in the
main body of the document or in the appendix (source Bert)

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Oct 2006 09:11:47 +0200

Sharon,
> modifications in this document.  This is not an option.  Stuff like
> this will only get stuck later anyway in the publication process. -
> The NETCONF over BEEP authors (and others clueful in BEEP)  need to
> provide input on all of sec. 5.2
>

To be clear, I do not have a huge amount of time to devote to this, and
almost assuredly Ken has less.  The fundamental issue is what level of
acknowledgment you want.  If you want NONE, then just use one large MSG
that is chunked, and let the client parse the page real time.  However,
I don't know what XML junkies would say about that.  On the other hand,
if you want application level acknowledgments, then group the messages
into groups you want acknowledged and use MSGs that should be ANSed
(this is my recommendation, since you can in effect implement the other
approach by using VERY large groupings).  Either way, the notifier sends
the agent sends the MSGs and the manager sends the responses (RPY for
one big page or ANS for multiples).

Eliot

--
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: Andy Bierman <[email-masked]>
Date: Mon, 16 Oct 2006 06:37:44 -0700

> one big page or ANS for multiples).

The WG already decided we do not want app-level ACKs.
They are supposed to be removed completely.

My comment (a) above is fairly clear -- we cannot create
new BEEP features or in any way rely on BEEP features that do
not exist in a Proposed Standard RFC.

> Eliot

Andy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Oct 2006 17:28:00 +0200

Andy,
> They are supposed to be removed completely.
My point was that you get this for free with BEEP (like so many other 
things) simply by choosing your grouping of messages and how you would 
process them (e.g., not waiting for the whole page).  You really need no 
additional PROTOCOL support for those acknowledgments (although some 
additional *application library* support on the part of the agent would 
be necessary).

> not exist in a Proposed Standard RFC.

I agree.

Eliot

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 18 Oct 2006 08:51:08 -0400

Hi

Ideally we will issue updates to the various transport mapping documents
with any required changes in order to be able to support notifications.
Presumably we can't start that work until the documents are published as
RFCs. We've been holding the text in our document for safe keeping
(although I agree the BEEP text is a bit broken currently).

Are we suggesting now is the time to remove this text from the document?
Where would it go? 

Sharon 

-----Original Message-----
From: Eliot Lear [mailto:[email-masked]] 
Sent: Monday, October 16, 2006 11:28 AM
To: Andy Bierman
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: Issues for a bit more Discussion - Netconf Notifications

Andy,

>
> My comment (a) above is fairly clear -- we cannot create new BEEP 
> features or in any way rely on BEEP features that do not exist in a 
> Proposed Standard RFC.

I agree.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Oct 2006 15:29:11 +0200

Sharon,
> Are we suggesting now is the time to remove this text from the document?

Once again I think we are suffering the poor choices we have made in the 
past by both having multiple transports and by requiring that each 
capability be available to each mapping.  Yes, we said that.  If we 
stick to that, the best approach to implement this silliness is to 
actually do what you did and stick this stuff in one document that 
updates all three.  Just get people to test each and you should be able 
to easily get to proposed this way.  If you really want three documents, 
then I assure this working group that we will not have three separate 
but equal mappings, because it is as likely as not for each capability 
you will not have an author or implementation available.

This having been said, I've given you the basis for text that should be 
sufficient for BEEP.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Oct 2006 06:37:30 -0700

> Are we suggesting now is the time to remove this text from the document?

The key phrase here is 'required changes'.
We don't have app-level ACKs, so there should be no text
related to that.  If there are any required changes to
the transport documents, let's identify them now.

We should decide where they go, once we know what they are.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 18 Oct 2006 10:30:02 -0400

Hi

While the text in the transport mapping sections in the notification
draft is not earth shattering, it does seem necessary. My take on what
is necessary is currently defined in section 5.

For example, section 5.1 says

" Session establishment and two-way messages are based on the NETCONF
   over SSH transport mapping [NETCONF-SSH]

   One-way event messages are supported as follows: Once the session has
   been established and capabilities have been exchanged, the server may
   send complete XML documents to the NETCONF client containing
   notification elements.  No response is expected from the NETCONF
   client."

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 9:37 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: Issues for a bit more Discussion - Netconf Notifications

Sharon Chisholm wrote:
> Hi
> 
> Ideally we will issue updates to the various transport mapping 
> documents with any required changes in order to be able to support
notifications.
> Presumably we can't start that work until the documents are published 
> as RFCs. We've been holding the text in our document for safe keeping 

The key phrase here is 'required changes'.
We don't have app-level ACKs, so there should be no text related to
that.  If there are any required changes to the transport documents,
let's identify them now.

Andy

> process them (e.g., not waiting for the whole page).  You really need 
> no additional PROTOCOL support for those acknowledgments (although 
> some additional *application library* support on the part of the agent

> would be necessary).
> to unsubscribe send a message to [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Oct 2006 08:32:16 -0700

>    notification elements.  No response is expected from the NETCONF

This is no different than what netconf-prot and netconf-ssh defines,
except for the bit about not expecting a response.  It seems to me
that the SSH document is the only one that doesn't need any special
text added to support notifications.

Doesn't the BEEP mapping need some text adding <notification> as
a top-level element?

Doesn't the SOAP mapping need lots of text (and hacks) to get
notifications to work?

We do not need to stick to the goal of "all features the same
on all transports", if current WG consensus has changed.
If we do not have sufficient interest and resources to produce
new transport documents for every mapping, then those mappings
should probably go away.  IMO, it doesn't matter if the text
is in the Notifications RFC or a bunch of other RFCs.
What matters is whether there is the consensus, expertise,
and resources to get the job done.

<tangent>
It's possible that we may end up in the long run with just SSH and TLS
transports, and eventually just TLS.  IMO, one feature of the NETCONF
protocol is the decoupling of the 4 layers.  As transport protocols
improve over time, new mappings can be defined without touching
the protocol spec.
</tangent>

Andy

---

From: Ted Goddard <[email-masked]>
Date: Wed, 18 Oct 2006 09:55:10 -0600

For SOAP we would need to describe that a separate HTTP
connection is opened for notifications and that the requests
for notifications may block for extended periods.
(It will take more than a paragraph to describe this precisely.)

However, if we allow that notifications need not be delivered
while another operation is in progress and we allow empty
notification responses, then a single HTTP connection could
be used effectively (with HTTP pipelining).

This is the technique that people are using with "Ajax Push".

Ted.