Re: pending edits for prot-10

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

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.

  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



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