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

Hi Mark

I agree with your argumentation.

I think we got caught in requirement words though. For me "...SHOULD..."
is the normative text - it's a hard requirement and, at least for the
public Internet, means that you have to have a pretty special reason to
go against it. Using the field in the way we anticipate it's use, seems
a fairly ordinary reason. "...bits are ignored..." is like "...will
be..." and is not requirement-speak. We should ignore that English
grammar that says "will" is stronger than "SHOULD" and stick with the
keywords where any experienced RFC reader will see "...will be..." as an
expectation, not a requirement. <Sorry about the academic tone - this
confusion is already enough to justify fining better language than
"...will be...">

If you read my mail with this in mind you'll see we're on the same page
for the bits I wrote about.

As for IANA registration - it's the same as specifying it in the RFC but
with less process overhead (new version of LCT not needed, just small
additional RFC for each registration). There are a few "reserved bits"
which fit into this "new LCT version" category. However, I think this is
overkill for all (or most) of the bits we have left over from 32-bit
alignment. IMHO, it's enough that basic LCT implementations are aware
that the field is there and generally set to zero; and fancy new
implementations (e.g. something like "time rich ALC") can use it however
they wish with no need for global reservation. It's like FLUTE in a
sense - the client needs to understand it's FLUTE if it's to use the
FLUTE semantics and some kind of general LCT client would be lost.

One thing the bear in mind is the header and HE length calculations.
Since the only way to know this HE's length is determined by the use
field, then we should probably say something about knowing the length -
unless we say this this header is always last (i.e. length could be
calculated from other HE lengths and the HDR_LEN). So far, every high
bit in the use field indicates +32bits in the EXT_TIME HE but I'm not
sure that this would hold for all usage. So we need _one_ of these:
1. EXT_TIME is always the last HE
2. The number of high bits in the use field, N, gives the HE length =
32bits x (1+N)
3. EXT_TIME and subsequent HEs MAY be discarded if the any others than
the first four use field bits are high (implying not knowing this HE's
length)

(2) is the most elegant but is this good use (though it requires fixing
1 use field bit to one 32 bit time value or part-of-value). I strongly
dislike (3).

Cheers, Rod.

>-----Original Message-----
>From: ext Mark Watson [mailto:[email protected]] 
>Sent: 03 February, 2006 20:03
>To: Walsh Rod (Nokia-NRC/Tampere); [email protected]; 
>[email protected]
>Subject: RE: [Rmt] 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.
>