Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-01

[Kevin Gross <[e-mail]>]

Thanks for the review Magnus,

I've prepared, but have not yet published, a new draft addressing these
comments as described below.

Are there any issues with the proposed resolutions or any other comments
from anyone else on this draft before I post the update?

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Fri, Nov 9, 2012 at 4:40 AM, Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
> I have review the Clock Source document draft-ietf-avtcore-clksrc-01 and
> have the following comments:
>
> 1. General comment on all the use of hanging lists. Please put in some
> separator characters like ":" between the label and the bullet text.
>

Fixed.

>
> 2. Section 3. media stream
>
> Yes, it is made clear above that this is SDP terminology. But as "media
> stream" is also used for the sequnce of packets comming from an SSRC in
> RTP I think it is prudent to call this type of media stream "SDP media
> stream" to avoid confusion in the reader.
>

Reworked definitions section and some ambiguous terminology use in the
draft to clarify difference between RTP media stream and SDP media stream.

>
> 3. Section 4.6
> This is really a question of how traceable clocks works. I know in
> Sweden we have "Swedish Time" which is produced by a governmental body
> using a number of time production centers and time sources. Several of
> the time sources are also used to help produce UTC. Commonly the
> difference between Swedish time and UTC will be minimal, i.e on the nano
> second level. However, in the case Sweden would be isolated from UTC
> users of Swedish time will be able to use a common time-base. This is
> clearly tracable, but how do you deal with the fact that there are
> different sources of traceable time.
>
> For example, my home computer's clocks runs of the Swedish strata one
> NTP servers, but I think it is traceable also.
>

To eliminate ambiguity, we've improved the definition of traceable time to
reference TAI. I've also added a note explaining that UTC is TAI with leap
seconds added occasionally to compensate for slowing of earth's rotation.
Either UTC or TAI is a valid traceable time.

TAI is an average of atomic timekeeping all across the world (including
Sweden, I assume). The various measurements are compared and combined and
used to correct locally generated time so that all important world time
standards progress together.

If Sweden disconnects from TAI, clocks generated there will no longer be
considered "traceable". Don't do it!


> 4. Section 4.8:
>
>    clksrc = ntp / ptp / gps / gal / local / private
>
> I think this should ad a syntax element that make clear the syntax of a
> future extension shall have. An example:
>
>    clksrc = ntp / ptp / gps / gal / local / private / clksrc-ext
>
>    clksrc-ext = token ; token as in SDP
>
> The similar extensibility I think should exist in the following rules:
>
> ptp-version
> ptp-server
>

Added clksrc-ext.

>
> 5. Section 4.8:
>
> hostname      =  *( domainlabel "." ) toplabel [ "." ]
>
> Where is this rule taken from. I try to remember why you need a hostname
> to end on a ".".
>

This was taken from RFC 2396. '.' is the root in DNS names though it is
often omitted.

>
> 6. Section 4.8
>     port = 1*DIGIT
>
> I would recommend that we restrict the port number to 5 digits maximum
> length, i.e.     port = 1*5DIGIT
>
> Or do you see any need for totally unlimited number of digits?
>

This was taken from RFC 2396. We think it best to follow that model unless
there's a good reason to do otherwise.

>
> 7. I wonder if it should be more explicit that the a=clksrc attribute
> actually are defined to usage at the source (a=SSRC) level in the
> definition text by including a mention of source-specific and a ref to
> RFC 5576?
>

I added explicit discussion of "source level" in section 4.8. The "source
level" definition in section 3 includes a reference to RFC 5576.

>
> 8. Section 5.3:
>
>    In a given system, master clock identifiers must be unique.  Such
>    identifiers MAY be manually configured, however 17 octet string
>    identifiers SHOULD be generated according to the "short-term
>    persistent RTCP CNAME" algorithm as described in RFC6222 [7].
>
> I can see that a short term persistent is sufficient, but aren't it
> desired to actually use a long term persistent identifier for clock
> sources so that one can track their usage over different RTP sessions?
>
> A clock identifier is not the same thing as a CNAME. We're simply
borrowing the methods described in RFC 6222 to create a unique identifier.
As per RFC 6222, a long term CNAME may be a MAC address. The MAC address is
not a good clock identifier for a device that supports multiple clocks
through a single network interface. The short term identifier does not have
this problem.

9. Section 5.4:
>
>                mediaclock = refclk / streamid / sender
>
> I think the above ABNF syntax rules shall include a syntax definition
> for future extensions of the attribute.
>
> Added mediaclock-ext for this.


> 10. Section 4 and 5:
>
> The SDP attributes are lacking clear rules for interpretation in a SDP
> Offer/Answer context and thus also the declarative usage should be
> contrasted and clear.
>
> I have added a new signaling considerations section to the document.