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

Kevin Gross <kevin.gross@avanw.com> Wed, 16 September 2015 00:57 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 C35F01B2FF2 for <avt@ietfa.amsl.com>; Tue, 15 Sep 2015 17:57:27 -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 dGDKiFxfocTi for <avt@ietfa.amsl.com>; Tue, 15 Sep 2015 17:57:23 -0700 (PDT)
Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E071B2FF1 for <avt@ietf.org>; Tue, 15 Sep 2015 17:57:21 -0700 (PDT)
Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-03v.sys.comcast.net with comcast id HcwX1r0034tLnxL01cxMqy; Wed, 16 Sep 2015 00:57:21 +0000
Received: from mail-wi0-f170.google.com ([209.85.212.170]) by resomta-po-02v.sys.comcast.net with comcast id HcvL1r0013h8is101cvLwL; Wed, 16 Sep 2015 00:55:21 +0000
Received: by wiclk2 with SMTP id lk2so49347270wic.1 for <avt@ietf.org>; Tue, 15 Sep 2015 17:55:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.84.99 with SMTP id x3mr13116025wiy.16.1442364919684; Tue, 15 Sep 2015 17:55:19 -0700 (PDT)
Received: by 10.28.20.209 with HTTP; Tue, 15 Sep 2015 17:55:19 -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: Tue, 15 Sep 2015 18:55:19 -0600
Message-ID: <CALw1_Q3uata7NAjEpbZm-UdPV_-xTyDe6D8yePAFezBcgTVEJA@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: "avt@ietf.org" <avt@ietf.org>
Content-Type: multipart/alternative; boundary=f46d044403a8aca374051fd2c0dd
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1442365041; bh=GhSNphCmNCkDYOuZh2x5p45fRAb6QiKwS36WkduReRQ=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=BEzqRbZbToSjElzN+BCNdz88K3ZzXC6rViHmIKKaWI3XpWuKddQx48VV2nJB8820B fJIHhBui2QVs8pOT2VFpuc4BNMP+c8aNx/eY9u4baEwKa9nSInXUgzNo44KjEBlTo1 a24Y4DVH7uKfQeubyge9x6kCXFmfgrD1CLsuKuskm1fqDOAJSRV7hFjXrzpffLItbo jaZGF+by6dDh9OdtEC7NuMNWEc9EpBY/Chtdoja5Mvl3MAA1EsJvtuUYPKGtiE73GO 20aDMnxn9szp64xroXru4Lt4nwe9FCa+ssgeMBsqs1w0HEAi8v6RKfMQLQT/anHEcV BW6lBaAsNMp0g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/If7kFljoyjKySHvjnr5Dk6q6Yr4>
X-Mailman-Approved-At: Wed, 16 Sep 2015 11:05: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, 16 Sep 2015 00:57:28 -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
> ----------------------------------------------------------------------
>
>