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

[Julius Friedman <[e-mail]>]

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" <[e-mail]> wrote:

> 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.
>
> Kevin Gross - AVA Networks
>
> On Mon, Dec 15, 2014 at 9:42 AM, Julius Friedman <[e-mail]
> > 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" <[e-mail]> 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.
>>>
>>> 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 <
>>> [e-mail]> wrote:
>>>>
>>>> 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" <
>>>> [e-mail]> 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 <[e-mail]>
>>>>> Date: Sunday 14 December 2014 18:56
>>>>> To: "[e-mail]" <
>>>>> [e-mail]>
>>>>> Subject: Mail regarding draft-ietf-avtcore-leap-second
>>>>> Resent-To: Kevin Gross <[e-mail]>, Ray van Brandenburg <
>>>>> [e-mail]>
>>>>>
>>>>>   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.
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Audio/Video Transport Core Maintenance
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>
>>>>