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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------