Subject: RE: message-id attribute issues

From: "Rob Enns" <[email-masked]>
Date: Mon, 19 Dec 2005 17:14:45 -0800

> I just noticed a couple more details in the schema in prot-10:
> 
>   - the message-id is mandatory to use in the <rpc> element
>     but optional in the <rpc-reply> element.  It should also be
>     mandatory in the <rpc-reply>, since all attributes passed in
>     the <rpc> have to be copied in the <rpc-reply>.

This was done because if the client sends an <rpc> without
a message-id (which is an error), the server has to respond.

>  - the data type for this attribute is xsd:string
>    This means everyone has to accept a message-id size of 
> 65535 octets.
>    That is a bit excessive IMO.
>    Can we limit this mandatory attribute to a reasonable 
> size, like 255?

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Dec 2005 02:37:05 -0800

>a message-id (which is an error), the server has to respond.

okay

>think we should limit it in the spec?

Right now we have a limit -- it's 65535.
If your agent doesn't accept a message-id attribute this big, it is broken.

(Imagine that some company like IWL is going to write a test suite
to test every one of these limits and tell your customers every place your
agent is broken.)

>Rob

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Dec 2005 19:49:50 +0100

> to test every one of these limits and tell your customers every place your

What about distinguishing between the upper limits as expressed in the
XSD and implementation "conformance" requirements?  I believe
xsd:string is just fine wrt. the upper limit. If people feel strongly
that there should be a smaller minimum implementation requirement,
then lets define these things as part of an applicability statement or
as implementation guidelines. The point is to not hardwire arbitrary
choices if we do not have to.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Dec 2005 11:48:00 -0800

>choices if we do not have to.

Let's make conscious decisions about the protocol.
This upper limit for the manager is the lower limit for the agent.
If the manager is allowed to send it then the agent MUST accept it.
I don't know what this idea of a smaller implementation requirement
is supposed to mean.  Please explain.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Dec 2005 21:48:56 +0100

> is supposed to mean.  Please explain.

I guess it boils down to the question how hard-wired a limit is.

The SMI specs state that an OID is 128 sub-identifiers (something
people considered a useful large number several years ago). We now
know that this limit hurts with table indexes becoming larger and if
you want to do more fancy protocol extensions (which we never got
agreement on - but at least the OID limit was one of the factors that
did hurt). And we have other somehow arbitrary limits in the SNMP
world which then led to CLRs.

The size of the message-id attribute might be less of an issue - but
who knows for sure? The question I think is whether we forsee that
sizes might change in the future and we envision that new ones can be
announced via say a capability or whether we hard-wire arbitrary size
constraints in the XSD based on what we believe is a good choice
today, which means the XSD has to change to lift such limits.

/js

PS: I did a quick scan of the IMAP specs to see whether they limit
    the size of the IMAP tag (which I think is very close in nature
    to netconf's message-id). I did not find a size limit - does
    anyone know whether such a thing exists? Otherwise, if IMAP
    can do without a specific size limit, perhaps netconf 1.0 can
    do as well.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 20 Dec 2005 13:29:35 -0800

Rob Enns wrote:

>.....

>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

Andy