Skip to main content

RTP Clock Source Signalling
draft-ietf-avtcore-clksrc-11

Yes

(Richard Barnes)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Sean Turner)
(Stewart Bryant)

Note: This ballot was opened for revision 09 and is now closed.

Richard Barnes Former IESG member
Yes
Yes (for -09) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2014-02-05 for -09) Unknown
For a readable doc about NTP AND SDP ... you win the Internet for the day.

I did have a couple of comments. Please consider them along with any other feedback you receive.

It might or might not belong in an IETF spec, but if there was a pointer to how

4.3.  Identifying PTP Reference Clocks

   Each IEEE 1588 clock is identified by a globally unique EUI-64 called
   a "ClockIdentity".  

"globally unique" is ensured, I would have been less curious ...

In 7.  Security Considerations

   Entities receiving and acting upon an SDP message SHOULD be aware
   that a session description cannot be trusted unless it has been
   obtained by an authenticated transport protocol from a known and
   trusted source.  

I'm thinking that's not an RFC 2119 SHOULD.
Adrian Farrel Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2014-02-06 for -09) Unknown
- s7: Your 2119 SHOULD statements seem a bit bogus as they
don't really translate into what a coder can do but I'm ok
with that.

- s7: Would it be worthwhile saying that even if you do
connect to a time source, you shouldn't use that to adjust
your system clock (as opposed to using it to sync some RTP
stuff), and if you did, then someone having a video call
with you could e.g.  cause you to accept a revoked public
key certificate and other potential badness? I suppose many
devices these days don't allow system clock changes without
user interaction, but some e.g. TVs perhaps might not get
that right if running on some home-grown operating system.
Stewart Bryant Former IESG member
No Objection
No Objection (for -09) Unknown