Re: [AVTCORE] Mail regarding draft-ietf-avtcore-leap-second
Kevin Gross <kevin.gross@avanw.com> Mon, 15 December 2014 16:52 UTC
Return-Path: <kevin.gross@avanw.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 C9DFD1A8029 for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 08:52:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level:
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no
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 QzcVLevBAquq for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 08:52:36 -0800 (PST)
Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674461A8545 for <avt@ietf.org>; Mon, 15 Dec 2014 08:52:34 -0800 (PST)
Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-06v.sys.comcast.net with comcast id Tsnq1p0055FMDhs01ssaU4; Mon, 15 Dec 2014 16:52:34 +0000
Received: from mail-yh0-f49.google.com ([209.85.213.49]) by resomta-po-19v.sys.comcast.net with comcast id TsqZ1p00K14WgC101sqZ6n; Mon, 15 Dec 2014 16:50:34 +0000
Received: by mail-yh0-f49.google.com with SMTP id f10so5240615yha.8 for <avt@ietf.org>; Mon, 15 Dec 2014 08:50:33 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.170.55.138 with SMTP id 132mr26071390ykx.77.1418662233528; Mon, 15 Dec 2014 08:50:33 -0800 (PST)
Received: by 10.170.229.84 with HTTP; Mon, 15 Dec 2014 08:50:33 -0800 (PST)
In-Reply-To: <CACFvNHWiBQdJagrWUm4fr0_HcpzfLs2HP+T=X1djDaANO0zV=g@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>
Date: Mon, 15 Dec 2014 09:50:33 -0700
Message-ID: <CALw1_Q2r5=BLwJ_TwjBHhQ5ArRxnaPVCMNvBnvud_OEse+Q3jQ@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Julius Friedman <juliusfriedman@gmail.com>
Content-Type: multipart/alternative; boundary="001a113a05d87c61bf050a440ae6"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418662354; bh=y6aJkL6dwexujRXuZYmq1gFKnvm6tXIR1zbxoox2TzE=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=mYyImHd36BzsOO7nWz72ltcvvdFHswdMBd9QQmDBI0Tpgos2w3i9q+I2W/0FWxNaP XfKxP85nOEVJPB9HNhCM0QMuciC2lytFqWvugqah+o617bzSMuV851Sijboc6pdAKF gRaPloEOe+yaYQJ2e4kd+RUxz7vRAP56MfPjHOEIiHnZP1HW8uJ9ektzlDozgISHhM 9plPeLktEVcR7lunc8QUXUhZY6u/ZBTyAVyO3akXXNDN5BPvhtxao3i1vpP7gve9Xs 38+GauJlxMgcPkyf7IaEe5shIZxns0b2nuylfUB2tX3lo5uOebIOpYbAq20MZRl9dL DTgwH9lEt79dQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/OI9bfP9lA_u-nuef3A0N0iUaIxE
Cc: "avt@ietf.org" <avt@ietf.org>
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:52:39 -0000
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 >>> >>>
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-l… Julius Friedman
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-l… Kevin Gross
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-l… Kevin Gross
- Re: [AVTCORE] Mail regarding draft-ietf-avtcore-l… Julius Friedman