A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (Trickle ICE)
draft-ietf-mmusic-trickle-ice-sip-18

[Ballot discuss]
Thanks to everyone who worked on this document. I have a couple of concerns that
need to be cleared up before the document can move forward.

---------------------------------------------------------------------------

§4.3.4 discusses the interaction of 3PCC with the trickle ICE mechanism.
Unfortunately, the diagrams used in this section do not show a 3PCC signaling
flow; they show a two-party call flow with an offerless INVITE. A 3PCC call flow
would necessarily involve a 3PCC controller sending an offerless INVITE to one
party, receiving an offer from that party (typically in a reliable provisional
response or in a 200 OK), and then sending an INVITE to the other party
containing that offer.

The text in this section matches the diagrams, and consequently does not appear
to be an analysis of 3PCC behavior. It is an analysis of two-party offerless
INVITE behavior.

If this section remains, it needs to be substantially re-worked: the diagrams
need to show three parties, with a 3PCC controller performing the controlling
role as described in RFC 3725. While I haven't stepped through the implications
for Trickle ICE when a controller is actually involved and is moving offers and
answers around between different message types, I suspect that the analysis in
here is substantially different once this starts happening.

I would personally be okay if the entire section were removed; however, I
have no desire to override working group consensus regarding the value of a
section dealing with 3PCC considerations.

[document reference issue removed -- this document will probably not need to change to address the issue]

[Ballot discuss]
Thanks for the well-written doc and the quick response to the initial tsv review. Also thanks to Jörg for the thorough and very helpful review!

As flagged by the tsv review, there can be an issue with the aggregation of candidates in one INFO message when rate limited and the path MTU/UPD fragmentation. While this is a small point only and I'm sure it can be easily addressed, it important enough that I decided to put a discuss in. I'm sure this can be resolved quickly as well.

Also if the document could give further guidance on an acceptable maximum for the rate of INFO requests that be even better!

[Ballot comment]
Editorial comments:

1) sec 4.3.2: "When sending the Answer in the 200 OK response to the INVITE request,
  the Answerer needs to repeat exactly the same Answer that was
  previously sent in the unreliable provisional response in order to
  fulfill the corresponding requirements in [RFC3264].  Thus, the
  Offerer needs to be prepared for receiving a different number of
  candidates in that repeated Answer than previously exchanged via
  trickling and MUST ignore the candidate information in that 200 OK
  response."
  What do I miss? Why can there be a different number of candidates if the repeated Answer needs to be exactly the same...? Or is there an "not" missing? Not an expert though, so might be just me...

2) I guess section 10.1 could also be moved to the appendix but it is short enough that leaving it in the body is fine as well.

[Ballot discuss]
Thanks to everyone who worked on this document. I have a couple of concerns that
need to be cleared up before the document can move forward.

---------------------------------------------------------------------------

§4.3.4 discusses the interaction of 3PCC with the trickle ICE mechanism.
Unfortunately, the diagrams used in this section do not show a 3PCC signaling
flow; they show a two-party call flow with an offerless INVITE. A 3PCC call flow
would necessarily involve a 3PCC controller sending an offerless INVITE to one
party, receiving an offer from that party (typically in a reliable provisional
response or in a 200 OK), and then sending an INVITE to the other party
containing that offer.

The text in this section matches the diagrams, and consequently does not appear
to be an analysis of 3PCC behavior. It is an analysis of two-party offerless
INVITE behavior.

If this section remains, it needs to be substantially re-worked: the diagrams
need to show three parties, with a 3PCC controller performing the controlling
role as described in RFC 3725. While I haven't stepped through the implications
for Trickle ICE when a controller is actually involved and is moving offers and
answers around between different message types, I suspect that the analysis in
here is substantially different once this starts happening.

I would personally be okay if the entire section were removed; however, I
have no desire to override working group consensus regarding the value of a
section dealing with 3PCC considerations.

---------------------------------------------------------------------------

The second issue doesn't necessarily pertain to this document per se as much
as it does the interaction among this document, draft-ietf-ice-trickle (Trickle
ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and draft-ietf-rtcweb-jsep
(JSEP). The problem doesn't lie with any single document, but in the overall
result of how they're currently structured.

JSEP (in the RFC editor queue) refers to the "a=end-of-candidates" SDP attribute
as appearing in Trickle ICE, section 9.3, which was true at one point in time.
Somewhere along the line, this attribute's definition was moved from there
into this document.

There are several ways to fix this, each with their own drawbacks:

1. Move the SDP syntax for "a=end-of-candidates" back into the Trickle ICE
  draft. Drawback: Trickle ICE does not currently define any normative SDP
  behavior; and, in fact, could work in a system that doesn't use SDP at all.

2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant from the
  perspective that ICE SDP defines SDP syntax for ICE in general (for both
  SIP and JSEP), and such a move aggregates all of the SDP syntax into a
  single document that is already necessary to reference from any document
  that uses SDP for Trickle ICE. Drawback: the document doesn't presently
  discuss Trickle ICE at all, and this would require a somewhat awkward
  section that basically says "If you use [Trickle ICE] with SDP, the syntax
  for the end-of-candidate marker is..."

3. Change JSEP to normatively depend on this document for the
  "a=end-of-candidates" syntax. Drawback: This document is extremely
  SIP-specific, while JSEP is based solely on RFC 4566 syntax and RFC 3264
  behavior, independent of any SIP semantics.  Forcing JSEP to normatively
  depend on a SIP specific document for a simple attribute syntax definition
  seems to be letting the tail wag the dog.

I believe that #2 is the least inelegant option, but I'm open to #1 and #3.
However, The *current* situation -- in which JSEP normatively points to a
document from which the text is cites has been removed out from under it -- is
clearly wrong.

[Ballot comment]
§4.1.4:

>  If the initial Answer included the attribute a=ice-options:trickle,
>  the Offerer MUST be prepared for receiving trickled candidates later
>  on.

I don't think this makes sense. If the initial *Offer* includes that option,
then the Offerer must be prepared to receive trickled candidates, even before
the Answer arrives. Figure 6 shows an example of this. I believe that the
paragraph I quote above needs to be entirely removed, as it may lead
implementors to incorrectly assume that they can't get trickled candidates prior
to an Answer.

---------------------------------------------------------------------------

§4.3:

>    o  The dialog at both peers MUST be in early or confirmed state.

This makes no sense. Dialogs exist in precisely two states, ever: early or
confirmed. Prior to "early," they don't exist. The only exit from "confirmed" is
destruction. (See RFC 3261 §12).

I think what this means to say is "A dialog MUST have been created between the
peers."

---------------------------------------------------------------------------

§4.3.2:

>  These retransmissions MUST
>  cease on receipt of an INFO request carrying a 'trickle-ice' Info
>  Package body or on transmission of the Answer in a 2xx response.

Why does this require that specific INFO to stop retransmission? The only
requirement is that the answerer knows that the offerer has received the
provisional response. The offerer cannot send post-INVITE requests to the
answerer until a dialog is established, and the only ways a dialog can be
established at the offerer is receipt of a provisional or final response. So, as
soon as you get *any* request from the offerer, you know that the provisional
response has arrived.

I think this passage means to say "These retransmissions MUST cease on receipt
of any in-dialog request from the offerer. The offerer cannot send in-dialog
requests until it receives a response, so the arrival of such a request proves
that the response has arrived."

---------------------------------------------------------------------------

§4.3.2:

>  The Offerer MUST send a Trickle ICE INFO request as soon as it
>  receives an SDP Answer in an unreliable provisional response.  This
>  INFO request MUST repeat the candidates that were already provided in
>  the Offer (as would be the case when Half Trickle is performed or
>  when new candidates have not been learned since then).

It is probably worth mentioning that it's possible that this INFO contains no
candidates, depending on how the offerer gathers its candidates and how long it
takes to do so.

---------------------------------------------------------------------------

§4.3.3:

>  These retransmissions MUST cease on receipt
>  of an INFO request or on transmission of the Answer in a 2xx
>  response.

Same comment as above for §4.3.2.

---------------------------------------------------------------------------

§4.3.4:

>  As specified in Section 4 this offerless INVITE
>  MUST include the SIP option-tag 'trickle-ice' in a SIP Supported:
>  header field in order to indicate support for Trickle-ICE to the
>  Offerer (at the User Agent Server (UAS)).

How does the 3PCC controller know to include this option tag? Is it simply
indicating that the 3PCC controller supports the Trickle mechanism? If so,
what happens if the second party (the one who receives the offer in an INVITE)
doesn't support Trickle ICE? This is one of the sharper corner cases that I
think arises when you go to fix the analysis I describe in my DISCUSS above.

---------------------------------------------------------------------------

§4.4:

>    a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998

Thanks for the IPv6 example; however, I have a *lot* of heartburn with the
selection of an example that demonstrates IPv6 NAT behavior. Since ICE's srflx
behavior is fundamentally tied to IPv4 NATs (and should not be an issue with
IPv6, as NATs are unnecessary), I think it's okay for the srvflx examples to go
ahead and show IPv4 addresses.

I *really* don't want to publish an RFC that demonstrates NATting of IPv6.

---------------------------------------------------------------------------

§4.4:

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

I finally did figure out what this meant, but it's confusing. The use of "any"
in the phrase "any pseudo 'm=' line" implies that the following sdpfrag would
qualify:

      a=ice-pwd:asd88fgpdd777uzjYhagZg
      a=ice-ufrag:8hhY
      m=audio 9 RTP/AVP 0
      a=mid:1
      a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host
      a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host
      a=end-of-candidates
      m=audio 9 RTP/AVP 0
      a=mid:2
      a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host
      a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host

The end-of-candidates *does* appear before the second pseudo "m=" line, which is
one of the lines (thereby satisfying the "any" criteria).

I think you mean "preceding the first pseudo 'm=' line..."

This is true later in the section also:

>  will not send any further candidates.  When included at session
>  level, i.e. before any pseudo "m=" line, this indication applies to

---------------------------------------------------------------------------

§4.4:

>  Note: At the time of writing this specification there were ongoing
>  discussions if a functionality for removing already exchanged
>  candidates would be useful.  Such a functionality is out of the scope
>  of this specification and most likely needs to be signaled by means
>  of a yet to be defined ICE extension, although it could in principle
>  be achieved quite easily, e.g. without anticipating any solution by
>  simply omitting a previously sent candidate from a subsequent INFO
>  request.  However, if an implementation according to this
>  specification receives such an INFO request with a missing candidate
>  it would have to treat that as an exceptional case.  Implementing
>  appropriate recovery procedures at the receiving side is advisable
>  for this situation.  Ignoring that a candidate was missing might be a
>  sensible strategy.

This seems like an interop nightmare. If you want a note about this possibly
being included in the future, please simply indicate that such an ability will
need to be explicitly signaled. Don't imply that implementations might get SDP
that violates the behavior defined in this document in some ill-defined way,
and just need to kind of gracefully deal with it, even if we don't really know
what it means at this point in time. There's no sensible way to code for that.

---------------------------------------------------------------------------

§4.4:

>    a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998
>    a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998
...
>    a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 9998
>    a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 9998

Same comment as above regarding IPv6 and NATs. Note that it would be Good and
Helpful to show SDP with a mixture of IPv4 and IPv6 anyway.

---------------------------------------------------------------------------

§5:

>  SIP User Agents (UAs) that support and intend to use trickle ICE are
>  required by [I-D.ietf-ice-trickle] to indicate that in their Offers
>  and Answers using the attribute "a=ice-options:trickle" and MUST
>  include the SIP option-tag "trickle-ice" in a SIP Supported: header
>  field.

Is this intended to imply that the option tag cannot be used in a Require header
field? I don't think that's a good idea; however, if that is the working group's
intention, please say so explicitly.

Suggest "...in a SIP 'Supported' or 'Require' header field."

---------------------------------------------------------------------------

§5.1:

This section discusses behavior in a walled garden. I'm generally fine with
this, as long as the failure modes when someone starts adding doors to the
walled garden are well-defined. I don't think this kind of provisioning is
okay unless it has a requirement that Offerers assuming Trickle ICE support
MUST include a "Require: trickle-ice" header field. That way, if the
provisioned assumption of Trickle ICE support ends up being incorrect, the
failure is (a) operationally easy to track down, and (b) recoverable by the
client (i.e.: they can re-send the request without the "Require" header field
and without the assumption of Trickle ICE support).

---------------------------------------------------------------------------

§6:

>  This INFO request indicates that the Answerer supports and uses RTP
>  and RTCP multiplexing as well.  It allows the Offerer to omit
>  gathering of RTCP candidates or releasing already gathered RTCP
>  candidates.

It's not clear how this "releasing already gathered RTCP candidates" interacts
with the requirement in §4.4:

>  In other words, the sequence
>  of a previously sent list of candidates MUST NOT change in subsequent
>  INFO requests and newly gathered candidates MUST be added at the end
>  of that list.

So, if I had already trickled candidates for the RTCP component of a connection
and *then* got an INFO from the Answerer indicating that it supports
multiplexing, does that mean I free the resources and exclude them from future
INFO messages? That seems to contravene the §4.4 requirement. Or do I free them
but continue to include them? I suppose that's okay (maybe?), but it's
extremely counterintuitive, and would need to be called out explicitly if you
expect implementors to get it right.

---------------------------------------------------------------------------

§7:

>  A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute
>  [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle-
>  ice-sdpfrag body if it supports and uses bundling.

This needs to clearly indicate that this needs to be included at the session
level (rather than the media level).

---------------------------------------------------------------------------

§7:

>  The Offerer can use this information e.g. for stopping the gathering
>  of candidates for the remaining "m=" lines in a bundle and/or for
>  freeing corresponding resources.

Same comment as for §6, above (regarding interaction with the requirement from
§4.4)

---------------------------------------------------------------------------

§7:

>      a=group:BUNDLE foo bar
>      a=ice-pwd:asd88fgpdd777uzjYhagZg
>      a=ice-ufrag:8hhY
>      m=audio 9 RTP/AVP 0
>      a=mid:foo
>      a=rtcp-mux
>      a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
>      m=audio 9 RTP/AVP 0
>      a=mid:bar

The presence of the second m= line here is confusing, given the following text
from §4.4:

>  Note, that there is no requirement that the Info request body
>  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 can be made via the
>  "a=mid:" attributes.

The §4.4 text strongly implies that it is nonsensical to include an m= section
without candidates. Is the example in §7 intended to imply that the section
needs to be included because its mid is mentioned in the "a=group:BUNDLE" line?
If so, please say so. If not, please remove the second m= section.

---------------------------------------------------------------------------

§9.2:

The syntax for "session-level-fields", "pseudo-media-descriptions", and
"trickle-ice-attribute-fields" include extremely strict rules around ordering of
fields (e.g., including ice-ufrag before ice-pwd would be syntactically
invalid). That level of strictness seems unlikely to lead to interoperable
implementations.

If the intention is to be rigid in this fashion, please add prominent prose
that warns implementors that fields MUST appear in the order specified, and
that all other orders are invalid and MUST be rejected.

If that's *not* your intention (and I suspect it isn't), then please fix the
syntax definition to allow for arbitrary ordering of attributes in the same way
as SDP does. For example:

    session-level-fields = *(session-level-field CRLF)

    session-level-field = bundle-group-attribute /
                          ice-lite-attribute /
                          ice-pwd-attribute /
                          ice-ufrag-attribute /
                          ice-options-attribute /
                          ice-pacing-attribute /
                          end-of-candidates-attribute /
                          extension-attribute-fields
                                ; for future extensions


---------------------------------------------------------------------------

§9.2:

The syntax for "session-level-fields" implies that "ice-pwd" and "ice-ufrag" are
mandatory at the session level. This seems to conflict with the text in §4.4:

>  The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
>  same level as the ones in the Offer/Answer exchange.  In other words,
>  if they were present as session-level attributes, they will also
>  appear at the beginning of all INFO request payloads, i.e. preceding
>  all pseudo "m=" lines.  If they were originally exchanged as media
>  level attributes, potentially overriding session-level values, then
>  they will also be included in INFO request payloads following the
>  corresponding pseudo "m=" lines.

The fix I propose above removes this implication that such attributes are
mandatory at the session level; however, if you choose to fix it some other way,
please ensure that the ABNF does not conflict with the normative language I
quote above.

---------------------------------------------------------------------------

§10.6:

Same comment as for §5 above.

---------------------------------------------------------------------------

§10.9:

>  If the INFO requests are sent on top of TCP, which is probably the
>  standard way, this is not an issue for the network anymore, but it
>  can remain one for SIP proxies and other intermediaries forwarding
>  the SIP INFO messages.  Also, an endpoint may not be able to tell
>  that it has congestion controlled transport all the way.

This seems kind of blithe about congestion control, as it concedes that the INFO
requests might end up on UDP at some point. Minimally, I would think that you
want to require some minimum quarantine period between INFO requests (probably
something in the range of 20 ms), during which any new candidates that are
gathered are aggregated into the next INFO message.

===========================================================================

Nits:

Expand "ICE" in the title.

---------------------------------------------------------------------------

draft-ietf-mmusic-ice-sip-sdp has undergone a major restructuring since version
16; as a consequence, all notes of the form:

>  [RFC EDITOR NOTE: The section 4.2.1.2.1 in above sentence is correct
>  for version 16 of said I-D.  Authors need to cross-check during
>  Auth48 since it could have have changed in the meantime.]

...are already out of date. It's probably worthwhile to fix these now, as they
are (in my opinion) quite unlikely to change again; and the current misdirection
makes it somewhat difficult to use the draft in its current form.

---------------------------------------------------------------------------

§4.1.3:

>  If the Answerer includes candidates in its initial Answerer, it MUST

"...initial Answer..."

---------------------------------------------------------------------------

§7:

>  A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute

Remove the space before "BUNDLE"

---------------------------------------------------------------------------

§11:

>  Trickle ICE uses two mechanism for exchange of candidate information.

"mechanisms"

[Ballot discuss]
  the Offer (as would be the case when Half Trickle is performed or
  when new candidates have not been learned since then).
IMPORTANT: They must be in order, right?

  'application/trickle-ice-sdpfrag' bodies do not interfere with the
  Offer/Answer procedures as specified in [RFC3264].
IMPORTANT: "pseudo" m= lines are not defined in 5888 so this is very unclear.

  sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in
  the same order as they were gathered.  In other words, the sequence
  of a previously sent list of candidates MUST NOT change in subsequent

IMPORTANT: This appears to conflict with the guidance in Section 6 of
the trickle document, which is about reordering candidates from how
they were gathered.

[Ballot comment]
  SIP message.  At the remote agent the gathering procedure is repeated
  and candidates are sent to the first agent.  Finally, a third phase
  starts where connectivity between all candidates in both sets is

This suggests that they have to happen in sequence, but that's not true.

  include in each "m="-line a "a=mid:" attribute in accordance to
  [RFC5888].

Why is this required?

  section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer
  is not yet provided.

Can you explain why you cease retransmitting on receiving INFO? I assume because it's an implicit ACK of your INFO?

  m=lines that they pertain to.  The correspondence can be made via the
  "a=mid:" attributes.

This whole section needs to be rewritten to make clear what's going on:

    candidates are grouped in sections headed by "pseudo" m=lines
    These sections contain a=mid values which point back to the true m=line.

[Ballot comment]
Section 5 has (and IIRC other places are similar):

  SIP User Agents (UAs) that support and intend to use trickle ICE are
  required by [I-D.ietf-ice-trickle] to indicate that in their Offers
  and Answers using the attribute "a=ice-options:trickle" and MUST
  include the SIP option-tag "trickle-ice" in a SIP Supported: header
  field.

It's a little strange to me to say that the core trickle spec mandates specifically the
"a=ice-options:trickle" attribute, which is only defined in this document.  The core
spec does mandate some form of indication, but maybe it is more clear to phrase as
something like:

  SIP User Agents (UAs) that support and intend to use trickle ICE are
  required by [I-D.ietf-ice-trickle] to indicate that support in their Offers
  and Answers.  For SIP, this is done using the attribute "a=ice-options:trickle", and
  the SIP option-tag "trickle-ice" MUST be included in a SIP Supported: header
  field.

In the scenario depicted in Figure 10, how is it indicated to Bob that Alice supports
trickle (and should that mechanism be indicated in the figure)?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-mmusic-trickle-ice-sip-12. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of [ RFC-to-be ], there are three actions which we must complete.

First, in the att-field (both session and media level) registry on the Session Description Protocol (SDP) Parameters registry page located at:

https://www.iana.org/assignments/sdp-parameters/

a single, new registration will be made as follows:

Type: att-field (both session and media level)
SDP Name: end-of-candidate
Mux Category: IDENTICAL
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Second, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a single, new media type will be registered as follows:

Name: trickle-ice-sdpfrag
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Third, in the Info Packages Registry on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new info package is to be registered as follows:

Name: trickle-ice
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC8126] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

Fourth, in the Option Tags registry also on the Session Initiation Protocol (SIP) Parameters registry page located at:

https://www.iana.org/assignments/sip-parameters/

a single, new option tag is to be registered as follows:

Name: trickle-ice
Description: This option tag is used to indicate that a UA supports and understands Trickle-ICE
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these three actions are the only ones required to be completed upon approval of [ RFC-to-be ].

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-01-26):

From: The IESG
To: IETF-Announce
CC: fandreas@cisco.com, ben@nostrum.com, draft-ietf-mmusic-trickle-ice-sip@ietf.org, mmusic@ietf.org, mmusic-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Session Initiation Protocol (SIP) usage for Trickle ICE) to Proposed Standard


The IESG has received a request from the Multiparty Multimedia Session
Control WG (mmusic) to consider the following document: - 'A Session
Initiation Protocol (SIP) usage for Trickle ICE'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-01-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The Interactive Connectivity Establishment (ICE) protocol describes a
  Network Address Translator (NAT) traversal mechanism for UDP-based
  multimedia sessions established with the Offer/Answer model.  The ICE
  extension for Incremental Provisioning of Candidates (Trickle ICE)
  defines a mechanism that allows ICE Agents to shorten session
  establishment delays by making the candidate gathering and
  connectivity checking phases of ICE non-blocking and by executing
  them in parallel.

  This document defines usage semantics for Trickle ICE with the
  Session Initiation Protocol (SIP) and defines a new SIP Info Package.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ivov-mmusic-sdpfrag: Internet Media Type application/sdpfrag (None - )
    draft-ietf-mmusic-rfc5245bis: Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal (None - IETF stream)

These are my AD Evaluation comments for draft-ietf-mmusic-trickle-ice-sip-11. I have quite a few comments, and would like to resolve at least the substantive comments prior to IETF Last Call.
*** Substantive:

- The draft needs a "deployment considerations" section relating to the
presence of middleboxes that may not be aware of trickle ice. I recognize
that b2bUAs may simply be endpoints that don't do trickle, but I wonder about
monitoring devices, etc. Even if the answer is "there is no impact", some
substantiating text would be helpful.

-3.2: There seem to be some inconsistencies on how the text talks about the
architectural model. For example, section 3.2 separates the "ICE agent" from
the "offer/answer" module, but 3.3 talks about a "trickle ICE agent" doing
offer/answer. (I suspect this is a terminilogy issue where "trickle ICE
agent" as the user agent and "ICE agent" as a software module are too easily
confused.)

4.1.1: What is the motivation for requiring "audio" in the M-line when one
does not know any candidates in advance? What if the intended media is not
audio? I don't understand why the lack of advance candidates would change
that. (Maybe this is an artifact of the pseudo-M-lines from the INFO bodies?)

-4.1.1, 2nd to last paragraph : "... it still MUST include the "a=rtcp-mux"
and/or "a=rctp-mux-only" attribute in the initial Offer."
IIUC, that's an already existing requirement from the referenced spec. If so,
please do not use 2118/8174 keywords to describe it here, unless in the form
of directly quoted text.

-4.2.2, RFC editor note:
This askes the RFC Editor to do research. I don't think that's a reasonable
expectation. They may notice that sort of thing anyway, but the authors
should plan to recheck references during AUTH48. (This comment applies to
several other similar RFC editor notes.)

-4.2.2, third paragraph after Fig 4: "or when new candidates have not been
learned since then) and/or they MAY also deliver newly learned candidates (if
available).  The Offerer MAY include an end-of-candidates attribute in case
candidate discovery has ended in the mean time."

Are those MAYs really correct when the conditions are true? E.g. if you have
newly learned candidates, there's only a MAY requirement to add them?
Likewise, if discovery has ended, there's only a MAY requirement to add the
end-of-candidates attribute?

-4.2.2, 4th paragraph after fig 4: " and MAY begin trickling"
that seems like a statement of fact rather than a normative
offering-of-permission.

-4.2.2, last paragraph: "... Answerer MUST repeat exactly the same Answer..."
Is that an external requirement, or a new normative one?

-4.2.3, first paragraph: "Trickle ICE Agents MAY therefore respond to an
INVITE request with provisional responses without an SDP answer"
That's only if the offerer indicated support for trickle ICE, right?

-4.3: It seems like the use of SDP syntax in the INFO messages creates quite
a bit of complexity due to the use of SDP in (even more) ways not
contemplated by it's design. Did the WG discuss the possibility of using a
designed-for-purpose syntax in the INFO bodies?  (This is just my curiosity;
I don't expect to make that sort of fundamental change this late in the
process.)

-4.3: Discussion of "pseudo-M-lines":
A complete separation of the trickle-ice from offer/answer seems unlikely to
me, since both must send and receive SIP messages in the same dialog. Is it
that much harder to remember the media type than it is to remember dialog
state?  More to the point, are there known implementations that require this?

-4.3, last bullet: "The fmt SHOULD appear only once..."
Why not MUST? Would it every be reasonable to include more than one?

-4.3, paragraph starting with : "Note that [I-D.ietf-ice-trickle] requires
that when candidates are trickled, each candidate MUST be delivered..."
Don't use 2119/8174 keywords to describe external requrements, except in
directly quoted text.

-4.3: 2nd paragraph prior to Fig 9:
Are the discussions about removing previously exchanged candidates still in
process? IMO, the "MAY" and "RECOMMENDED" in this paragraph refer to
requirements that are too vague to state in normative terms.

- figure 9 (and other figures including INFO bodies): Please include a real
content-length value.

-5, first paragraph: Please don't use normative terms to describe external
requirements.

-5.1, first paragraph:
I'm confused by the reference to WebRTC clients. These are not assumed to use
SIP at all. How are they relevant examples?

-5.2: IIUC, using the GRUU means the INVITE can go only to that particular
device. This seems to circumvent the recipient's ability to use forking for
their own purposes. That's not a showstopper, but it deserves mention.

-5.3: The comparisons to XMPP don't seem to add much, and seems like
editorializing. (Also in 3.1). The fact that XMPP has more advanced discovery
mechanisms is not particularly relevant unless you want to use those as an
example of how to solve the problems in SIP.

-6, 6th paragraph: "The Trickle Answerer MUST follow the guidance
  on the usage of the "a=rtcp" attribute as given in
  [I-D.ietf-mmusic-ice-sip-sdp] and [RFC3605]"
External requirement...

-8.2, first paragraph: External requirement.

-9: Please comment about whether this media type is reasonable to use for
other SDP related applications? I gather the answer is "no" given that it's
called "trickle-ice-sdpfrag".

-9.2, first paragraph: "A sender SHOULD stick to lower-
  case for such grammars, but a receiver SHOULD treat them case-
  insensitive."
Why is the second SHOULD not a MUST?

- 10.7: The requirement to include the payload only applies to INFO requests
for this particular package, right? That is, not necessarily "all INFO
requests".

- 10.9: You used the need to pool candidates as a argument against using
update. Doesn’t this create the same requirement? Also, do you think it
reasonable that an implementation might not be concerned about this?

-11.2: Please use the IESG (iesg@ietf.org) for the change control authority.
The mmusic mailing list could be closed some day.

-12: The registered media type refers to this document for security
considerations, but I don't see any considerations specific to it here.


*** Editorial and Nits:

- General: IDNits shows some outdated references. Please fix before final
published version.

- section 1, paragraph 1:

The sentence structure for listing the 3 phases is odd. The first two are in
a comma separated list, but the third is in a separate sentence. I suggest
breaking all 3 into separate sentences, with the needed connecting words.

Missing "and" before "the second phase"

I think the word "latency" would be better expressed as "delay" or "setup
delay", etc. Too many readers are going to think of "latency" in terms of
network latency (i.e packet delivery).

- 1, paragraph 2: "simultaneously"
I think the operating idea is that they can happen in "parallel" or "be
interleaved".

-2: Please use the new boilerplate in RFC 8174, unless you specifically want
lower case versions of the RFC 2119 keywords to be interpreted in their 2119
sense.

-2, 2nd paragraph: "This specification makes use of all terminology..."
I suggest removing "all".

-3.2, first paragraph:
I think "the exception of the actual INFO messages," is too big of an
exception for this paragraph to be meaningul. For example, this is a huge
change for middleboxes that pay attention to the SDP (e.g. SBCs); I think
saying that things "would look the same" is an overstatement.

-4, item 5: "Note that in case of forking multiple early dialogs will exist."
s/will/may (or "might" if you want to avoid "may")

-4.1.1, 2nd paragraph: "...before knowing any candidate of one or more media
descriptions..."
s/of/for

-4.1.1, last paragraph: This seems redundant to the similar statement in
section 4, item 2.

-4.1.2, last paragraph:
s/neither/none (unless you expect there to be exactly 2 trickled candidates.)

-4.2.1, title (and several related titles):
I think that usage of "asserting" will trip up some users. Consider
"establishing" instead.

- Figure 3: This figure needs a comment about the meaning of "+SRFLX Cand.",
similar to those for later figures.

-4.2.3, first paragraph:
s/possibility/ability

-4.2.3, paragraph after Fig 6: "When sending the Answer, the agent MUST
repeat all currently known and used candidates, if any, and MAY include all
newly gathered candidates since the last INFO request was sent.  If that
Answer was sent in a unreliable provisional response, the Answerers MUST
repeat exactly the same Answer in the 200 OK response to the INVITE request
in order to fulfill the corresponding requirements in [RFC3264]."

This seems self contradictory, but could be fixed with some connecting
language like "However", or "An exception..."

-4.2.4, title: Spell out 3PCC on first mention. Also, an informational
citation would be helpful.

-4.3, 3 paragraphs prior to Fig 9: "is an indication of the peer agent that
it will not send any further candidates"
s/of/from

-4.3, last paragraph before Fig 9: Please refer to the figure by number
rather than relative position.

-5.2, title: Expand "GRUU" on first mention.
First paragraph: s/"SIP US"/"SIP UA"
"... require SIP support" - Should that say "trickle ICE support"?
2nd paragraph: Please define "targeted trickling"

-7, 4th paragraph: I don't understand the meaning of "latest on..." in this
context.

-7, paragraph between "offer" and "INFO" examples: "Once the dialog is
established as described in section Section 4.2 the Answerer sends the
following INFO request."
The word "section" is repeated.

-9.2, first paragraph: "It specifies the subset of existing SDP attributes,
that are needed..."
s/are/is  (the phrase constrains "subset", not "attributes").

"The grammar uses the indicator for case-sensitivity %s is defined in
[RFC7405], but also imports grammars for other SDP attributes that precede
the production of that RFC. "
I can't parse that sentence.

- 10.1, 2nd paragraph: s/introduces/"would introduce"
3rd paragraph: s/"one exchange"/"one active exchange"

- 11.2: Weird line spacing.
"Applications which use this Media Type:
The listed applications only use this media type when using trickle-ice,
right? Would it make sense to just include "trickle-ice"?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard. The document indicates Standards Track on the front page, which is appropriate.


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The Interactive Connectivity Establishment (ICE) protocol describes a Network Address Translator (NAT) traversal mechanism for UDP-based multimedia sessions established with the Offer/Answer model.  The ICE extension for Incremental Provisioning of Candidates (Trickle ICE) defines a mechanism that allows ICE Agents to shorten session establishment delays by making the candidate gathering and connectivity checking phases of ICE non-blocking and by executing them in parallel.

This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP) and defines a new Info Package as specified in [RFC6086].


Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

The document has been a WG document since 2014, where it saw significant interest in the WG. The documen has since then undergone several changes as a result of WG feedback, however none of those have been controversial.


Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

We have not received information about current implementations, however the document is a companion document to draft-ietf-ice-trickle, which is a normative dependency for the W3C WebRTC specification.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

Flemming Andreasen is the Document Shepherd
Ben Campbell is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have reviewed -08 in detail (which resulted in a few updates) as well as the most recent versions. The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

Earlier versions of the document saw decent WG participation and review, however there has been very little review and feedback since the -07 version. The WGLC in particular did not produce any feedback (positive or negative).


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document defines a new Media Type, and a request for review was sent out on October 12, 2017 (no feedback received as of November 14, 2017).

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Each author has confirmed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Earlier versions of the document saw decent WG participation and good WG consensus. More recent versions have seen very little feedback (but there are no known concerns either).


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

The document defines a new Media Type. A request for review was sent to media-types@iana.org on October 12, 2017. As of November 14, 2017, no feedback has been received. 

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

- [I-D.ietf-ice-trickle] has undergone WGLC (in the ICE WG) and is expected to move to Publication Request soon
- [I-D.ietf-mmusic-ice-sip-sdp] has undergone WGLC. A minor update is expected after which it will move to Publication Request
- [I-D.ietf-mmusic-mux-exclusive] is in the RFC Editor Queue
- [I-D.ietf-mmusic-rfc5245bis] is in the process of moving to Publication Request
- [I-D.ietf-mmusic-sdp-bundle-negotiation] is nearing completion.
- [I-D.ietf-mmusic-sdp-mux-attributes] is in the RFC Editor Queue


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

Reviewed and confirmed.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF has been verified with Bill Fenner's ABNF parser.