[AVTCORE] Fwd: Technical - Re: [Editorial Errata Reported] RFC7273 (4450)

Kevin Gross <kevin.gross@avanw.com> Wed, 23 September 2015 05:10 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 822731A008B for <avt@ietfa.amsl.com>; Tue, 22 Sep 2015 22:10:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 9.279
X-Spam-Level: *********
X-Spam-Status: Yes, score=9.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FRT_STOCK1=3.988, FRT_STOCK2=3.988, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, NORMAL_HTTP_TO_IP=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 aGxafb89FP-0 for <avt@ietfa.amsl.com>; Tue, 22 Sep 2015 22:10:21 -0700 (PDT)
Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8041A0076 for <avt@ietf.org>; Tue, 22 Sep 2015 22:10:21 -0700 (PDT)
Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-08v.sys.comcast.net with comcast id LVAL1r0065FMDhs01VAMHs; Wed, 23 Sep 2015 05:10:21 +0000
Received: from mail-wi0-f178.google.com ([209.85.212.178]) by resomta-po-19v.sys.comcast.net with comcast id LV8K1r00C3rW5a901V8Lvn; Wed, 23 Sep 2015 05:08:21 +0000
Received: by wiclk2 with SMTP id lk2so221880559wic.0 for <avt@ietf.org>; Tue, 22 Sep 2015 22:08:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.71.206 with SMTP id x14mr37095396wju.147.1442984899384; Tue, 22 Sep 2015 22:08:19 -0700 (PDT)
Received: by 10.28.20.209 with HTTP; Tue, 22 Sep 2015 22:08:19 -0700 (PDT)
In-Reply-To: <CALw1_Q3uata7NAjEpbZm-UdPV_-xTyDe6D8yePAFezBcgTVEJA@mail.gmail.com>
References: <20150818173656.46E36180092@rfc-editor.org> <CALw1_Q0HojZUoJrTqNDe8kNK+xzYJPH+A5cuXQ_xgtU=6A5mFw@mail.gmail.com> <55EFEFF0.5060502@ericsson.com> <CALw1_Q3uata7NAjEpbZm-UdPV_-xTyDe6D8yePAFezBcgTVEJA@mail.gmail.com>
Date: Tue, 22 Sep 2015 22:08:19 -0700
Message-ID: <CALw1_Q2Jnq_JthMFKQ-oq2UGcPFTrAMnPHKegWH8h2jCcqy-4A@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: "avt@ietf.org" <avt@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bfcecf8581a7c0520631a95
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1442985021; bh=05kuuzKEnMAD7nu40WEy7NpEE2Z8WR1P5Eha1uexRlw=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=ATtrPDoOFMZs/vgdZnkqCed0p2NCdiDkKHcyRvcycZtXxwv91Iwj9R1V1F/7Sfvrb zcRAll2J/tLU5pLTM8B00uNcX/wHF4OCqemYV67MXExzCNDBMky3umZy4gMQSykAHr 5nUUTBjIhS5XGqaDS66PCXRPcu23zgBpnODPxTCcte8FzYUk6KUaOGKlVgmgs95MDn wfURQlq3t42XuHv36/R25KgEKOc8rv8pHcZ7uzFPIpkb/e6lQ091UEaUx0EhPPJeOi uoJ3H4/uEONxPxOJOyHni5U/DSCTkvka00LGWPuuLG4zR2TBw0oGicaBbudyovBlzA 1rD9TBKpPX5Ew==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/0gGHqnRwIEsO_-F2EBLxakhvYis>
X-Mailman-Approved-At: Wed, 23 Sep 2015 09:50:38 -0700
Subject: [AVTCORE] Fwd: Technical - Re: [Editorial Errata Reported] RFC7273 (4450)
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 23 Sep 2015 05:10:25 -0000

Apologies if this has already been seen, been getting bounce messages from
the reflector. IETF guys think they have it cleared up and have asked me to
try again.

Summary of the situation with RFC 7273: The ABNF and examples are not in
agreement.

I originally proposed that the examples be amended to match the ABNF.
However, research by the authors indicates that all current implementations
have been done in accordance with examples, not the ABNF. At this point
there are at least two independent implementations and a few others based
off one of those.

In light of this finding, we believe modifying the ABNF to match the
examples is the least disruptive solution.

We need feedback from the group as to whether this seems to be the right
approach. If so, we will proceed to prepare a revision.

Kevin Gross - AVA Networks

On Wed, Sep 9, 2015 at 2:38 AM, Magnus Westerlund <
magnus.westerlund@ericsson.com> wrote:

> WG,
>
> We clearly need to do something here. I really hope that people speak up
> if they have any input on this or have an implementation.
>
> I do however note that what suggested here appears to be inconsistent with
> examples also.
>
> First of all we need to look at the higher ABNF constructs:
>
>   ptp             = "ptp=" ptp-version ":" ptp-server
>    ptp-version     = "IEEE1588-2002"
>                    / "IEEE1588-2008"
>                    / "IEEE802.1AS-2011"
>                    / ptp-version-ext
>    ptp-version-ext = token
>
>    ptp-server      = ptp-gmid [":" ptp-domain]
>                    / "traceable"
>    ptp-gmid        = EUI64
>    ptp-domain      = ptp-domain-name / ptp-domain-nmbr
>
> As you may see the ":" before the "domain-nmbr" is coming from ptp-server
> ABNF construct, and should not be part of the changed ptp-domain-name one.
>
> Thus if the domain number should be used without prefix, then the correct
> ABNF I believe should be:
>
>      ; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
>      ptp-domain-nmbr = ptp-domain-dgts
>      ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
>      ptp-domain-n1   = DIGIT             ; 0-9
>      ptp-domain-n2   = POS-DIGIT DIGIT   ; 10-99
>      ptp-domain-n3   = ("10"/"11") DIGIT ; 100-119
>                      / "12" %x30-37      ; 120-127
>
>
> On the suggested change of the ptp-domain-name I would in fact recommend
> against it, because then the domain-numbers are a subset of the domain
> names as the allowed domain names allow all values for domain numbers.
> Thus, if one like to have explicit separation between these two types, then
> "domain-name=" follow by value should be retained for any domain names.
> Then a parser can also look at the first character after the ":" to
> determine if it "d" for domain names or a digit for domain numbers.
>
> Lets come to a consensus on what shape and form this correction should
> have. If you believe that the examples should be amended please argue that.
>
> Cheers
>
> Magnus Westerlund
> (AVTCORE chair)
>
>
>
> Den 2015-09-02 kl. 22:27, skrev Kevin Gross:
>
>> The authors have done some research on this issue and have determined
>> that all current implementations that signal IEEE 1588-2008 reference
>> clock use the notation from the examples, not the ABNF notation.
>> We would like to consider an alternate means of resolving the
>> inconsistency in the RFC in a manner consistent with existing
>> implementations.
>>
>> Change:
>>
>>     ; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
>>     ptp-domain-nmbr = "domain-nmbr=" ptp-domain-dgts
>>     ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
>>     ptp-domain-n1   = DIGIT             ; 0-9
>>     ptp-domain-n2   = POS-DIGIT DIGIT   ; 10-99
>>     ptp-domain-n3   = ("10"/"11") DIGIT ; 100-119
>>                     / "12" %x30-37      ; 120-127
>> To this:
>>
>>     ; PTP domain allowed number range: 0-127 (IEEE 1588-2008)
>>     ptp-domain-nmbr = ":" ptp-domain-dgts
>>     ptp-domain-dgts = ptp-domain-n1 / ptp-domain-n2 / ptp-domain-n3
>>     ptp-domain-n1   = DIGIT             ; 0-9
>>     ptp-domain-n2   = POS-DIGIT DIGIT   ; 10-99
>>     ptp-domain-n3   = ("10"/"11") DIGIT ; 100-119
>>                     / "12" %x30-37      ; 120-127
>>
>> For consistency, if we take this route we may also want to change:
>>
>>     ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
>>     ptp-domain-name = "domain-name=" 1*16ptp-domain-char
>>     ptp-domain-char = %x21-7E
>>
>> To this:
>>
>>     ; PTP domain allowed characters: 0x21-0x7E (IEEE 1588-2002)
>>     ptp-domain-name = ":" 1*16ptp-domain-char
>>     ptp-domain-char = %x21-7E
>>
>> The authors are aware of no implementations that signal a IEEE 1588-2002
>> reference clock.
>>
>> Any comments from the group on the preferred way to address this?
>>
>> Kevin Gross - AVA Networks
>>
>> On Tue, Aug 18, 2015 at 11:36 AM, <rfc-editor@rfc-editor.org
>> <mailto:rfc-editor@rfc-editor.org>> wrote:
>>
>>     FYI, the type of this erratum has been changed to Technical because
>>     it is not "a spelling, grammar, punctuation, or syntax error that
>>     does not affect the technical meaning".
>>
>>     Thank you.
>>     RFC Editor/ar
>>
>>     On Aug 18, 2015, at 7:49 AM, RFC Errata System
>>     <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>> wrote:
>>
>>     The following errata report has been submitted for RFC7273,
>>     "RTP Clock Source Signalling".
>>
>>     --------------------------------------
>>     You may review the report below and at:
>>     http://www.rfc-editor.org/errata_search.php?rfc=7273&eid=4450
>>
>>     --------------------------------------
>>     Type: Editorial
>>     Reported by: Kevin Gross <kevin.gross@avanw.com
>>     <mailto:kevin.gross@avanw.com>>
>>
>>     Section: 5.5
>>
>>     Original Text
>>     -------------
>>     5.5.  Examples
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 239.0.0.2/255 <http://239.0.0.2/255>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/48000/8
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
>>     a=mediaclk:offset=963214424
>>
>>     Figure 6: Media clock directly referenced to IEEE 1588-2008
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 239.0.0.2/255 <http://239.0.0.2/255>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/44100/2
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
>>     a=mediaclk:offset=963214424 rate=1000/1001
>>
>>     Figure 7: "Oddball" sample rate directly refernced to IEEE 1588-2008
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 224.2.228.230/32 <http://224.2.228.230/32>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/48000/2
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
>>     a=mediaclk:rtp=IN IP4 239.0.0.1 5004 00:60:2b:20:12:if
>>
>>     Figure 8: Stream media clock derived from another RTP multicast
>>     stream
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 224.2.228.230/32 <http://224.2.228.230/32>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/48000/2
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:0
>>     a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
>>
>>     Figure 9: Stream media clock derived from another RTP multicast
>>     stream
>>
>>
>>     Corrected Text
>>     --------------
>>     5.5.  Examples
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 239.0.0.2/255 <http://239.0.0.2/255>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/48000/8
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:domain-nmbr=0
>>     a=mediaclk:offset=963214424
>>
>>     Figure 6: Media clock directly referenced to IEEE 1588-2008
>>
>>     Figure 7 shows an example SDP description 2 channels of 24-bit, 44056
>>     kHz NTSC "pull-down" media clock derived directly from an IEEE 1588-
>>     2008 reference clock
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 239.0.0.2/255 <http://239.0.0.2/255>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/44100/2
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:domain-nmbr=0
>>     a=mediaclk:offset=963214424 rate=1000/1001
>>
>>     Figure 7: "Oddball" sample rate directly refernced to IEEE 1588-2008
>>
>>     Figure 8 shows the same 48 kHz audio transmission from Figure 6 with
>>     media clock derived from another RTP multicast stream.  The stream
>>     providing the media clock must use the same reference clock as this
>>     stream that references it.
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 224.2.228.230/32 <http://224.2.228.230/32>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/48000/2
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:domain-nmbr=0
>>     a=mediaclk:rtp=IN IP4 239.0.0.1 5004 00:60:2b:20:12:if
>>
>>     Figure 8: Stream media clock derived from another RTP multicast
>>     stream
>>
>>     Figure 9 shows the same 48 kHz audio transmission from Figure 6 with
>>     media clock derived from an IEEE 1722 AVB stream.  The stream
>>     providing the media clock must be synchronized with the IEEE 1588-
>>     2008 reference clock used by this stream.
>>
>>     v=0
>>     o=- 1311738121 1311738121 IN IP4 192.168.1.1
>>     c=IN IP4 224.2.228.230/32 <http://224.2.228.230/32>
>>
>>     s=
>>     t=0 0
>>     m=audio 5004 RTP/AVP 96
>>     a=rtpmap:96 L24/48000/2
>>     a=sendonly
>>     a=ts-refclk:ptp=IEEE1588-2008:39-A7-94-FF-FE-07-CB-D0:domain-nmbr=0
>>     a=mediaclk:IEEE1722=38-D6-6D-8E-D2-78-13-2F
>>
>>     Figure 9: Stream media clock derived from another RTP multicast
>>     stream
>>
>>
>>     Notes
>>     -----
>>     There is an inconsistency between ABNF in section 4.8 and examples
>>     in section 5.5. It would be cleaner to correct the examples and that
>>     is what is proposed above. There is evidence, however, that current
>>     implementations are working to what is shown in the examples, not
>>     according to the ABNF specification.
>>
>>     Instructions:
>>     -------------
>>     This erratum is currently posted as "Reported". If necessary, please
>>     use "Reply All" to discuss whether it should be verified or
>>     rejected. When a decision is reached, the verifying party (IESG)
>>     can log in to change the status and edit the report, if necessary.
>>
>>     --------------------------------------
>>     RFC7273 (draft-ietf-avtcore-clksrc-11)
>>     --------------------------------------
>>     Title               : RTP Clock Source Signalling
>>     Publication Date    : June 2014
>>     Author(s)           : A. Williams, K. Gross, R. van Brandenburg, H.
>>     Stokking
>>     Category            : PROPOSED STANDARD
>>     Source              : Audio/Video Transport Core Maintenance RAI
>>     Area                : Real-time Applications and Infrastructure
>>     Stream              : IETF
>>     Verifying Party     : IESG
>>
>>
>>
>
> --
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>