Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment (ICE)
Note: This ballot was opened for revision 36 and is now closed.
Alissa Cooper (was Discuss, Yes) Yes
Comment (2019-08-09 for -38)
Thanks for addressing my DISCUSS. Previous comments are still below. Note that the "Obsoletes" header still appears although I thought Christer said he had removed it. ----- Since RFC 5245 is already obsolete, this document cannot obsolete it I don't think. RFC 8445 references this document, so readers of that document will be able to find this one. Section 2: Please use the precise boilerplate from RFC 8174. Section 4.1: It's not clear why IESG Approval is included as one of the registration policies to extend the candidate attribute. Does the WG anticipate cases where IETF Review will not be appropriate? And I agree with Alexey that a registry needs to be defined in the IANA Considerations section. Section 8: Agree with Ben about adding references to ICE and SDP security considerations. Section 9.1.1: email@example.comfirstname.lastname@example.org/ Section 9.2: Further to Alexey's point, the minimal information necessary for the registry to function should be collected and/or published.
Adam Roach Yes
Deborah Brungard No Objection
Roman Danyliw (was Discuss) No Objection
Thank you for addressing my Discuss and Comment items.
Benjamin Kaduk (was Discuss) No Objection
Thank you for addressing my Discuss (and Comment) points!
Suresh Krishnan No Objection
Warren Kumari No Objection
Comment (2019-08-06 for -37)
I have nothing really to add, other than supporting Roman and Alissa's points.
Mirja Kühlewind No Objection
Comment (2019-08-05 for -37)
1) First I have a processing question for the IESG (and maybe the RFC editor) but it might be just me not knowing this: As I understand it, RFC5245 was spilt up into RFC8445 and this document, however, I find it a bot odd that both documenst obsolete RFC5245. Is that what we usually do? Did we have this case before? Is that the right thing to do? 2) One quick question: Why is a port value of "9" used to signal use of the default destination, instead of e.g. "0"? Is that because port "0" is used to reset the data stream? However, couldn't this combination of address and port "0" not be treated differently? Or is that to avoid any potential false connections? How could that happen? Isn't there a better way to do that? I mainly would like to understand what the reason is and maybe request to also explain this in the document. 3) A minor editorial comment Sec 4: "This specification defines eight new SDP attributes" Given these attributes have already been specified in RFC5245, I wouldn't call them "new". 4) Question on sec 4.1: " <transport>: indicates the transport protocol for the candidate. This specification only defines UDP. However, extensibility is provided to allow for future transport protocols to be used with ICE by extending the sub-registry "ICE Transport Protocols" under "Interactive Connectivity Establishment (ICE)" registry." The registry also contain an entry for TCP (see RFC6544). However, I also wonder a bit why a new registry was created initially instead of just using the protocol numbers or keyword in the IANA Protocol Numbers Registry...? 5) A request in section 5.4: "If absent in an offer and answer the default value of the attribute is 50 ms, which is the recommended value specified in [RFC8445]." RFC8445 also specifies a minimum of 5ms (MUST). It would be good to also indicate here that this minimum exists without relying on the user to look up RFC8445. 6) Also further on in section 5.4: "Once both agents have indicated the pacing value they with to use, both agents MUST use the larger of the indicated values." Given this in normatively specified in RFC8445, maybe you should not use normative language in this document but provide in addition again a reference to RFC8445. 7) And similar on the use of MUST in section 5: "The keepalives MUST be sent regardless of whether the data stream is currently inactive, .." This is specified in RFC8445, so maybe consider not using normative language here as well... however, this case is maybe less clear. 8) You probably should explicitly instruct IANA in the IANA consideration section to update the references to this RFC instead of RFC5245 in the respective registry.
Barry Leiba No Objection
Alexey Melnikov (was Discuss) No Objection
As per my response to the mailing list, section 10.2 and 10.3 might benefit from having Contact and Change Controller in the registration template.
Alvaro Retana No Objection
Éric Vyncke No Objection
Comment (2019-08-03 for -37)
Thank you for the work put into this document; I just have a couple of comments and some nits. All easy to fix. Regards, -éric == COMMENTS == -- Section 3.2.4 -- Please add reference to STUN. -- Section 3.2.6 -- The example would benefit by having an IPv6 candidate. Same applies for section 4.2. -- Section 4.1 -- It is not clear to me whether FQDN are valid: they are accepted by the grammar but they are rejected in the text. == NITS == -- Section 18.104.22.168.1. -- Please use quotes around "0.0.0.0" and "::". -- section 9.1.1 -- Typo in the contact email "email@example.com" -- Appendix A -- IPv6 addresses are usually all lower case :-)