Subject: LFB Class ID assignment

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 4 Dec 2005 12:19:07 -0500

Evangelos' email reminded me of an outstanding issue.
The model requires that all LFB Class definitions be assigned IDs.
We have decided that this is a flat 32 bit space.

The model document needs to include an IANA consideration section that 
defines how these are assigned.
I am happy to write the section, but it is not for me to decide the policy.
Here are some ideas:

Should we reserve a range of IDs for experimental use?  (That would let 
developers assign a temporary number when working out a definition that 
would not collide with any assigned value?

I presume that we should have a large first-come-first-served range (FCFS).
I am inclined to require that registrants for that space indicate who is to 
be contacted with questions about the registration, the LFB Class name, a 
short description of the LFB class, and if available a public reference for 
the class.
If we go with this, we should presumably allow a registrant to update the 
data when a public reference becomes available.
We could restrict this registration range to items with publicly available 
reference documentation.  Should we?  My personal take is that making 
regstration easy is a good thing.  And we have plenty of numbers.

Should we have a separate range reserved for IETF / RFC assignment, or just 
use the same FCFS range?

Thank you,
Joel M. Halpern

---

From: Weiming Wang <[email-masked]>
Date: Wed, 7 Dec 2005 21:54:24 +0800

Joel,

I could understand the model RFC's  IANA consideration for LFB IDs as a
suggestion of ID range assignment like some range for normal LFB defined by LFB
lib RFC, some range for experimental purpose, and some for venders. Whereas, I
could not understand well why a FCFS registration should be used during this
process.  I just think IETF may not be responsible for such a registration for
IDs. IETF may only need to ensure that LFBs defined by IETF must have unique
IDs.
Not sure if I'v correctly catched your meaning.

Thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 7 Dec 2005 09:53:22 -0500

As a general practice, the IETF takes responsibility for making it 
practical for people to not have colliding use of identifiers in protocols 
we define.  This is particularly applicable for the ForCES model where we 
want many parties (companies, people, ...) to create LFB Class 
definitions.  Thus, the IANA maintains registries for many kinds of 
values.  Many of them allow registration by and for things other than RFCs.

Yours,
Joel

---

From: Alistair Munro <[email-masked]>
Date: Wed, 7 Dec 2005 20:21:41 +0000

Dear All,

I wonder if anyone lays claim to any LFB Class IDs already?

The NPF has assigned IDs for LFBs that it has defined so far, and I can 
make these available, with a request to consider re-using them. If that 
isn't acceptable then I can ask the NPF software group to review its ID 
assignments.

Regards,

Alistair

--
Alistair Munro,
Principal Engineer, U4EA Technologies Ltd.
City Point, Temple Gate, Bristol, BS1 6PL, U.K.
E-mail: [email-masked]
Tel: (home) +44-1275-462707, (mobile/cell) +44-7974-922-442;
Fax: +44-117-373-6751
Web: http://www.u4eatech.com

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 7 Dec 2005 16:24:25 -0500

As far as I can tell, there is no requirement that the NPF and the IETF use 
the same IDs for their class definitions.  The definitions are 
different.  We do want to reuse each others work, adn be able to map 
between the work.  But I would not expect the class IDs to be the 
same.  For example, class IDs 1 and 2 for ForCES describe entities that 
probably are not needed for NPF.

I would like to see someone familiar with the NPF work bring the relevant 
parts in as either full LFB Class definitions, or information to be 
included in ForCES LFB class definitions.

Yours,
Joel