Re: message-id attribute issues

[Andy Bierman <ietf@andybierman.com>]

Rob Enns wrote:

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

What about 4095 octets?   That's 20 times
bigger than any message-id I would have thought we needed.
Big enough to be useful, small enough to be mandatory-to-accept.

I realize that this whole issue is sort of
covered by the max-message-size issue.
After all, that is the real limit here that matters.

I understand that 4095 is just an arbitrary a limit as 65535.
However, we envision this field being around 16 bytes in
actual use.  IMO, if we come up with new semantics over
time, then we add an additional parameter with an appropriate
data type at that time.

I want to make sure that manager application developers
can reasonably expect to code to the limits in the standard
and have agents accept the request.

IMO this is different than the size of the <config> element that
obviously grows in proportion to the size of the device.


> Rob
>  

Andy

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