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

(Richard Barnes) Yes

(Spencer Dawkins) Yes

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.

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

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

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection