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

[Kevin Gross <[e-mail]>]

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 <
[e-mail]> 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, <[e-mail]
>> <mailto:[e-mail]>> 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
>>     <[e-mail] <mailto:[e-mail]>> 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 <[e-mail]
>>     <mailto:[e-mail]>>
>>
>>     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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>
>