Re: pending edits for prot-10

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> 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.

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


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

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

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

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


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

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

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

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

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