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

Kevin Gross <kevin.gross@avanw.com> Wed, 09 September 2015 22:54 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 1DCE71B3DCD for <avt@ietfa.amsl.com>; Wed, 9 Sep 2015 15:54:32 -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 5S85NIUbsJVr for <avt@ietfa.amsl.com>; Wed, 9 Sep 2015 15:54:28 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86C71B3C41 for <avt@ietf.org>; Wed, 9 Sep 2015 15:54:26 -0700 (PDT)
Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-08v.sys.comcast.net with comcast id FAtH1r0042JGN3p01AuSoh; Wed, 09 Sep 2015 22:54:26 +0000
Received: from mail-io0-f173.google.com ([209.85.223.173]) by resomta-ch2-10v.sys.comcast.net with comcast id FAsS1r0053l547l01AsSlt; Wed, 09 Sep 2015 22:52:26 +0000
Received: by iofb144 with SMTP id b144so40577977iof.1 for <avt@ietf.org>; Wed, 09 Sep 2015 15:52:26 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.8.164 with SMTP id h36mr54451975ioi.35.1441839146072; Wed, 09 Sep 2015 15:52:26 -0700 (PDT)
Received: by 10.79.100.7 with HTTP; Wed, 9 Sep 2015 15:52:26 -0700 (PDT)
In-Reply-To: <55EFEFF0.5060502@ericsson.com>
References: <20150818173656.46E36180092@rfc-editor.org> <CALw1_Q0HojZUoJrTqNDe8kNK+xzYJPH+A5cuXQ_xgtU=6A5mFw@mail.gmail.com> <55EFEFF0.5060502@ericsson.com>
Date: Wed, 09 Sep 2015 16:52:26 -0600
Message-ID: <CALw1_Q261z2RuRw_Av0QTzupWJSfFXW4VXdroh-EnZS-dRt2FQ@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: "avt@ietf.org" <avt@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f8bda200650051f58565e"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1441839266; bh=daW6+yTL2BlPxSdlrVsS4QhvWtR/8gF1SuoyOQmfYJk=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=F04HoRJS3FeEl4GF6ltmoWfDBvD9kLAxYvCmFoNdsUjGS2UqNR5NId/Wc56H7yF6B lMN3uoluJZr0l/iNZXgFR5ZEkSEmRy69B18kDFCPu155qzXRNrYMTJMcJtYx5rzJIy xlkfauSmVOrB71YNe9AfkgtCFJSWaJzh49jsx5ELmTsz5fZXIy3KETAdvUAoznKq5E nDycsnmETFOpnSGmdQB2MasraIfZo0ne9MZ6rRb1ijrbG0U+WzAZWd/xdrkxZZo2kl wvzzSL8gROaZzVI2+Pz1TQAq84bWroHt046Z53ia00CXBscDm14TQNgbk0IcCA4hVZ 2mi0dv1J67WzQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/3QGUC6dWjM-lmXelCX6v0_WJ5rQ>
X-Mailman-Approved-At: Thu, 10 Sep 2015 18:18:43 -0700
Subject: Re: [AVTCORE] 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, 09 Sep 2015 22:54:32 -0000

Summary: The ABNF and examples are not in agreement.

Our research 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
> ----------------------------------------------------------------------
>
>