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

From: "Mark Watson" <[email-masked]>
Date: Wed, 1 Feb 2006 11:34:44 -0500

Vincent,

Looks good - I have two comments:

- 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
- 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.

I can include the proposal in the next LCT draft revision and address
these comments, so no need to do a new draft of your proposal (if you
agree with the comments!).

Also - the link to the LCT draft in the I-D directory has (finally) been
corrected, so could I ask if anyone has comments on LCT generally which
I should incorporate into the next update (which I am planning to do in
time for the next meeting). 

Regards,

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vincent Roca
Sent: Tuesday, January 31, 2006 7:18 AM
To: [email-masked]
Subject: [Rmt] EXT_TIME: a new HE for timing information in LCT

Dear Mark et al.

Here is the follow-up of a discussion we had in December on
the possibility of defining a new header extension for LCT
to carry several kinds of timing information.
Cheers,

    Vincent / Toni / Rod

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Vincent Roca <[email-masked]>
Date: Thu, 02 Feb 2006 09:21:51 +0100

Hello Mark,

>just be 'reserved' - I would not anticipate future use without defining
You're right, "future use" is ambiguous. Remove it.

>receivers, to allow more to be added in future in a backwards compatible
Good point too.

>agree with the comments!).
Yes you can.

>time for the next meeting). 

Best regards,

   Vincent

---

From: [email-masked]
Date: Fri, 3 Feb 2006 14:50:27 +0200

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.