Subject: RE: [Rmt] EXT_TIME: a new HE for timing information in LCT

From: "Mark Watson" <[email-masked]>
Date: Fri, 3 Feb 2006 13:03:19 -0500

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-masked] [mailto:[email-masked]] 
Sent: Friday, February 03, 2006 4:50 AM
To: Mark Watson; [email-masked]; [email-masked]
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-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: [email-masked]
Date: Mon, 6 Feb 2006 10:26:48 +0200

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.

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

---

From: [email-masked]
Date: Mon, 6 Feb 2006 15:23:50 +0200

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.

>From: [email-masked] [mailto:[email-masked]] 
>Sent: 06 February, 2006 10:27
>To: [email-masked]; [email-masked]; [email-masked]
>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.
>
>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:
>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)
>
>1 use field bit to one 32 bit time value or part-of-value). I 
>strongly dislike (3).
>
>Cheers, Rod.
>
>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.
>>
>>this part of the protocol, then the correct approach is an IANA 
>>registry for these time fields.
>>
>>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.
>>
>