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

[Magnus Westerlund <[e-mail]>]

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.

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.

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.

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

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 ".".

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?

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?

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?

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.

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.


But, I think this document is shaping up nicely and the authors are
doing an excellent work with it. So lets get these last things settled
so that we can last call it.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------