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

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 <juliusfriedman@gmail.com>
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" <kevin.gross@avanw.com> 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 <
>> juliusfriedman@gmail.com> 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" <
>>> ray.vanbrandenburg@tno.nl> 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 <juliusfriedman@gmail.com>
>>>> Date: Sunday 14 December 2014 18:56
>>>> To: "draft-ietf-avtcore-leap-second@tools.ietf.org" <
>>>> draft-ietf-avtcore-leap-second@tools.ietf.org>
>>>> Subject: Mail regarding draft-ietf-avtcore-leap-second
>>>> Resent-To: Kevin Gross <kevin.gross@avanw.com>, Ray van Brandenburg <
>>>> ray.vanbrandenburg@tno.nl>
>>>>
>>>>   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
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>>>