RTP Clock Source Signalling
RFC 7273
Note: This ballot was opened for revision 09 and is now closed.
(Richard Barnes) Yes
(Spencer Dawkins) Yes
Comment (2014-02-05 for -09)
No email
send info
send info
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
Comment (2014-02-06 for -09)
No email
send info
send info
- 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.