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

Julius Friedman <juliusfriedman@gmail.com> Mon, 15 December 2014 16:59 UTC

Return-Path: <juliusfriedman@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4456E1A86F5 for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 08:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47493J6AJFtJ for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 08:59:09 -0800 (PST)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224B31A86E5 for <avt@ietf.org>; Mon, 15 Dec 2014 08:59:04 -0800 (PST)
Received: by mail-pa0-f42.google.com with SMTP id et14so12228612pad.1 for <avt@ietf.org>; Mon, 15 Dec 2014 08:59:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TARSt44nWJCXMTr3Qhbh+Q//EsRaorydvipbjsYxppM=; b=ZAWSUU2WyDZi3ucFdviqz6z3QD/+zkX/DwqltJvAAR8cZEhrLU1yenZeBpS+cs86PP g40jMw9j8OKJISl/c4aldmcvL+R2Aes12vO4g85Yr7Q30fTkf9CS9U1gz2YiGrIZTCyU N1QS0FaG/jum031WRoLXeih4pJdbnRNLpN+ok9+8p9W97N77Het/1uAEQcOEVfqsErZg G/2A0EdRnMqIyEosoWYwjNcwpyTgY0aCOZ7XqN6uRw+FWB7Yrx6uiwbs2GivBJ1CRA/W 6fuVIt/9qerL0uRbIy3fJ/k12cvJjdkuxaUUYEIpk/SO3w9qtljd4IzNYfJkahVTnSRi 9aUA==
MIME-Version: 1.0
X-Received: by 10.68.211.193 with SMTP id ne1mr53153610pbc.49.1418662743317; Mon, 15 Dec 2014 08:59:03 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 08:59:03 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 08:59:03 -0800 (PST)
In-Reply-To: <CALw1_Q2r5=BLwJ_TwjBHhQ5ArRxnaPVCMNvBnvud_OEse+Q3jQ@mail.gmail.com>
References: <CACFvNHUYfvz+cR9nPtqUNz4ZVD-5N690QqNRHeCTq=DCcykwUQ@mail.gmail.com> <6CD85653-1D8F-4E46-8345-70242728B9CB@tno.nl> <CACFvNHUQ4UUA1FM-_pWY8AarjHU+Jb=QL0dNu7pPkzbjwPoGxw@mail.gmail.com> <CALw1_Q2mzc+1VCE4-=2Ys=x47Rtbw-grrzzm4bwQ_WU1fuyCyQ@mail.gmail.com> <CACFvNHWiBQdJagrWUm4fr0_HcpzfLs2HP+T=X1djDaANO0zV=g@mail.gmail.com> <CALw1_Q2r5=BLwJ_TwjBHhQ5ArRxnaPVCMNvBnvud_OEse+Q3jQ@mail.gmail.com>
Date: Mon, 15 Dec 2014 11:59:03 -0500
Message-ID: <CACFvNHWmy5HGDGbSQ=oWZmLscnvOMNrKw4eXDzOGPG8X5thfwg@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: Kevin Gross <kevin.gross@avanw.com>, avt@ietf.org
Content-Type: multipart/alternative; boundary="e89a8fb208e8df2373050a4428fc"
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/pfzf20Fax0RkK2aLX8OniHGSLAI
Subject: Re: [AVTCORE] Mail regarding draft-ietf-avtcore-leap-second
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 16:59:12 -0000

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" <kevin.gross@avanw.com> 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 <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
>>>>
>>>>