RE: EXT_TIME: a new HE for timing information in LCT

Hi Rod,

This section question is actually a subtle on of who 'owns' that part of
the protocol. If we normatively require that ALC-compliant receivers
ignore additional data fields in the EXT_TIME then noone can add such
fields without being non-compliant to ALC. Of course we (the IETF) can
define updates to ALC which introduce new fields and change this
behaviour. So then we (the IETF) really own that part of the protocol.

If we just say that receivers 'SHOULD' ignore such additional fields,
then users of ALC (e.g. other standards bodies) can define such fields
without their receivers being non-compliant to ALC. But then the IETF
could not introduce such fields in a future revision of ALC without
potentially stepping on uses which have been defined elsewhere.

If we really want to open the possibility for other bodies to extent
this part of the protocol, then the correct approach is an IANA registry
for these time fields.

Personally, I feel that the overhead of an IANA registry is not
justified for these time fields and that IETF should retain full
ownership of this part of the protocol. So then the compatibility
behaviour should be normative so that other usages cannot sneak in
without being described in IETF - a short RFC to introduce a new time
field is a pretty simple thing in the unlikely event that it is ever
needed.

...Mark





-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Friday, February 03, 2006 4:50 AM
To: Mark Watson; [email protected]; [email protected]
Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT

Good points Mark. 

>- the bits that previously indicated the presence of SCT and 
>ERT should just be 'reserved' - I would not anticipate future 
>use without defining a new protocol version

Yes, this is the intent.

>- it should be specified that if there are additional fields 
>in the EXT_TIME after the SCT, ERT and SLC then these should 
>be ignored by receivers, to allow more to be added in future 
>in a backwards compatible way.

Yes. I'm not sure what normal RFC convention would be but my gut feeling
is that its best not to make normative behaviour - i.e. "these bits are
ignored" and not "these bits SHOULD be ignored". In this way another
spec using those bits isn't altering normative ALC behaviour.

Cheers, Rod.