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

Julius Friedman <juliusfriedman@gmail.com> Mon, 15 December 2014 15:11 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 539D61A6FEB for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 07:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Level:
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 1-HZj59dsIk5 for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 07:11:24 -0800 (PST)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B621A6FE7 for <avt@ietf.org>; Mon, 15 Dec 2014 07:11:24 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id et14so12089357pad.3 for <avt@ietf.org>; Mon, 15 Dec 2014 07:11:23 -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=q4m40yKxtD40eGwqCeF7Au7k486QPfY7zoHBj+m6VYQ=; b=gLfDNu+k3qsxKM2UJTvUujPAfmmk5J7WS1GVo7CkPaLDj9vCUPsiTPqEQPbvrTegZj 5l0CIlEB4HRNTu6WUaFyKunK3722GOn9KEElzQC93kSW8+yxbja+WAbtA6kkNCTQg6JD ELi66niywqsjLjiNFGxHjHLoPX6mYLcdz/zyc06prAqTwk1Mhsrtwc8qL7i/HIXMv4gO IvjeOku5JNknzPwCIHwD+HeUrbakXvT7BMmGvTP4ooxJ2/069v6oYkt3UIGChoRtny1Y 3kK3JQTHez3hCZCBZDQxYi6VGeDgoDcH/tI301pCRoJS9wXJt5ghAdkk2EVVksnCoPm0 vrLw==
MIME-Version: 1.0
X-Received: by 10.68.236.67 with SMTP id us3mr31549315pbc.121.1418656283132; Mon, 15 Dec 2014 07:11:23 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 07:11:23 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 07:11:23 -0800 (PST)
In-Reply-To: <6CD85653-1D8F-4E46-8345-70242728B9CB@tno.nl>
References: <CACFvNHUYfvz+cR9nPtqUNz4ZVD-5N690QqNRHeCTq=DCcykwUQ@mail.gmail.com> <6CD85653-1D8F-4E46-8345-70242728B9CB@tno.nl>
Date: Mon, 15 Dec 2014 10:11:23 -0500
Message-ID: <CACFvNHUQ4UUA1FM-_pWY8AarjHU+Jb=QL0dNu7pPkzbjwPoGxw@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: "R. (Ray) van Brandenburg" <ray.vanbrandenburg@tno.nl>, avt@ietf.org
Content-Type: multipart/alternative; boundary="047d7b2e11b1d08c9d050a42a75d"
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/hFSyu3Xu7-3cKNPsnnxyuXFQMPo
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 15:11:38 -0000

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.
>
>