Ballot for draft-ietf-avtcore-rtp-v3c
Yes
No Objection
Abstain
No Record
Summary: Has enough positions to pass.
Thank you to Carl Wallace for their secdir review. Recently (Dec 2025) I balloted on draft-ietf-avtcore-rtp-haptics. The comment I made on their Security Considerations was this: "Section 9, para 3: While RFC7201 does give options to an application developer for security mechanisms, it is a bit old at this point. Most of the options listed have migrated to stronger versions. For example TLS1.2 (RFC 5246) is on the verge of obsolescence. BCP 195 (includes RFC 9325 and eventually draft-ietf-uta-require-tls13) provides the most current guidance for using the (D)TLS protocols. For IPsec, RFC 4301 is an architecture specification, the actual protocols are RFC 4303 and RFC 7296. I wouldn't recommend putting all of this in the draft. I do think that there needs to be a statement that 'appropriate, current, strong security mechanisms' with a disclaimer that RFC 7201 is dated... The easiest thing to point to is RFC 9325, if you want something specific. I'm happy to help with the wording." For the current draft, Section 11: I recommend that the authors of this draft look at what was written in the haptics draft, and make a similar update (as it is appropriate). Again, I'm happy to help, if you need.
Thank you for resolving my discuss observation. https://mailarchive.ietf.org/arch/msg/avt/fDh3dN2sNKdDkoxpynTefsKnkp0/
Thanks to the authors and the WG for their work on this document. I have some minor comments to share: 1) Please delete the duplicate BCP14 boilerplate below: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2) Except for the following sentence that is a normative behavior, all the rest contents of section 7.1 seem to belong to section 10.1 under the IANA consideration section. The receiver MUST ignore any parameter unspecified in this memo. Similarly, a significant portion of the IANA considerations under 10.2 and 10.3 are place in the main body of the document which is contravenes RFC8126 - https://datatracker.ietf.org/doc/html/rfc8126#section-1.1
Hi Lauri, all, Thank you for the discussion and for the changes made in -16. The latest version [1] adequately addresses the comments in my previous ballot [2]. Cheers, Med [1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-avtcore-rtp-v3c-15&url2=draft-ietf-avtcore-rtp-v3c-16&difftype=--html [2] https://mailarchive.ietf.org/arch/msg/avt/FLTTOIWlai8q9EdZr-ivAR4Eq-4/
Thank you to Lars Eggert for the GENART review. ** Section 7.1. This section appears to be mixing guidance for the specification (for the "receiver") and the guidance to IANA (at this section is invoked by reference from 10.1). Please remove RFC2119 key words from the guidance to IANA in this section per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/.
Thanks for the work done in this document, I am balloting ABSTAIN because I find the new text in 5.3 still a little unclear, e.g., who and when the bit is set to 1. But, at least the text is no more self-contradicting. Previous DISCUSS ballot is at: https://mailarchive.ietf.org/arch/msg/avt/UXfPkbWbC8PRcOAJcXPhko3vJ40/ -éric