|
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: 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 Rmt at ietf.org https://www1.ietf.org/mailman/listinfo/rmt