Subject: [MMUSIC] Re: Some comments on draft-ietf-mmusic-ice-08

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Jun 2006 15:50:03 -0400

Thanks for the comments. Responses inline.

Philip Matthews wrote:

> Jonathan:
> 
> Here are some comments. They are mostly pretty minor.
> I am still re-reading the draft to more fully understand it,
> so more may follow.
> 
> General comments:
> - The grammar given in section 12 specifies that a colon (":") is to  
> immediately follow the word "candidate"
> in the "a=candidate" line. This is consistent with the SDP syntax for  
> an attribute with a value as specified in
> draft-ietf-mmusic-sdp-new-26.
> However, none of the examples given elsewhere in the document use a  colon.

Good catch. Fixed.

> 
> Section 1:
> - (First PP) Misspelling - "Descrption" should be "Description".

fixed.

> 
> Section 2:
> - I found it difficult to understand much of the terminology on my  
> first pass through
>   the document, even though I had a basic understanding of how ICE  
> works. In the end,
>   I just skipped over it and then came back later.
>   Perhaps consider placing the introductory sections before the  
> terminology section,
>   perhaps by making sections 3 - 6 subsections of section 1.  If you  
> did this,
>   then the terminology section would clearly divide the Informative  
> text from the Normative text.

I like the idea of moving the introduction before terminology, that is 
fine. Not so sure about the rest. I'm still noodling your proposed 
reorganization and Rohans, and will do the reorg last as I edit -09.

> - It would be nice if the definitions of Reflexive Transport Address  
> and Relayed Transport Address
>   could make it clearer that these are subclasses of Derived  Transport 
> Addresses
>   (for example, the definition text could start "A type of Derived  
> Transport Address where ...").

Done. Note that the definition of reflexive transport address did 
mention that it was derived; its just that the statement was at the end 
of the definition. I moved it to the beginning.

> - I found the definitions of the various Transport Address forms  
> difficult to understand
>   (I was familiar with the concepts, but hadn't see the terms  before, 
> and was uncertain for a while
>   which term matched which concept).
>   I might be useful to add a diagram (perhaps somewhere in sections  
> 3-6) that illustrates the
>   various forms  (Derived, Reflexive, etc...)

I think its clear that the terminology itself needs to really be 
introduced first in the introduction section, and the terminonology 
section more of a reference after that. As for a picture, I'll add this 
into the introduction:

  Please view in a fixed-width font such as
                   Courier.

               To Internet

                   |
                   |
                   |  /------------  Relayed
                   | /               Address
               +--------+
               |        |
               |  STUN  |
               | Server |
               |        |
               +--------+
                   |
                   |
                   | /------------  Reflexive
                   |/               Address
             +------------+
             |    NAT     |
             +------------+
                   |
                   | /------------  Local
                   |/               Address
               +--------+
               |        |
               | Agent  |
               |        |
               +--------+

> 
> Section 3:
> - "in addition to private networks connected to the public Internet  
> through NAT".
>   The wording here suggests  that the combination of the Internet  plus 
> various private networks
>   connected to it via NAT boxes is one realm.

I've revised the intro (see separate note) and removed these two 
paragraphs on realm, which don't lend any clarity at all I think.

> - (top of page 10) "reply from that target Section 7.13".
>   There is some sort of grammatical error here.

fixed.

> 
> Section 7.1:
> - In the case of a candidate whose components are all server- reflexive 
> or relayed, must the component
>   transport addresses all be derived from the same local address?
>   I suspect so, but you don't say this.

They are from the same candidate, matched component to component. There 
is a picture now in the overview which says this. I also added words to 
this extent at the top of 7.1, which say:

For server reflexive and
relayed candidates, each component MUST be derived from a component with the
same component ID, all of which come from a single local candidate.

> - (page 13)
>       "Local candidates are obtained by binding to ephemeral ports  on 
> an interface ..."
>    AND
>      "... obtain a set of candidates (one for each interface) by  
> binding to N ephemeral UDP ports ..."
>   This text seems to imply that the UDP ports must be ephemeral.  This 
> seems overly restrictive.
>   I believe that the specification will work fine if a well-known  port 
> is used instead.
>   I suggest replacing these with the following:
>       "Local candidates are obtained by binding to ports (typically  
> ephemeral ports) on an interface ..."
>   AND
>      "... obtain a set of candidates (one for each interface) by  
> binding to N UDP ports ..."

changed.

> - (page 14, indented paragraph)
>   "The ability to process STUN connectivity checks allows for  clients 
> to obtain peer reflexive transport
>    addresses that can be used by the network server to reach them  
> without a relay, even through NATs
>    with restrictive mapping and filtering policies."
>   I don't understand this sentence.
>   In general, I found the wording in this indented paragraph to be  much 
> below the very high standard
>   set by the rest of the document. Perhaps you might rewrite this  
> entire paragraph.

Rewritten to:

<list style="indent"> <t>Why would these types of endpoints even
bother to implement ICE?  The answer is that such an implementation
greatly facilitates NAT traversal for clients that connect to
it. Consider a PC softphone behind a NAT whose mapping policy is
address and port dependent. The softphone initiates a call through a
gateway that implements ICE. The gateway doesn't obtain any server
reflexive or relayed transport addresses, but it implements ICE, and
consequently, is prepared to receive STUN connectivity checks on its
local transport addresses. The softphone will send a STUN connectivity
to check to that local transport address, causing the NAT to allocate
a new binding for the softphone. The connectivity check will inform
the softphone of this address, allowing it to be used by the gateway
as a peer reflexive remote candidate. This allows direct media
transmission between the gateway and softphone, without the need for
relays. Furthermore, implementation of the STUN connectivity checks
allows for NAT bindings along the way to be kept open. ICE also
provides numerous security properties that are independent of NAT
traversal, and would benefit any multimedia endpoint. See <xref
target="sec:security"/> for a discussion on these benefits.
</t></list>

> - (page 15)
>    "... where there are multiple layers of NAT,  and that layering  is 
> known to the provider of the client."
>   Suggest adding an extra "where", so it reads
>    "... where there are multiple layers of NAT,  and where that  
> layering is known to the provider of the client."

added.

> 
> Section 7.8:
> -  "symmetric NAT". Replace with BEHAVE terminology?

fixed.

> 
> Section 12:
> - In addition to all the SDP examples in section 11, it would be nice  
> to see one or two examples of SDP
>   that do NOT use $L1, $L-PRIV-1.IP, $STUN-PUB-2.PORT, etc.
>   This would help the reader understand the grammar rules.

You mean with actual values? Sigh...

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Philip Matthews <[email-masked]>
Date: Thu, 22 Jun 2006 13:00:48 -0400

Jonathan:

Thanks very much for your reply.

I am very happy with most of your suggested changes.
Just a few minor comments inline.
[To keep this short, I've trimmed most of your reply.]

Good luck getting out ICE-09!

- Philip

> Thanks for the comments. Responses inline.

[---SNIP---]

>> Section 2:
>> - I found it difficult to understand much of the terminology on  
>> my  first pass through
>>   the document, even though I had a basic understanding of how  
>> ICE  works. In the end,
>>   perhaps by making sections 3 - 6 subsections of section 1.  If  
>> you  did this,
>>   then the terminology section would clearly divide the  
>> Informative  text from the Normative text.
>
> I like the idea of moving the introduction before terminology, that  
> is fine. Not so sure about the rest. I'm still noodling your  
> proposed reorganization and Rohans, and will do the reorg last as I  
> edit -09.

Ok. I'll wait and see what you come up with ...

[---SNIP---]

>>   (I was familiar with the concepts, but hadn't see the terms   
>> before, and was uncertain for a while
>>   I might be useful to add a diagram (perhaps somewhere in  
>> sections  3-6) that illustrates the
> section more of a reference after that.

Great!

> As for a picture, I'll add this into the introduction:
>

Looks good.

[---SNIP---]

>>   "The ability to process STUN connectivity checks allows for   
>> clients to obtain peer reflexive transport
>>   In general, I found the wording in this indented paragraph to  
>> be  much below the very high standard

This looks good in isolation. Once you have finished ICE-09,
I will re-read the entire document in detail and see how it looks
in context.

>
>
>> Section 12:
>> - In addition to all the SDP examples in section 11, it would be  
>> nice  to see one or two examples of SDP

Yes, I do mean with actual values. I don't think it's that hard ...
(I suppose I could have sent suggested text instead. Sorry.
I'll try to do that next time.)