Re: vendor extensions was Re: draft-ietf-forces-model-07 update

There are two issues for LFB Class identification.
Naming - textual names, used primarily for human beings
Numeric IDs - used by the ForCES protocol

We have a 32 bit numeric class ID space.  I 
proposed reserving the first 64K IDs for RFC 
defined IDs.  If we use even 10% of that space, 
we will have so thoroughly confused everyone that 
no one will be able to find anything.
I left the whole upper space for everyone else to use.  There is lots of space.

As for the names, I have no objection to a 
distinct prefix (or set of prefixes) for the 
upper large space.  I don't particularly like X- 
as the prefix because that normally indicates 
unregistered / unreserved identifiers.

And, if folks can come to an agreement on style 
conventions for LFB Class Names, Element Names, 
Structure Names, DataType Names, special value 
names, etc, I am happy to work with that.  I 
don't care, so I did not propose a specific 
convention.  The protocol and libraries will work 
without a convention, so I can live without 
one  (but coding conventions are usually a good idea).

Yours,
Joel M. Halpern

At 09:53 PM 10/16/2006, Jia Fenggen wrote:
>Hi,jamal,
>   I haven't seen tom's answer and joel's still 
> not speaking out on that,so i have to wait them before open an tracker issue.
>Yours,Fenggen
>>From: Jamal Hadi Salim <[email protected]>
>>Reply-To: [email protected]
>>To: Jia Fenggen <[email protected]>
>>CC: [email protected]
>>Subject: Re: vendor extensions was Re: draft-ietf-forces-model-07 update
>>Date: Mon, 16 Oct 2006 13:15:50 -0400
>>
>>On Mon, 2006-16-10 at 19:45 +0800, Jia Fenggen wrote:
>> > >SMI (which I hark back to as a well-established, widely used DDL) uses
>a
>> > >separate prefix (1.3.6.1.4.1) for the OBJECT IDENTIFIER of
>vendor-defined
>> > object
>> > >types but has no convention for the textual name, except that groups
>of
>> > related
>> > >object types start with the same lower-case (case is significant)
>string.
>> > >Surprisingly, given the size that this name space has grown to, I know
>of
>> > no
>> > >clashes within these lower-case strings, despite there being no formal
>> > database
>> > >of them.
>> > currently,protocol draft has an inital assignment on LFB classid in
>which
>> > 0x00010000-0x7FFFFFFF are reserved for vendor extension,but just as you
>> > mentions,as the LFB name space growing,this may not be enough,and
>further
>> > probably we should enforce an registration on the LFB classid for
>verdors
>> > but that lead to an problem like IP address assignment.
>> > According to the LFB class textual names,I prefer the prefix method.
>>
>>Me too.
>>
>>BTW, Issue #87 which i opened during the discussion on IANA entry for
>>the LFB model draft removes that from the protocol draft.
>>
>>http://www.mip4.org/issues/tracker/forces/issue87
>>
>>Fenggen, Once there is a consensus on something that needs to be fixed,
>>can you please open a tracker issue?
>>
>>cheers,
>>jamal
>
>_________________________________________________________________
>ÏíÓÃÊÀ½çÉÏ×î´óµÄµç×ÓÓʼþϵͳ¡ª MSN Hotmail¡£  http://www.hotmail.com