[AVTCORE] AD review of draft-ietf-avtcore-leap-second

Richard Barnes <rlb@ipv.sx> Sun, 24 November 2013 20:07 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0CEF81AE30E for <avt@ietfa.amsl.com>; Sun, 24 Nov 2013 12:07:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DPtlsHoNY5IG for <avt@ietfa.amsl.com>; Sun, 24 Nov 2013 12:07:27 -0800 (PST)
Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id B6B711AE31A for <avt@ietf.org>; Sun, 24 Nov 2013 12:07:27 -0800 (PST)
Received: by mail-oa0-f46.google.com with SMTP id o6so3494556oag.33 for <avt@ietf.org>; Sun, 24 Nov 2013 12:07:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OilL3o845B1RNVq6HHCW6uImKT9Sjp8RLvSBhEVZkrQ=; b=kS3DLWp6o2TSvZKCknLcTgEmtHtgBln2+RG/OL4A4hpploy5ZZqLp/3tyt13lza+VM RkMjyiWXLWQZFSkGveinH36v/qJCntxCm9iu/UUKdL+i3Wmc/XDB7KqYSWwsH80VNLMW v3NXExzhVUeXKQ8BmHWv7dNw1kUnKY54fdgYo2N/wRQHj6TNnqwqNHHhQzV4N+tCFFEe gLr6Z7FxPMeoMfrxUrjvrrxZuGDfFXcq8m9ifjUQsZg2Oh++Vgy/08sAhKxLTXIGV8YC GwOHNHtN6sfa3K1ozMdLLOoF5YRTrOUij6w05tyh0f1d0PR/yroMYoZ7bK5Ouglq0ph6 nNMQ==
X-Gm-Message-State: ALoCoQlIa5tv6MwWQDligNVcIReA/Ezr5+Lj9rh5AiufAxp4xaC5xs5yNwYGx6lCOQW6xkmrYaSJ
MIME-Version: 1.0
X-Received: by with SMTP id xt7mr21625846obc.16.1385323639685; Sun, 24 Nov 2013 12:07:19 -0800 (PST)
Received: by with HTTP; Sun, 24 Nov 2013 12:07:19 -0800 (PST)
Date: Sun, 24 Nov 2013 15:07:19 -0500
Message-ID: <CAL02cgSLAPvaAZfdKrky53cVpB+Nqqhgj=RqMbYobOnWT3vwgw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: draft-ietf-avtcore-leap-second@tools.ietf.org, avt@ietf.org, "avtcore-chairs@tools.ietf.org" <avtcore-chairs@tools.ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2e22471546e04ebf1cb4d
Subject: [AVTCORE] AD review of 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: Sun, 24 Nov 2013 20:07:29 -0000

I have reviewed this draft in preparation for IETF LC, and think it looks
good to go.

One thing the authors might keep in mind while doing any LC or DISCUSS
edits is that it may not be immediately clear to the reader how suppressing
or ignoring SRs (Section 5.1) is helpful with this problem.   There's a
line in Section 5 that explains this ("generating or using NTP timestamps
... SHOULD be avoided"), but it would be helpful to tie the two ideas
together.  Perhaps something like this at the beginning of Section 5.1:
NEW: "In order to avoid generating or using NTP timestamps during periods
where confusion might arise (see above), RTP senders and receivers need to
avoid using RTCP Sender Reports (SRs) to synchronize their clocks during
this window, instead relying on their internal clocks to maintain sync in
the vicinity of a leap second."

Editorial nit: In Section 5,
OLD: "the timestamp ambiguity, positive leap seconds"
NEW: "the timestamp ambiguity that positive leap seconds"