Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-leap-second

From: Julius Friedman <[email-masked]>
Date: Mon, 15 Dec 2014 10:11:23 -0500

Granted then 3550 is updated in several standards and not necessarily
obsoleted, maybe thats the problem; whether or not assumptions matter the
details are clearly stated.

This draft doesn't specifically say how to check or correct this issue
which is should.

What if one party is not in leap year time and another is?

Furthermore the senders report is giving you a time to indicate the senders
time for a sample.

If this information is deemed so important that it makes it to standard
then I don't see why other such issues as the octet count are not also
addressed.

Two years or not I would assume better later than never.

Sincerely,
Julius Richard Friedman
On Dec 15, 2014 3:20 AM, "Brandenburg, R. (Ray) van" <
[email-masked]> wrote:

>   Hi Julius,
>
>    > This rfc also updated 3550 which is obsolete and should update 3551
> and only reference 3550 when required.
>
>  Where do you get the idea that 3550 is obsoleted?
>
>  > We assume that the small system dependent implementation of leap year
> needs to be addressed at the rfc level.
>
>  With ‘we’, I assume you mean ‘you’, since I haven’t seen your opinion on
> the mailing list in the roughly 2 years since this draft was first
> introduced and it becoming an RFC.
>
>  Ray
>
>
>   From: Julius Friedman <[email-masked]>
> Date: Sunday 14 December 2014 18:56
> To: "[email-masked]" <
> [email-masked]>
> Subject: Mail regarding draft-ietf-avtcore-leap-second
> Resent-To: Kevin Gross <[email-masked]>, Ray van Brandenburg <
> [email-masked]>
>
>   This is another priceless internet draft.
>
> We assume that the small system dependent implementation of leap year
> needs to be addressed at the rfc level.
>
> We do so without providing anyway to test your implementation to the given
> criteria or test the system to determine if any corrections are actually
> required.
>
> This should at the best case be informational.
>
> It is a larger problem to calculate the payload rate without csrc,
> extension and padding  than it would be to account for a leap year, this is
> especially true if the receiver synchronized to the sender then the time
> difference becomes 0 anyway.
>
> This rfc also updated 3550 which is obsolete and should update 3551 and
> only reference 3550 when required.
>
> Sincerely,
> Julius Richard Friedman
>
>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>

---

From: Kevin Gross <[email-masked]>
Date: Mon, 15 Dec 2014 09:32:49 -0700

This draft contains only recommendations, not requirements. You're welcome
to treat it as informational. Many have reported to me that it is very
helpful for understanding leap-second issues.

RFC 7273 can be used in conjunction with this draft to determine whether
timestamps in SRs contain leap-seconds.

I'm not sure what you're referring to when you say, "Small system dependent
implementation of leap year."

Kevin Gross - AVA Networks

On Mon, Dec 15, 2014 at 8:11 AM, Julius Friedman <[email-masked]>
wrote:
> Furthermore the senders report is giving you a time to indicate the
> senders time for a sample.
>
>>  With ‘we’, I assume you mean ‘you’, since I haven’t seen your opinion
>> on the mailing list in the roughly 2 years since this draft was first
>> We do so without providing anyway to test your implementation to the
>> given criteria or test the system to determine if any corrections are
>> actually required.
>>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>
>

---

From: Kevin Gross <[email-masked]>
Date: Mon, 15 Dec 2014 09:50:33 -0700

The recommendations have been designed to handle two leap-second insertion
techniques. The recommendations are robust enough to handle either/both
without knowing which are in play. The recommendations explicitly do not
accommodate "time-warping technichniques" (see references [4] and [5]) and
recommends that these not be used as an NTP timestamp reference.

On Mon, Dec 15, 2014 at 9:42 AM, Julius Friedman <[email-masked]>
wrote:
>
> Thanks for the response.
>
> I meant how can this draft determine how my operating system handled leap
> year insertion?
>
> Since it doesn't provide a method of detection then its informational and
> may not apply.
>
> Hence my comments.
>
> Also since by the time the sr was received the again the difference would
> be absorbed it would not  be worthwhile to calculate and would be better to
> monitor for time difference as usual.
>
> I also believe that its helpful to note that the senders octet count
> results in an invalid payload rate when csrc or extension ot padding is
> used but I guess I was also told to draft a rfc for the same reason.
>
> Anyway those were my thoughts and hence why I chimed in.
> On Dec 15, 2014 11:34 AM, "Kevin Gross" <[email-masked]> wrote:
>
>> This draft contains only recommendations, not requirements. You're
>> welcome to treat it as informational. Many have reported to me that it is
>> very helpful for understanding leap-second issues.
>>
>> I'm not sure what you're referring to when you say, "Small system
>> dependent implementation of leap year."
>>
>> On Mon, Dec 15, 2014 at 8:11 AM, Julius Friedman <
>> [email-masked]> wrote:
>>>
>>>>    > This rfc also updated 3550 which is obsolete and should update
>>>> 3551 and only reference 3550 when required.
>>>>
>>>>  > We assume that the small system dependent implementation of leap
>>>> year needs to be addressed at the rfc level.
>>>>
>>>> This message may contain information that is not intended for you. If
>>>> you are not the addressee or if this message was sent to you by mistake,
>>>> you are requested to inform the sender and delete the message. TNO accepts
>>>> no liability for the content of this e-mail, for the manner in which you
>>>> use it and for damage of any kind resulting from the risks inherent to the

---

From: Julius Friedman <[email-masked]>
Date: Mon, 15 Dec 2014 11:59:03 -0500

So who says there is only two ways?

How about if the receiver is not in a leap year when the sender is? E.g
north Korea or on another planet.

How can a system test itself to see if this recommedation is applicable or
the other type system to determine which way to use or if any changes are
even required.

I believe this response doesn't answer how using ntp is not better and
ignores that the clock can still change.
On Dec 15, 2014 11:52 AM, "Kevin Gross" <[email-masked]> wrote:

> On Mon, Dec 15, 2014 at 9:42 AM, Julius Friedman <[email-masked]
> > wrote:
>>
>> Thanks for the response.
>>
>>>>>  With ‘we’, I assume you mean ‘you’, since I haven’t seen your
>>>>> opinion on the mailing list in the roughly 2 years since this draft was
>>>>> first introduced and it becoming an RFC.
>>>>>
>>>>>  Ray
>>>>>
>>>>>