Re: message-id attribute issues

[Andy Bierman <ietf@andybierman.com>]

Rob Enns wrote:

> .....

> CLR? ;-) Seriously, I think implementors may find creative things
> to do with message-id, and 255 could be a bit short. 

What would be a reasonable size to allow vendors to still be creative
in the way they misuse the NETCONF protocol? :-)

Why do they need to overload the message-id with extra semantics?
You can put as many of your own attributes in the <rpc> element as you want.

My concern is that we describe (in 4.1) and show this field throughout
the document as a 3 digit integer, yet we encode it as a 65535 byte
string, without any explanation why.

If nobody wants to lower the hard-limit of 65535 that we now have,
that's fine.  It will be interesting to see what actual hard-limits get
used.

Manager application developers might be forced to use trial-and-error,
instead of the NETCONF spec, to figure out what they can actually send to
an agent.


> Every
> implementation
> will have a practical limit on the messages that can be received; do you
> think we should limit it in the spec?
>
> Rob
>
>
>  

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