Subject: [Sipping] General comments and NITs on draft-rosenberg-sipping-nat-scenario s-02

From: "Mary Barnes" <[email-masked]>
Date: Thu, 5 Feb 2004 10:06:50 -0600

Jonathan and Gonzalo,

Sorry for the delay in providing feedback on this work.  I have a couple of
general points for discussion and then some detailed nits. Following the
thread of this work , I also will post separately a few comments on the
MMUSIC WG ICE draft. 

General: 
1) What are the changes in the -02 from the -01?  The only thing I could
spot was an update to reference [11]. I had done an initial review of the
-01 and the -02 appeared before I had a chance to post those comments, so
perhaps I didn't re-review closely enough. 

2) On the current plan to use this document to replace the existing WG NAT
scenarios document, I have concerns that there will be a loss of background
information that might be useful.  I also think that the current WG document
fairly accurately reflects the plethora of various solution options out
there for this problem (albeit none of them ideal).  And, though I do
generally agree that with the ICE approach in terms of minimizing the
knowledge of topology etc in the client, the reality is that ALGs and some
of the other solutions are likely to remain around for a while and I think
it's useful to keep documentation of where they fit relative to this
solution.  I realize that progressing the existing WG NAT scenarios document
by itself (which would need some work to complete) isn't necessarily
productive. One thought I had was that perhaps parts of the existing
document could be included in the Appendix, with these less desireable
alternatives referenced in the corresponding sections of the ICE based
scenarios.  In a sense, this might add strength to why ICE would be
preferred to these alternatives. 

3) Somewhat related to point 2, I really like the completeness of the flows
in the existing WG NAT scenarios as they do include the SIP messages and the
media flow in many cases. I realize that this draft does detail the
appropriate SDP, but the message flows consist entirely of the STUN and TURN
messages.  I realize that adding the SIP messages will dramatically increase
the size of the flows.  Perhaps adding one or two detailed flows at the
beginning (or as appropriate) and then just referring to Steps x, y, and z,
etc. in those flows would add some value.  

Specific NITs/comments:
1) Relative to General point 2 above, I think one value of ICE beyond what's
in the existing WG NAT scenarios document is the v6 to v4 scenario.  I think
it would be good to highlight that in the abstract. I would propose
extending the sentence:
"The examples cover a range of network topologies and use cases." 
to:
"The examples cover a range of network topologies and use cases, including
IPv6 networks interworking with IPv4." 

2) Page 6, section 2.1, 1st para, next to last sentence:  "Thought not
show,..." should be "Though not shown, ...".

3) page 16, section 2.2, 1st para, last sentence: "A's discovers..." should
be with "A discovers...". 

4) page 18, section 2.2, paragraph between Figure 9 and Figure 2, for
readability I would suggest splitting this into 2 paragraphs starting with
the 4th sentence "B now begins connectivity checks." Also, consistent with
the layout for section 2.2, it might be better to move that second portion
of the paragraph after Figure 10. 

5) Page 21, section 2.2, OPEN ISSUE, last sentence: "doesnt" should be
"doesn't".  Also, shouldn't this OPEN ISSUE be captured in the MMUSIC WG ICE
document, as doesn't it reflect an algorithmic problem with the
prioritization scheme?  

6) Page 28, section 3.1, last para, 2nd sentence: "Thats" should be "That's"

7) Page 29, section 3.2, last para, last sentence would read more clearly by
explicitly mentioning that it will not lockdown as follows:
" Here, it will not lockdown, since the address learned from the TURN server
                    ---------    
  is never advertised to any peers."

7) Page 29, section 3.2, related to my general comment 3 above,  it would be
nice to have a message flow here, showing the continued flow though the TURN
server for this scenario. 

8) Page 33, section 3.3, SDP should be labeled as Figure 21. 

9) Page 33, paragraph immediately following SDP, "... B;s connectivity
test." should be "...B's connectivity test."  

10) Page 47, section 6, 1st paragraph, "...packets addresses to that
PREFIX..." should be "...packets addressed to that PREFIX..."

11) Page 55, I'm assuming Reference [4] needs to be updated as the MMUSIC WG
ICE document.

Regards,
Mary H. Barnes
[email-masked]
972-684-5432

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Feb 2004 21:58:35 +0200

Mary,

> perhaps I didn't re-review closely enough. 

The RFC editor got confused somehow when publishing this draft. So, we 
ended up with two different documents called the same way (version 01): 
an old version, and the new version... to resolve this mess, we 
submitted the 02 version.

Gonzalo

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.