Re: pending edits for prot-10

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:

> Andy Bierman <ietf@andybierman.com> wrote:
>  
>
> >  4) optionally advertise your own max-message-size in the
> >     capabilities exchange
> >
> >   <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.
>  

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.

>  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...)
>  

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.


>  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.
>  

okay

>  
>
> > 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).
>  

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 :-)

> /martin
>
>
>
>
>  

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/>