I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. Document: draft-ietf-mmusic-trickle-ice-sip-12 Reviewer: Dale R. Worley Review Date: 2018-01-23 IETF LC End Date: 2018-01-26 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. This draft is technically quite good, and except for various nits, quite well written. But there are some significant technical issues that need to be properly settled before the protocol is well-defined with good advice on robust usage. I don't think settling these issues will be difficult. ** Global/major issues: * The tokens "end-of-candidate" and "end-of-candidates" seem to be used equivalently in this document, with the following number of uses: 11 end-of-candidate 19 end-of-candidates Which is the correct form? * The definition of application/trickle-ice-sdpfrag describes the use of "a=charset" as an attribute, but the grammar of sdpfrag in section 9 does not permit that attribute. * Deployment considerations (section 11) It might be worth mentioning here what happens if a middlebox deletes Trickle ICE INFO requests because it does not understand them, but does not delete "Supported: trickle-ice" headers. It seems to me that in order to be robust in this situation, a UA should provide a globally routable address in the m= lines of the initial offer or answer, or if Trickle ICE INFO requests fail, eventually amend the addresses to be globally routable addresses. But the WG may have more knowledge about this situation. * There are various locations where the language has usages that seem to me to be excessively informal or prolix. Cases I've noticed are: 2. Terminology It is assumed that the reader will be familiar with the terminology from both documents. Probably s/will be/is/. 3.1. Discovery issues Such Offers and Answers can only be handled meaningfully by agents that actually support incremental candidate provisioning, which implies the need to confirm such support before actually using it. It's probably best to omit "actually" here and elsewhere. There is also a use of "right from the first Offer". And in some places "would" is used where it is not needed or could be replaced by "do"; "would" should (IMO) be restricted to situations that are counter-factual. There is also a use of "like for example" instead of "for example". I expect the RFC Editor can give guidance on this subject. ** Detailed/editorial/nits: A Session Initiation Protocol (SIP) usage for Trickle ICE draft-ietf-mmusic-trickle-ice-sip-12 The current practice is to capitalize "usage" in this situation. (I expect the RFC Editor can give guidance on the current capitalization style for RFCs.) Abstract This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP) and defines a new SIP Info Package. Perhaps /a new SIP Info Package/a new SIP Info Package to support this usage/. Table of Contents The capitalization of section titles seems to be inconsistent. 1. Introduction It describes how ICE candidates are to be exchanged incrementally with SIP INFO requests [RFC6086] Probably s/exchanged incrementally with/exchanged incrementally using/, as "with" can be read to mean that the SIP INFO requests are one party which is exchanging. 4. Incremental Signaling of ICE candidates The following sections provide further details on how Trickle ICE Agents perform the initial Offers/Answers exchange (Section 4.1), perform subsequent Offers/Answers exchanges (Section 4.2) and establish the INVITE dialog usage (Section 4.3) such that they can incrementally trickle candidates (Section 4.4). I think you want to change "Offers/Answers" to "Offer/Answer". 4.3.1. Establishing dialog state through reliable Offer/Answer delivery It was stated in section 4.1, "Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag 'trickle-ice' in a SIP Supported: header field within all SIP INVITE requests and responses.", but it would be helpful to remind the reader in figure 3 by showing the Supported: headers: Alice Bob | | | INVITE (Offer) | | Supported: trickle-ice | |--------------------------->| | 183 (Answer) | | Supported: trickle-ice | |<---------------------------| and similarly in later figures. Something similar might be done with the "SRFLX Cand." elements to make the figures less cramped. 4.3.2. Establishing dialog state through unreliable Offer/Answer These retransmissions MUST cease on receipt of an INFO request or on transmission of the Answer in a 2xx response. Strictly, "a trickle-ice INFO request", as other INFO requests might be received as part of other mechanisms. 4.3.4. Considerations for Third Party Call Control The peer Trickle ICE Agent (the UAC) MUST send a Trickle ICE INFO request as soon as they receive an unreliable provisional response (see Figure 8). s/they receive/it receives/ 4.4. Delivering candidates in INFO messages Agents MUST include a pseudo "m=" line and an identification tag in a "a=mid:" attribute for every "m=" line whose candidate list they intend to update. Such "a=mid:" attributes MUST immediately precede the list of candidates for that specific "m=" line. All "a=candidate" or "a=end-of-candidates" attributes following an "a=mid:" attribute, up until (and excluding) the next occurrence of a pseudo "m=" line, pertain to the "m=" line identified by that identification tag. An "a=end-of-candidates" attribute, preceding any pseudo "m=" line, indicates the end of all trickling from that agent, as opposed to end of trickling for a specific "m=" line, which would be indicated by a media level "a=end-of-candidates" attribute. This seems to be the first section that involves the detailed structure of trickle-ice INFO messages. It would probably be useful here to tell the reader that there is a grammar in section 9. This paragraph is very dense and you should see if you can split it in some way. In particular, I think it is possible to separate the first part, which discusses the structure of the sdpfrag, from the second part, which specifies how the pseudo m= lines in the sdpfrag correlate with the m= lines in the offer/answer. In addition, it seems to me that there is no requirement that the sdpfrag contains as many pseudo m= lines as the offer/answer contains m= lines, nor that the pseudo m= lines be in the same order as the m= lines that they pertain to (the correspondence being made via the mid attributes). Since this is very different from the semantics of SDP proper, I think it should be pointed out explicitly. 5. Initial discovery of Trickle ICE support This makes discovery fairly straightforward for Answerers or for cases where Offers need to be generated within existing dialogs (i.e., when sending UPDATE or re-INVITE requests). In both scenarios prior SDP would have provided the necessary information. I think you need to expand this to note that INVITE requests are required to include "Supported: trickle-ice" if the UA supports Trickle-ICE. This is important because a UA may receive an offerless re-INVITE as part of initiating a 3PCC -- the peer UA may be attempting to connect media between the UA and a third UA, and the third UA may not support Trickle ICE, even though the peer UA does. (See, e.g., RFC 3725 section 4.1 and RFC 7088 section 2.3.) In this situation, the offerless re-INVITE would not contain "Supported: trickle-ice" unless the peer UA knows that the third UA supports Trickle-ICE. The UA, seeing the absence of "Supported: trickle-ice", would send a non-Trickle-ICE offer, even if the previous SDP had indicated support for Trickle-ICE. 5.1. Provisioning support for Trickle ICE While the exact mechanism for allowing such provisioning is out of scope here, this specification encourages trickle ICE implementations to allow the option in the way they find most appropriate. What is "the option"? Perhaps "such provisioning". 5.2. Trickle ICE discovery with Globally Routable User Agent URIs This circumvents to use of forking for that request. I think you want s/circumvents to/prevents the/. 5.3. Fall-back to Half Trickle Figure 11 seems to be incorrect -- since Alice is using Half-Trickle ICE, all her candidates are sent in the INVITE, and she shouldn't send any INFO requests. But an INFO request from Alice is shown. 6. Considerations for RTP and RTCP multiplexing INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/sdp Content-Disposition: Info-Package Content-length: 161 Shouldn't this be "Content-type: application/trickle-ice-sdpfrag"? 7. Considerations for Media Multiplexing INFO sip:alice@example.com SIP/2.0 ... Info-Package: trickle-ice Content-type: application/sdp Content-Disposition: Info-Package Content-length: 219 Shouldn't this be "Content-type: application/trickle-ice-sdpfrag"? 9.2. Grammar A sender SHOULD stick to lower- case for such grammars, but a receiver MUST treat them case- insensitive. This is awkward. Perhaps better is "A sender SHOULD use lower-case for attributes from such earlier grammars, but a receiver MUST treat them case-insensitively." I don't know the practice regarding the overall grammar of SDP, but the grammar shown here is very rigid regarding the order of fields in and in . If this rigidity is not intended, there should be some notation on the grammar to show this. 10.1. Rationale - Why INFO? The decision to use SIP INFO requests as a candidate transport method is based primarily on their lightweight nature. Once a dialog has been established, INFO requests can be exchanged both ways with no restrictions on timing and frequency and no risk of collision. On the other hand, using Offer/Answer and UPDATE requests [RFC3311] would introduce the following complications: A critical fact is that the sending of Trickle ICE candidates in one direction is entirely uncoupled from sending candidates in the other direction. Thus, the sending of candidates in each direction can be done by a stream of INFO requests that is not correlated with the stream of INFO requests in the other direction. And since each INFO request is cumulatively includes the contents of all previous INFO requests in that direction, ordering between INFO requests need not be preserved. All of this permits using largely-independent INFO requests. Contrarily, UPDATE or other offer/answer mechanisms assume that the messages in each direction are tightly coupled with messages in the other direction. 12.2. application/trickle-ice-sdpfrag Media Type This section defines a new Media Type 'application/trickle-ice- sdpfrag' in accordance with [RFC6838]. s/This section/This document/ -- as in section 12.2. This section should refer to the grammar of section 9 as the definition of the media type content. SDP files are primarily UTF-8 format text. The content of application/trickle-ice-sdpfrag is not SDP, strictly speaking. And as noted later in the document, not all of them are UTF-8. I think you want something like this: The media contents follow the same rules as SDP, except as noted in this document. The media contents are text, with the grammar specified in section 9. Then continue with "Although the initially ...", which describes the character set implications of "are text". The "a=charset:" attribute may be used to signal the presence of other character sets in certain parts of a trickle-ice-sdpfrag body (see [RFC4566]). Except that "a=charset" is not permitted by the grammar of section 9. [END]