Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
draft-ietf-mmusic-ice-19

[Ballot discuss]
This is a great document and a much needed function.
While the protocol is complex, the specification is
well written and solid.

I do have a few issues or question marks, however:

1. (Resolved)

2. (Resolved)

3. I worry about the 18.5.2 amplification attack. 100 tests limit
  and no mandatory limit on number of candidates worries me.
  Is there a possibility to make this stricter? What data
  are the suggested numbers based on?

  The new text in -18 is much better, thanks. However,
  I would prefer making the ability to
  configure this a mandatory feature. I.e., s/SHOULD/MUST/.
  I don't care so much what the value is, as long as we can go
  in later and change the values if this turns out to be a real
  attack vector.

[Ballot discuss]
I have cleared the first part of my initial DISCUSS and left with this:

The document is missing information related to operational considerations and manageability. Specifically I could not find information about:
- strategy of deployment - how an installation should be started, are there any NAT configurations that should be avoided, are there any recommended default configuration parameters, any information on scalability?
- Are mixes of ICE and ICE-lite expected to work, what are the limitations?
- impact on the network traffic level - how much bandwidth would the keep-alive message for each session consume? any limits and default settings to be considered at installation?
- observability - how does a network manager know that discovery is completed and his ICE deployment works? Any hooks in the protocol to help debug a situation when something goes wrong?
- Section 16 - when saying Ta and ST0 should be configurable - is this implying there needs to be some out-of-band configuration interface, or is this all automatic computation performed by agents?

[Ballot discuss]
This is a great document and a much needed function.
While the protocol is complex, the specification is
well written and solid.

I do have a few issues or question marks, however:

1. Why does Section 4.2 (lite) mention RF 3484, but
  Section 4.1 (full) does not? Wouldn't RFC 3484 algorithms
  be appropriate input for the prioritization of address pairs?
  (or inappropriate to not take the input?)

2. There are several places in the document with an apparent
  assumption that interface = address. It does not hold when
  you are dual-stack, and does not even hold for IPv6 as
  you may have multiple addresses and multiple types of
  addresses. Some places:

    Section 2.1: "If an agent is multihomed, it obtains a
    candidate from each interface."

    Section 4.1.1.1: "If an agent is using both RTP and RTCP,
    it would end up with 2*K host candidates if an agent has
    K interfaces."

3. I worry about the 18.5.2 amplification attack. 100 tests limit
  and no mandatory limit on number of candidates worries me.
  Is there a possibility to make this stricter? What data
  are the suggested numbers based on?

[Ballot comment]
There were some bug fixes to -17 by Adam Fisk and others on the MMUSIC list that JDR said he'd include - is an RFC Editor Note with those missing? Is the plan to have this go to "revised ID needed" to incorporate these?


There was a comment on the MMUSIC list about the length of username fields: "I am not sure 1023 character long username are that great really. For a start, after concatenation (2047 characters), you'll get connectivity checks that exceed the typical Internet MTU." Has that been resolved? (What is the max. size of connectivity check packets, anyway?)


Should something be said about how ICE interacts with standard source address selection (RFC1122, RFC3484) for the media flows? Doesn't using ICE circumvent those standards?


Section 4.1.1.1., paragraph 1:
>    protocol.  Procedures are specified here for UDP.

  Does "here" mean "the remainder of this document?"
  If so, please state this much more prominently.


Finally, with ICE now being pushed as a more general middlebox traversal scheme (cf. the discussion of using ICE for HIP), it would have been good to refactor this specification, extracting the media-, SIP- and RTP-specific pieces into a different document. The current description of ICE is so intermingled with RAI-specific stuff that it is not obvious as to which mechanisms need to be extracted to use ICE outside that application area. (I do understand that another major rewrite is the last thing the authors want to do at this point - but I fully expect one to be required before non-RAI folks can easily adapt ICE for their purposes.)

[Ballot comment]
There were some bug fixes to -17 by Adam Fisk and others on the MMUSIC list that JDR said he'd include - is an RFC Editor Note with those missing? Is the plan to have this go to "revised ID needed" to incorporate these?


Should something be said about how ICE interacts with standard source address selection (RFC1122, RFC3484) for the media flows? Doesn't using ICE circumvent those standards?


Section 4.1.1.1., paragraph 1:
>    protocol.  Procedures are specified here for UDP.

  Does "here" mean "the remainder of this document?"
  If so, please state this much more prominently.


Finally, with ICE now being pushed as a more general middlebox traversal scheme (cf. the discussion of using ICE for HIP), it would have been good to refactor this specification, extracting the media-, SIP- and RTP-specific pieces into a different document. The current description of ICE is so intermingled with RAI-specific stuff that it is not obvious as to which mechanisms need to be extracted to use ICE outside that application area. (I do understand that another major rewrite is the last thing the authors want to do at this point - but I fully expect one to be required before non-RAI folks can easily adapt ICE for their purposes.)

[Ballot discuss]
This is a great document and much needed function. While the protocol is complex, the specification is well written and solid.

I do have a few issues or question marks, however:

1. Why does Section 4.2 (lite) mention RF 3484, but
  Section 4.1 (full) does not? Wouldn't RFC 3484 algorithms
  be appropriate input for the prioritization of address pairs?
  (or inappropriate to not take the input?)

2. There are several places in the document with an apparent
  assumption that interface = address. It does not hold when
  you are dual-stack, and does not even hold for IPv6 as
  you may have multiple addresses and multiple types of
  addresses. Some places:

    Section 2.1: "If an agent is multihomed, it obtains a
    candidate from each interface."

    Section 4.1.1.1: "If an agent is using both RTP and RTCP,
    it would end up with 2*K host candidates if an agent has
    K interfaces."

3. I worry about 18.5.2 amplification attack. 100 tests limt
  and no mandatory limit on number of candidates worries me.
  Is there a possibility to make this stricter? What data
  are the suggested numbers based on?

[Ballot discuss]
This is a great document and much needed function. While the protocol is complex, the specification is well written and solid.

I do have a few issues or question marks, however:

1. Why does Section 4.2 (lite) mention RF 3484, but
  Section 4.1 (full) does not? Wouldn't RFC 3484 algorithms
  be appropriate input for the prioritization of address pairs?
  (or inappropriate to not take the input?)

2. There are several places in the document with an apparent
  assumption that interface = address. It does not hold when
  you are dual-stack, and does not even hold for IPv6 as
  you may have multiple addresses and multiple types of
  addresses. Some places:

    Section 2.1: "If an agent is multihomed, it obtains a
    candidate from each interface."

    Section 4.1.1.1: "If an agent is using both RTP and RTCP,
    it would end up with 2*K host candidates if an agent has
    K interfaces."

[Ballot discuss]
ICE aims at supporting multiple transport protocols (cf. draft-ietf-mmusic-ice-tcp) and not just UDP. Some inconsistencies exist around that feature. Section 2 seems to want to give a high-level overview of the ICE architecture - including support of multiple transport protocols - whereas the detailed specification in the remaining sections focuses exclusively on ICE with UDP. (At least that's how it came across )

However, Section 2 is inconsistent in how it defines and then uses the terms "transport address" and "candidate". Some definitions say that a transport address is "a combination of IP address and port for a particular transport protocol", i.e., a 3-tuple , whereas other uses of the terms say something like "combination of IP address and port", i.e., a pair . The former seems to be correct, because a protocol number is useless without the context of a particular transport protocol. This needs to be clarified both in the text and in the diagrams/examples, which use the X:x notation to denote IP address and port while omitting the transport protocol.

Also, something should be said in Section 2 about how ICE decides which transport protocol(s) to gather candidates for. Different applications support different kinds of transports, e.g., RTP runs over UDP, TCP and DCCP, whereas HTTP is limited to TCP, etc. It's unclear how ICE interacts with that.

(As an alternative to all the above, it could be made clear that this entire draft is just about ICE with UDP. But that would also require some text changes, and having a comprehensive description of the architecture with support for multiple transports is beneficial, because it'd be needed for draft-ietf-mmusic-ice-tcp anyway.)

Section 10., paragraph 2:
>    If there has been no packet sent on the candidate pair ICE is using
>    for a media component for Tr seconds (where packets include those
>    defined for the component (RTP or RTCP) and previous keepalives), an
>    agent MUST generate a keepalive on that pair.  Tr SHOULD be
>    configurable and SHOULD have a default of 15 seconds.

  15 seconds are short, but we've discussed this offline and I can
  grudgingly live with it. However, please add that (1) Tr MUST NOT be
  configured to less than 15 seconds and that (2) folks deploying ICE in
  more controlled networking environments SHOULD set Tr to the longest
  duration possible in their environment.


Section 16:
> 16.  Setting Ta and RTO

This section proposes to shape the ICE probes such that they consume bandwidth in a way that is similar to the media flows for which ICE is being executed. That's a neat idea, but I don't see how this can fly in general. STUN doesn't depend on ICE, and ICE doesn't depend on RTP, meaning that using RTP parameters for this calculation isn't generally possible. (And even if it were, that'd be a pretty ugly layering violation.) The result is that folks will probably simply use the 100ms for RTO and 20ms for Ta, which is too aggressive. (I know of an open-source implementation that did that, and found that the behavior sucked over DSL links. They went to 300ms for RTO and something larger for Ta, too.) I agree that RFC2988's 3 seconds for the RTO are problematic, but SIP and GIST use 500ms, for example, and that'd be a much safer value.

(I should have caught this earlier, when the idea of shaping the ICE probes to use bandwidth similar to the media stream was proposed - I apologize that I didn't.)

State Change Notice email list have been change to mmusic-chairs@tools.ietf.org, behave-chairs@tools.ietf.org, jdrosen@cisco.com, philip_matthews@magma.ca, fluffy@cisco.com from mmusic-chairs@tools.ietf.org, behave-chairs@tools.ietf.org, jdrosen@cisco.com, philip_matthews@magma.ca, fluffy@cisco.om

[Ballot comment]
Should something be said about how ICE interacts with standard source address selection (RFC1122, RFC3484) for the media flows? Doesn't using ICE circumvent those standards?


Section 4.1.1.1., paragraph 1:
>    protocol.  Procedures are specified here for UDP.

  Does "here" mean "the remainder of this document?"
  If so, please state this much more prominently.


Finally, with ICE now being pushed as a more general middlebox traversal scheme (cf. the discussion of using ICE for HIP), it would have been good to refactor this specification, extracting the media-, SIP- and RTP-specific pieces into a different document. The current description of ICE is so intermingled with RAI-specific stuff that it is not obvious as to which mechanisms need to be extracted to use ICE outside that application area. (I do understand that another major rewrite is the last thing the authors want to do at this point - but I fully expect one to be required before non-RAI folks can easily adapt ICE for their purposes.)

[Ballot discuss]
ICE aims at supporting multiple transport protocols (cf. draft-ietf-mmusic-ice-tcp) and not just UDP. Some inconsistencies exist around that feature. Section 2 seems to want to give a high-level overview of the ICE architecture - including support of multiple transport protocols - whereas the detailed specification in the remaining sections focuses exclusively on ICE with UDP. (At least that's how it came across )

However, Section 2 is inconsistent in how it defines and then uses the terms "transport address" and "candidate". Some definitions say that a transport address is "a combination of IP address and port for a particular transport protocol", i.e., a 3-tuple , whereas other uses of the terms say something like "combination of IP address and port", i.e., a pair . The former seems to be correct, because a protocol number is useless without the context of a particular transport protocol. This needs to be clarified both in the text and in the diagrams/examples, which use the X:x notation to denote IP address and port while omitting the transport protocol.

Also, something should be said in Section 2 about how ICE decides which transport protocol(s) to gather candidates for. Different applications support different kinds of transports, e.g., RTP runs over UDP, TCP and DCCP, whereas HTTP is limited to TCP, etc. It's unclear how ICE interacts with that.

(As an alternative to all the above, it could be made clear that this entire draft is just about ICE with UDP. But that would also require some text changes, and having a comprehensive description of the architecture with support for multiple transports is beneficial, because it'd be needed for draft-ietf-mmusic-ice-tcp anyway.)

Section 10., paragraph 2:
>    If there has been no packet sent on the candidate pair ICE is using
>    for a media component for Tr seconds (where packets include those
>    defined for the component (RTP or RTCP) and previous keepalives), an
>    agent MUST generate a keepalive on that pair.  Tr SHOULD be
>    configurable and SHOULD have a default of 15 seconds.

  15 seconds are short, but we've discussed this offline and I can
  grudgingly live with it. However, please add that (1) Tr MUST NOT be
  configured to less than 15 seconds and that (2) folks deploying ICE in
  more controlled networking environments SHOULD set Tr to the longest
  duration possible in their environment.

[Ballot comment]
Should something be said about how ICE interacts with standard source address selection (RFC1122, RFC3484) for the media flows? Doesn't using ICE circumvent those standards?

Finally, with ICE now being pushed as a more general middlebox traversal scheme (cf. the discussion of using ICE for HIP), it would have been good to refactor this specification, extracting the media-, SIP- and RTP-specific pieces into a different document. The current description of ICE is so intermingled with RAI-specific stuff that it is not obvious as to which mechanisms need to be extracted to use ICE outside that application area. (I do understand that another major rewrite is the last thing the authors want to do at this point - but I fully expect one to be required before non-RAI folks can easily adapt ICE for their purposes.)

[Ballot discuss]
ICE aims at supporting multiple transport protocols (cf. draft-ietf-mmusic-ice-tcp) and not just UDP. Some inconsistencies exist around that feature. Section 2 seems to want to give a high-level overview of the ICE architecture - including support of multiple transport protocols - whereas the detailed specification in the remaining sections focuses exclusively on ICE with UDP. (At least that's how it came across )

However, Section 2 is inconsistent in how it defines and then uses the terms "transport address" and "candidate". Some definitions say that a transport address is "a combination of IP address and port for a particular transport protocol", i.e., a 3-tuple , whereas other uses of the terms say something like "combination of IP address and port", i.e., a pair . The former seems to be correct, because a protocol number is useless without the context of a particular transport protocol. This needs to be clarified both in the text and in the diagrams/examples, which use the X:x notation to denote IP address and port while omitting the transport protocol.

Also, something should be said in Section 2 about how ICE decides which transport protocol(s) to gather candidates for. Different applications support different kinds of transports, e.g., RTP runs over UDP, TCP and DCCP, whereas HTTP is limited to TCP, etc. It's unclear how ICE interacts with that.

(As an alternative to all the above, it could be made clear that this entire draft is just about ICE with UDP. But that would also require some text changes, and having a comprehensive description of the architecture with support for multiple transports is beneficial, because it'd be needed for draft-ietf-mmusic-ice-tcp anyway.)

[Ballot discuss]
I'm happy to move this to the Turn document when that comes to the
IESG.  I'm bringing up the issue now, but I suspect no one including
me will want to hold this document for it.  I want to discuss with the
IESG to see where we are though.

This document suggests that clients should be statically provisioned
with a long-term secret to use with Turn servers.  I suspect that
after doing the RFC 4107 analysis we'll find that we need mandatory
key management for Turn. I suspect that by the time all is said and
done, that will be inappropriate advice.  How do we want to manage
this?

[Ballot discuss]
This may be a discuss DISCUSS. The first issue relates to questions that were raised in the Working Group discussions. The second is related to operational and manageability considerations information. In the absence of a dedicated section the information may be distributed within the document, I found some, but I am still missing many pieces. (it's a big document, you know)

1. Status of the document - prior and during Chicago there have been intense discussions on the list whether the appropriate status of this document is Proposed or Experimental. Some questions were asked about the (lack of) deployment experience with the later versions. Are we sure about the level of consensus reached by the Working Group and the IETF regarding this version of the document?

2. The document is missing information related to operational considerations and manageability. Specifically I could not find information about:
- strategy of deployment - how an installation should be started, are there any NAT configurations that should be avoided, are there any recommended default configuration parameters, any information on scalability?
- Are mixes of ICE and ICE-lite expected to work, what are the limitations?
- impact on the network traffic level - how much bandwidth would the keep-alive message for each session consume? any limits and default settings to be considered at installation?
- observability - how does a network manager know that discovery is completed and his ICE deployment works? Any hooks in the protocol to help debug a situation when something goes wrong?
- Section 16 - when saying Ta and ST0 should be configurable - is this implying there needs to be some out-of-band configuration interface, or is this all automatic computation performed by agents?

[Ballot comment]
From the Gen-ART Review by Christian Vogt

  Section 2.6, 1st paragraph:
  >
  > ... However, it is possible that packet losses will cause a higher
  > priority check to take longer to complete.  In that case, allowing
  > ICE to run a little longer might produce better results.
  >
  Saying "a packet loss" rather than "packet losses" could avoid
  confusion.  A reader might otherwise wonder why running "a little
  longer might produce better results" if it would mean that a
  high-packet-loss path gets eventually chosen.

  In Security Considerations, Section 18.5.2, "STUN Amplification
  Attack", explains that ICE candidate probes could be used for
  amplified flooding:
  >
  > It is impossible to eliminate the amplification, but the volume can
  > be reduced through a variety of heuristics.  [...]
  >
  A reader might at first glance wonder why the amplification could not
  be avoided by requiring the initiator to send a separate request per
  response.  For example, this is done in Mobile IPv6 route optimization
  where a mobile host sends out two initialization messages that each
  prompt the peer to send a single response message.

  It might be valuable to note in section 18.5.2 that a "balancing"
  of the number of request and response messages is not possible in the
  case of ICE because the initiator does not know the number of
  responses at the time it sends the request.  In ICE, the number of
  responses depends on both the initiator's and the responder's set of
  IP addresses.

  Section 2.1, 1st paragraph:
  >
  > ...  In all cases, such a network interface appears to the agent as
  > a local interface from which ports (and thus a candidate) can be
  > allocated.
  >
  s/ports (and thus a candidate)/a port (and thus a candidate)/
  ... or plural in both cases.

  Section 2.1, 2nd paragraph on page 11:  It seems that "local
  interface Y" should be "local IP address Y" because only the IP
  address is relevant for connectivity, not the interface. And, an
  interface may have multiple IP addresses, of course.

IANA Last Call Comment:

*** NOTE ***
Note: Actions 1,2 and 3 can be performed as soon as
this document is approved. Actions 4 and 5 depend on [draft-ietf-behave-rfc3489bis] and this document must
be put on hold until that one is approved.
*********


Action #1: Sections 20.1.1, 20.1.2
Upon approval of this document, the IANA will make
the following assignments in the "Session Description
Protocol (SDP) Parameters - per [RFC4566]"
registry located at

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

sub-registry "att-field (media level only)"

Type SDP Name Reference
---- ------------------ ---------
candidate [RFC-mmusic-ice-17]
remote-candidates [RFC-mmusic-ice-17]


Action #2: 20.1.3, 20.1.4, 20.1.7
Upon approval of this document, the IANA will make
the following assignments in the "Session Description
Protocol (SDP) Parameters - per [RFC4566]"
registry located at

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

sub-registry "att-field (session level)"

Type SDP Name Reference
---- ------------------ ---------
ice-lite [RFC-mmusic-ice-17]
ice-mismatch [RFC-mmusic-ice-17]
ice-options [RFC-mmusic-ice-17]

Action #3: 20.1.5, 20.1.6
Upon approval of this document, the IANA will make
the following assignments in the "Session Description
Protocol (SDP) Parameters - per [RFC4566]"
registry located at

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

sub-registry "att-field (both session and media level):

Type SDP Name Reference
---- ------------------ ---------
ice-pwd [RFC-mmusic-ice-17]
ice-ufrag [RFC-mmusic-ice-17]


Action #4: Section 20.2
Depends on [draft-ietf-behave-rfc3489bis] to be
processed first which is still in working group.
Once that one is processed add following
registrations to the "STUN attribtues" sub-registry
[draft-ietf-behave-rfc3489bis] creates

0x0024 PRIORITY [RFC-mmusic-ice-17]
0x0025 USE-CANDIDATE [RFC-mmusic-ice-17]
0x8029 ICE-CONTROLLED [RFC-mmusic-ice-17]
0x802a ICE-CONTROLLING [RFC-mmusic-ice-17]


Action #5: Section 20.3
Depends on [draft-ietf-behave-rfc3489bis] to be
processed first which is still in working group.
Once that one is processed add following registrations
to the "STUN Error Responses" sub-registry created by
[draft-ietf-behave-rfc3489bis].


487 Role Conflict: The client asserted an ICE role
[RFC-mmusic-ice-17] (controlling or controlled) that
is in conflict with the role of the server.


We understand the above to be the only IANA Actions
for this document.

State Change Notice email list have been change to mmusic-chairs@tools.ietf.org, behave-chairs@tools.ietf.org, jdrosen@cisco.com, philip_matthews@magma.ca, fluffy@cisco.om from mmusic-chairs@tools.ietf.org, behave-chairs@tools.ietf.org, philip_matthews@magma.ca, fluffy@cisco.om

--- Document Shepherd Write-Up for:
---          draft-ietf-mmusic-ice-17.txt

The procedures described in RFC 4858 (a.k.a. the PROTO process) are
being used for the MMUSIC Internet-Draft titled "Interactive
Connectivity Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-17,
http://tools.ietf.org/html/draft-ietf-mmusic-ice-17

Requested Publication Status: Proposed Standard
Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)

--------------------------------------------------------------------
--- (1.a)
    Who is the Document Shepherd for this document?  Has the
    Document Shepherd personally reviewed this version of the
    document and, in particular, does he or she believe this
    version is ready for forwarding to the IESG for publication?

Jean-Francois Mule, MMUSIC co-chair (jf.mule@cablelabs.com) is the
Document Shepherd. He has personally reviewed this version of the
Internet-Draft.
Based on the WG discussion and Document Shepherd review, I believe this
version is ready for forwarding to the IESG for publication.


--- (1.b)
    Has the document had adequate review both from key WG members
    and from key non-WG members?  Does the Document Shepherd have
    any concerns about the depth or breadth of the reviews that
    have been performed?

Yes, ICE has received numerous reviews from participants and
subject-matter experts that are WG members, implementers or IAB members
who provided valuable comments to improve the quality of the protocol.
The Document Shepherd has no concerns about the depth of the reviews
that have been performed.

--- (1.c)
    Does the Document Shepherd have concerns that the document
    needs more review from a particular or broader perspective,
    e.g., security, operational complexity, someone familiar with
    AAA, internationalization, or XML?

This Internet-Draft has been the subject of IETF-wide tutorials and
topics related to ICE have been presented or discussed on various lists
outside MMUSIC including SIP, sipping, behave, and v6ops.
I have no particular concerns re: more reviews. Additional reviews from
folks outside the RAI area is certainly welcome, for e.g. in the
Transport area (in particular behave and midcom), and in the Operations
and Management area (in particular v6ops for ICE usage in dual-stack and
multihomed hosts).

--- (1.d)

    Does the Document Shepherd have any specific concerns or
    issues 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. 
No concerns given the 3 week WGLC and the additional extended WGLC
(2-week period after all the WGLC comments had been addressed).

    Has an IPR disclosure related to this document
    been filed?  If so, please include a reference to the
    disclosure and summarize the WG discussion and conclusion on
    this issue.

Yes. IPR disclosures have been filed and announced to the list by the wg
chairs. More details can be found at:
https://datatracker.ietf.org/ipr/search/?option=document_search&id_docum
ent_tag=11119


--- (1.e) 
    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?

There is solid consensus.

--- (1.f)
    Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarize the areas of conflict in
    separate email messages to the Responsible Area Director.  (It
    should be in a separate email because this questionnaire is
    entered into the ID Tracker.)

No.

--- (1.g)
    Has the Document Shepherd personally verified that the
    document satisfies all ID nits?  (See
    http://www.ietf.org/ID-Checklist.html and
    http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
    not enough; this check needs to be thorough.  Has the
    document met all formal review criteria it needs to, such as
    the MIB Doctor, media type and URI type reviews?


Yes, draft-17 was checked against idnits 2.04.12.
The document uses IPv4 addresses from the RFC1918 private address space
in examples and I believe this is fine given its applicability to
environments in presence of NAT. While IDnits produces warning, the use
of the net10 address space seems appropriate: warnings can be ignored.
The rest of the IDnits are minor and can be fixed in a future revision.

The idnits check (version 2.04.09) with the verbose setting yielded the
following output:

idnits 2.04.12

tmp/draft-ietf-mmusic-ice-17.txt:
tmp/draft-ietf-mmusic-ice-17.txt(1516): Found possible IPv4 address
'10.0.1.1' in position 44; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(1526): Found possible IPv4 address
'10.0.1.1' in position 39; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(1528): Found possible IPv4 address
'10.0.1.1' in position 4; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(4245): Found possible IPv4 address
'10.0.1.1' in position 19; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(4435): Found possible IPv4 address
'10.0.1.1' in position 44; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(4445): Found possible IPv4 address
'10.0.1.1' in position 39; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(4447): Found possible IPv4 address
'10.0.1.1' in position 4; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5161): Line is too long: the offending
characters are 'or'
tmp/draft-ietf-mmusic-ice-17.txt(5307): Unexpected reference format:
'...ed NA[P]Ts an...'
tmp/draft-ietf-mmusic-ice-17.txt(5747): Found possible IPv4 address
'10.0.1.101' in position 45; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5756): Found possible IPv4 address
'10.0.1.100' in position 4; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5759): Found possible IPv4 address
'192.168.1.100' in position 4; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5774): Found possible IPv4 address
'192.168.1.100' in position 21; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5775): Found possible IPv4 address
'10.0.1.100' in position 45; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5779): Found possible IPv4 address
'192.168.1.100' in position 49; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5780): Found possible IPv4 address
'10.0.1.100' in position 37; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5828): Found possible IPv4 address
'10.0.0.0' in position 19; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5829): Found possible IPv4 address
'10.0.0.0' in position 18; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5830): Found possible IPv4 address
'10.0.1.1' in position 12; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5832): Found possible IPv4 address
'10.0.1.1' in position 4; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5833): Found possible IPv4 address
'10.0.1.1' in position 41; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.
tmp/draft-ietf-mmusic-ice-17.txt(5836): Found possible IPv4 address
'10.0.1.1' in position 4; this doesn't match RFC3330's suggested
192.0.2.0/24 address range.


  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:

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

    No issues found here.

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:

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

    No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

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

  ** There is 1 instance of too long lines in the document, the longest
one
    being 2 characters in excess of 72.

  == There are 20 instances of lines with private range IPv4 addresses
in the
    document.  If these are generic example addresses, they should be
changed
    to use the 192.0.2.x range defined in RFC 3330.


  Miscellaneous warnings:

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

    No issues found here.

  Checking references for intended status: Proposed Standard

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

    (See RFC 3967 for information about using normative references to
    lower-maturity documents in RFCs)
  == Unused Reference: 'RFC3556' is defined on line 4472, but no
explicit
    reference was found in the text
    '[RFC3556]  Casner, S., "Session Description Protocol (SDP)
Bandwidth...'

  == Outdated reference: A later version (-04) exists of
    draft-ietf-behave-turn-03

  == Outdated reference: A later version (-10) exists of
    draft-ietf-sip-outbound-09


    Summary: 1 error (**), 4 warnings (==), 0 comments (--).

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


--- (1.h)
    Has the document split its references into normative and
    informative? 
Yes.

    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
    strategy for their completion? 
There are 3 normative references to IETF Internet-Drafts; see the
comments below & inline for the strategy for their completion.

  [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., "Session Traversal Utilities for (NAT)
              (STUN)", draft-ietf-behave-rfc3489bis-06 (work in
              progress), March 2007.
This document is active in the BEHAVE working group and a 2-week WGLC is
expected to complete in August 2007.

  [I-D.ietf-behave-turn]
              Rosenberg, J., "Obtaining Relay Addresses from Simple
              Traversal Underneath NAT (STUN)",
              draft-ietf-behave-turn-03 (work in progress), March 2007.
This document is active but is not yet ready for WGLC. Expected WGLC in
the fall of 2007.


  [I-D.ietf-sip-ice-option-tag]
              Rosenberg, J., "Indicating Support for Interactive
              Connectivity Establishment (ICE) in the Session
              Initiation Protocol (SIP)",
              draft-ietf-sip-ice-option-tag-02 (work in progress),
              June 2007.
This document has passed WGLC and a publication request as a Proposed
Standard has been submitted.

    Are there normative references
    that are downward references, as described in [RFC3967]?  If
    so, list these downward references to support the Area
    Director in the Last Call procedure for them [RFC3967].
No.

--- (1.i)
    Has the Document Shepherd verified that the document's IANA
    Considerations section exists and is consistent with the body
    of the document? 
Yes.

    If the document specifies protocol
    extensions, are reservations requested in appropriate IANA
    registries?
Yes.
    Are the IANA registries clearly identified?
Yes; a dependency exists on the creation the STUN registry per
I-D.ietf-behave-rfc3489bis.

    If the document creates a new registry, does it define the
    proposed initial contents of the registry and an allocation
    procedure for future registrations?  Does it suggest a
    reasonable name for the new registry?  See [RFC2434].  If the
    document describes an Expert Review process, has the Document
    Shepherd conferred with the Responsible Area Director so that
    the IESG can appoint the needed Expert during IESG Evaluation?
This document does not create a new registry but proposes new values be
registered in the existing SDP registry and in the to-be-created STUN
one. For SDP, the document registers new attribute names and follows the
requirements defined in RFC 4566 Section 8.2.4. ("Specification
Required" policy per RFC 2434 and all the required information is
provided).
For STUN, the document registers STUN attributes and one error code
(20.2 and 20.3) and it is compliant with the rules defined by
http://tools.ietf.org/html/draft-ietf-behave-rfc3489bis Sections 17.2
and 17.3.

--- (1.j)
    Has the Document Shepherd verified that sections of the
    document that are written in a formal language, such as XML
    code, BNF rules, MIB definitions, etc., validate correctly in
    an automated checker?

Yes, checked aBNF with http://www.apps.ietf.org/abnf.html. Results
included undefined and unreferenced rules (to be expected) but no
errors.


--- (1.k)
    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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document.  If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

    Working Group Summary
        Was there anything in the WG process that is worth noting?
        For example, was there controversy about particular points
        or were there decisions where the consensus was
        particularly rough?
    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?

    Personnel
        Who is the Document Shepherd for this document?  Who is the
        Responsible Area Director?  If the document requires IANA
        experts(s), insert 'The IANA Expert(s) for the registries
        in this document are .'


Here is the proposed Document Announcement Write-Up:

        Technical Summary
This document defines a protocol for Network Address Translator (NAT)
traversal for multimedia sessions established with the offer/answer
model.  This protocol is called Interactive Connectivity Establishment
(ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN)
protocol and its extension, Traversal Using Relay NAT (TURN).  ICE can
be used by any protocol utilizing the offer/answer model, such as the
Session Initiation Protocol (SIP).

          Working Group Summary
The MMUSIC Working Group has consensus to publish this document as a
Proposed Standard.

          Document Quality
Previous versions of this protocol have been implemented. A number of
implementers have indicated plans to support this protocol once
published.

      Personnel
The Document Shepherd is Jean-Francois Mule, and the Responsible Area
Director is Cullen Jennings.