RE: [EXP2STD] IANA Registries for LCT Header Extentions ?

All,

 

Another possibility which has been suggested to me is to have a single
flat registry (introduced by LCT) and abandon the PI-specific header
types idea. So, for example, LCT Header Extension 64 would mean the same
in all PIs, rather than having the possibility for 64 to mean different
things in different protocols that use LCT.

 

I think this would be simpler (and there are no backwards compatibility
issues).

 

If you disagree, please disagree *soon*, otherwise that's what will
appear in the draft!!

 

Regards,

 

Mark

 

________________________________

From: Mark Watson 
Sent: Tuesday, October 11, 2005 11:27 AM
To: [email protected]
Subject: [EXP2STD] IANA Registries for LCT Header Extentions ?

 

All,

 

In updating the LCT and ALC documents for Standards Track, I have come
again across the fact that there is no process defined for specifying
new LCT Header Extensions.

 

LCT divides the LCT Header Extension Type range into two parts, a
general part and a PI-specific part. LCT then defines two general LCT
Header Extensions (EXT_NOP and EXT_AUTH).

 

ALC goes on to define an ALC-specific LCT Header Extension EXT_FTI.
FLUTE defines two further ALC-specific extensions EXT_FDT and EXT_CENC.

 

I think we should have IANA registries for these: a registry for the
general LCT header extensions (which would be established in the 'IANA
Considerations' of LCT) and registries for the PI-specific header
extensions (one for each PI, established by the 'IANA Considerations' of
each PI specification).

 

Comments ? What should the allocation rules be ? "IETF Consensus",
"Specification Required" ?

 

Regards,

 

Mark

_______________________________________________
Rmt mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt