RE: message-id attribute issues

["Rob Enns" <rpe@juniper.net>]

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

Yep, true. I just have a feeling (no secret plans) that folks may
want to reuse message-ids from other places/namespaces when it's
convenient so the flexibility would be nice.

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

Yes, also the same issue exists with the requirement to return any
extra attributes, since they could be large.

If we _had_ to come up with an upper limit on message-id length, 
I'd lean to 1024 bytes as a nice round number. That could be the
thin end of the wedge to getting upper limits on all attributes,
so I'd still like to avoid it.

Rob

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