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

FYI - I clearly blew a fuse at the weekend when writing the last email
so please scrap the last 2 paragraphs on "HE length calculations". Now
I'm mostly sane again I realize I should have gone to HEL. (HEL being
the header extension length field which has solved this problem almost
since the dawn of man :)

Thank you Vincent for very kindly pointing this out. (I would have
forgiven much more brutal words for this magnitude of gaff :)

Cheers, Rod.


>-----Original Message-----
>From: [email protected] [mailto:[email protected]] 
>Sent: 06 February, 2006 10:27
>To: [email protected]; [email protected]; [email protected]
>Subject: RE: [Rmt] 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.
>>
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>