Subject: pending edits for prot-10

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Dec 2005 06:53:17 -0800

Hi,

I want to wrap up the various change proposals to the protocol
document, so Bert can get an updated version ASAP.

The following changes will be made in the next version:

   1)  change the order of the <source> and <target> parameters
       in the <copy-config> command

   2) add a maxLength="4095" constraint to the <message-id> attribute

   3) provide XSD for standard <error-info> content
      (was removed from prot-10; needs to be fixed and replaced)

The following change is agreed upon, but the replacement text
with all the details has not been written yet:

  4) optionally advertise your own max-message-size in the
     capabilities exchange

   <element name="max-message-size" type="integer" minOccurs="0"/>

Comments?  Objections?

Andy

--
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: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Dec 2005 17:54:39 +0100 (CET)

>    <element name="max-message-size" type="integer" minOccurs="0"/>

I think this would be unfortunate if it's supposed to be used for all
messages, and not just notifications.

  o  This makes it difficult to implement agents which stream the XML,
     e.g. as you suggested as a way to handle big routing tables.
     (FYI, our implementation uses this technique).  These
     implementations would have to buffer all data before sending it,
     or to try to calculate the size of the message before actually
     sending it (which may or may not be possible).

  o  Some (most?) implementations will probably use a streaming
     approach for XML parsing, which means that it might be tricky to
     set a max message size since the overhead of the XML encoding can
     be difficult to calculate.

  o  If it's optional, does that mean that an agent can choose to NOT
     recognize this parameter, and send larger messages anyway?  In
     either case, a manager will probably have to be able to discard
     messages that are too big.  So why can't the manager do this all
     the time?  (for replies that is, for one-way non-acked
     notifications I can see the value in letting the agent know on
     beforehand if the manager will be able to handle the message or
     not.  maybe...)

  o  Making this a "global" value might also be difficult to implement
     for a manager - some replies might just be streamed to disk for
     later processing, such as a big routing table.  (ok, a manager
     could start a new session each time a request would need a
     different value).

>    <element name="max-message-size" type="integer" minOccurs="0"/>

BTW, the type should probably be xs:positiveInteger.

> Comments?  Objections?

The only other comment I have is that it would be nice to know why
noone seems to be interested in the xpath namespace issue.  Don't you
think it's a real problem?  Or should implementations invent their own
ways of handling this (if so, it could be mentioned in the doc).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Dec 2005 09:50:35 -0800

>messages, and not just notifications.

I think we need to say it's not used for anything until
we understand all the details.  Put item 4 in the 'pending' column.

>     beforehand if the manager will be able to handle the message or

Yes -- I should have clarified the word "optional".
I think there was more consensus for this parameter if it
was treated as a hint, not as a rule.

How can one argue against that?
What could that be? You would rather be ignorant of
the fact the other NC peer is throwing away your messages?

A stream-based implementation is not mandatory.
An implementation is allowed to have a maximum
message size (that it can receive), but there is no minimum value
any implementation has to support.  (This is a political compromise
intended to confuse people when they try to assign blame for
a broken multi-vendor NETCONF system ;-)

If you want successful interoperability, I suggest not ignoring
the max-message-size of the other peer.

>BTW, the type should probably be xs:positiveInteger.

okay

>ways of handling this (if so, it could be mentioned in the doc).

oops - I forgot that one.  Of course we care about namespaces! Right?
I was planning on just following your suggestion in my implementation:
I guess the document needs to clarify this issue.

 From your email on 12/12:

  <error-path xmlns:d="http://www.example.com/Datamodel">
      d:top/d:users/d:user[name="fred"]/d:companyInfo/d:dept
   </error-path>

Xpath really doesn't have any way of specifying namespaces?
Will the expression above break existing Xpath tools?
Maybe most people just plan on getting namespace processing wrong :-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 28 Dec 2005 20:09:46 +0100 (CET)

> we understand all the details.  Put item 4 in the 'pending' column.

ok.  but if that's the case, why not wait and add the capability later?

> the fact the other NC peer is throwing away your messages?

For a reply to a request by the same manager, yes, the agent could be
ignorant, since the manager would have to do something clever anyway
if it receives a message-too-big error.

And for notifications, what should an agent do if the remote can't
receive the message?  Probably log the message, and increment some
counter or something.  Maybe send some other notification which
informs about this?  But a robust deployment would probably log anyway
(if the notifs are one-way non-acked), so the agent doesn't really
care that max-message size is too big, it would just not send the
message.

> A stream-based implementation is not mandatory.

No, but again it would be nice if the protocol didn't rule this out
(implicitly by having the max-message size parameter).

> the max-message-size of the other peer.

For notifications I agree (if max-message-size is added).  But I don't
see the value in having this for a reply.

> I guess the document needs to clarify this issue.

Yes I think so, since I have seen one other suggestion (from Vincent).

> Xpath really doesn't have any way of specifying namespaces?

You can't define prefix to namespace uri mappings in the xpath
expression itself, but you can check namespaces the way Vincent
suggested (using the namespace-uri() function, which is kind of
awkward).

> Will the expression above break existing Xpath tools?

I think many tools use some kind of resolve function for prefixes, or
they take a prefix-to-namespace map as input.

> Maybe most people just plan on getting namespace processing wrong :-)

Maybe most implementations don't have xpath implemented yet...

/martin