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

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 protected] [mailto:[email protected]] On Behalf Of
Vincent Roca
Sent: Tuesday, January 31, 2006 7:18 AM
To: [email protected]
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