Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)
draft-ietf-mmusic-ice-sip-sdp-39

Thank you for addressing my Discuss and Comment items.

I have nothing really to add, other than supporting Roman and Alissa's points.

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

Please use quotes around "0.0.0.0" and "::".

-- section 9.1.1 --

Typo in the contact email "esg@ietf.org"

-- Appendix A --

IPv6 addresses are usually all lower case :-)

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.

Thank you for addressing my Discuss (and Comment) points!

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.