Re: [Gen-art] Gen-ART LC review of draft-zhu-mobileme-doc-04
Hi, My impression from reading the document and according to figure 1 was that all end host communication was done in a UDP tunnel. So what is the relation of the TCP connection to BTMM. Roni Even From: Lixia Zhang [mailto:li...@cs.ucla.edu] Sent: Sunday, March 06, 2011 7:52 AM To: Roni Even Cc: draft-zhu-mobileme-doc@tools.ietf.org; gen-art@ietf.org; 'IETF-Discussion list' Subject: Re: Gen-ART LC review of draft-zhu-mobileme-doc-04 On Mar 4, 2011, at 6:01 AM, Roni Even wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-zhu-mobileme-doc-04 Reviewer: Roni Even Review Date:2011-3-4 IETF LC End Date: 2011-3-18 IESG Telechat date: Summary: This draft is almost ready for publication as Informational RFC. Major issues: Minor issues: In section 5 and in section 6.1 second bullet you mention that the end to end connection is TCP while in other places like section 3, 4th paragraph you mention that UDP is used to tunnel packet end to end. So what are the TCP connections used for? section 3 talks about the use of UDP encapsulation for end host's data packets. section 5 and section 6.1 refer to TCP connections used by user applications running on end hosts. Nits/editorial comments: ___ Ietf mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Ge-ART LC review of draft-zhu-mobility-survey-
Thanks for the review. We plan to briefly mention link layer and application layer mobility approaches. However, security and how they deal with NAT and firewalls are separate issues, as this document focuses on how the protocols handle the mobility. For S5.3, we agree that it is political and we are willing to remove it. We'll also address other minor issues you mentioned. Thanks, Zhenkai On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-zhu-mobility-survey-03 Reviewer: Richard Barnes Review Date: 2011-02-28 IETF LC End Date: 2011-03-09 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Its discussion of mobility technologies is thorough, but incorrect in some places, and could use some more context. Major issues: General: The document hypothesizes at a few points reasons why IP mobility techniques haven't caught on, without really looking at competitor technologies. In particular, it would be good to spend a little time talking about techniques for mobility at the link layer (such as the 3GPP GTP approach) and at the application layer (SIP REGISTER, XMPP, etc.) General: The document does not discuss security considerations at all. While I'm sure these considerations are discussed in individual documents, it could be helpful to pull up common high-level issues up to this document. General: There's not really any mention here of how these technologies interact NATs and firewalls, both of which could seriously limit their scope. S5.3: I found Section 5.3 duplicative of the previous section and mainly full of political, rather than technical content. Suggest removing. S6.2: TCP is not the only transport-layer protocol! In particular, in voice and video calls, the stuff that goes on for a long time is all UDP, and sessions are managed through a separate signaling protocol, which can be UDP or TCP. All of the discussion of session management (especially for VoIP) should take into account the mobility features that are already available at the application layer (e.g., SIP re-INVITEs), and discuss how these features interact with mobility at other layers. Minor issues: none S4.7: How does NEMO relate to normal use of the routing protocols to detach and reattach a network? A couple of sentences would be helpful here. S4.15: It's not really accurate to say that global HAHA avoids triangle routing, since it actually does make a triangle. In Figure 6, there's a missing arrow from the CN to the nearby HA, which completes the HA-HA-CN triangle. So it's not that sufficient density avoids triangle routing, it just makes it less of a big deal because the HAs are close to the endpoints. S4.17 P1: I'm a little mystified as to how something is published in the DNS, and only accessible to the subscriber. Quick clarification would be helpful. Nits/editorial comments: S2, Locator: It could be helpful to note here that you're talking about *topological* location, not geolocation.s S4.8 P1: The phrase universally deployed is used a couple of times in this paragraph; it inspires unnecessary pessimism in the reader :) You might want to re-scope to say that mobility is naturally supported in domains where multicast is enabled. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-zhu-mobileme-doc-04
On 7 Mar 2011, at 3:08 AM, Roni Even wrote: Hi, My impression from reading the document and according to figure 1 was that all end host communication was done in a UDP tunnel. So what is the relation of the TCP connection to BTMM. Roni Even Question: When you use IPSEC VPN, what are the TCP connections used for? Answer: Every application that uses TCP today still uses TCP when TCP is running over the IPSEC VPN. BTMM is an IPv6 overlay network, tunneled over IPv4. Every TCP-based application you run is still a TCP-based application. Stuart Cheshire chesh...@apple.com * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-xcon-examples-08.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-xcon-examples-08.txt Reviewer: Francis Dupont Review Date: 20110305 IETF LC End Date: 20110304 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - in general there are some pagination issues but they should be solved by the RFC Editor. - ToC page 2 and 12 page 81: Acknowledgements - Acknowledgments - 2 page 3, 5.2 page 16, 5.3 page 24, 6 page 32, 6.2 page 37 and 7.4 page 70: i.e. - i.e., - 5 page 11, 5.1 page 13, 6.1 page 34, 6.2 page 36, 6.3 page 40, 6.4 page 44, 6.5 page 44, 7.2 page 59 and 8.1 page 76: e.g. - e.g., - 5.2 page 19 '6.': conference . - conference. - 5.3 page 23 and 7.2 page 57: e.g, - e.g., - 5.3 page 24: flavour - flavor - 6.2 page 37: revconly - recvonly - 6.3 page 42: i. e. - i.e., - 7.2 page 59: mantained - maintained - 7.3 page 63: partecipants - participants - 7.3 page 64: comnpletely - completely - 8.1 page 75 figure 27: to Bob | - to Bob | - 8.2 page 77: disconnetting - disconnecting - 11 page 80: thw - the (note: it is in a to-be-removed section) - 11 page 80 and 13.2 page 81: RFC2606 reference is used in this to-be-removed-before-publication section and *only* in it (warning). - Authors' addresses page 82: US - USA Regards francis.dup...@fdupont.fr PS: I can see you use scenarios in place of scenarii but as there are some from Italy in authors if this is fine for them this is fine for me. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ietf-intarea-server-logging-recommendations-03.txt
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-intarea-server-logging-recommendations-03.txt Reviewer: Francis Dupont Review Date: 20110305 IETF LC End Date: 20110311 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 1 page 3: ... will diminish but this is a years long perhaps decades long process. I had a concern about the plural (years/decades) but I consulted someone with a better English than me who answered the whole construct was pretty bad... - 1 page 3: this linebreak documents. - document - 2 page 4: e.g. - e.g., - 2 page 4: preffered - preferred (about this statement, should the document explain a localtime only is not enough (it is ambiguous during one hour per year, unfortunately it is trivial to know which one :-)?) Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Ge-ART LC review of draft-zhu-mobility-survey-
Zhenkai, Thanks for following up. With regard to security/NATs: These could be relevant in your comparison, since I would think that different proposals would have different properties along these lines. For example, it seems like the degree of trust placed in the HA/rendezvous function varies quite a bit, as does the safety of the binding update mechanism (i.e., its ability to prevent an attacker from using spoofed updates to steal traffic). --Richard On Mar 7, 2011, at 2:52 AM, Zhenkai Zhu wrote: Thanks for the review. We plan to briefly mention link layer and application layer mobility approaches. However, security and how they deal with NAT and firewalls are separate issues, as this document focuses on how the protocols handle the mobility. For S5.3, we agree that it is political and we are willing to remove it. We'll also address other minor issues you mentioned. Thanks, Zhenkai On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-zhu-mobility-survey-03 Reviewer: Richard Barnes Review Date: 2011-02-28 IETF LC End Date: 2011-03-09 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Its discussion of mobility technologies is thorough, but incorrect in some places, and could use some more context. Major issues: General: The document hypothesizes at a few points reasons why IP mobility techniques haven't caught on, without really looking at competitor technologies. In particular, it would be good to spend a little time talking about techniques for mobility at the link layer (such as the 3GPP GTP approach) and at the application layer (SIP REGISTER, XMPP, etc.) General: The document does not discuss security considerations at all. While I'm sure these considerations are discussed in individual documents, it could be helpful to pull up common high-level issues up to this document. General: There's not really any mention here of how these technologies interact NATs and firewalls, both of which could seriously limit their scope. S5.3: I found Section 5.3 duplicative of the previous section and mainly full of political, rather than technical content. Suggest removing. S6.2: TCP is not the only transport-layer protocol! In particular, in voice and video calls, the stuff that goes on for a long time is all UDP, and sessions are managed through a separate signaling protocol, which can be UDP or TCP. All of the discussion of session management (especially for VoIP) should take into account the mobility features that are already available at the application layer (e.g., SIP re-INVITEs), and discuss how these features interact with mobility at other layers. Minor issues: none S4.7: How does NEMO relate to normal use of the routing protocols to detach and reattach a network? A couple of sentences would be helpful here. S4.15: It's not really accurate to say that global HAHA avoids triangle routing, since it actually does make a triangle. In Figure 6, there's a missing arrow from the CN to the nearby HA, which completes the HA-HA-CN triangle. So it's not that sufficient density avoids triangle routing, it just makes it less of a big deal because the HAs are close to the endpoints. S4.17 P1: I'm a little mystified as to how something is published in the DNS, and only accessible to the subscriber. Quick clarification would be helpful. Nits/editorial comments: S2, Locator: It could be helpful to note here that you're talking about *topological* location, not geolocation.s S4.8 P1: The phrase universally deployed is used a couple of times in this paragraph; it inspires unnecessary pessimism in the reader :) You might want to re-scope to say that mobility is naturally supported in domains where multicast is enabled. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Ge-ART LC review of draft-zhu-mobility-survey-
On Mar 7, 2011, at 12:22 PM, Richard L. Barnes wrote: Zhenkai, Thanks for following up. With regard to security/NATs: These could be relevant in your comparison, since I would think that different proposals would have different properties along these lines. For example, it seems like the degree of trust placed in the HA/rendezvous function varies quite a bit, as does the safety of the binding update mechanism (i.e., its ability to prevent an attacker from using spoofed updates to steal traffic). --Richard first, I agree that some of the solutions have different properties regarding security/NAT handling. However note that the solution approaches span a very wide range, hence the relevance degree of security/NAT also varies in a rather wide range (e.g. consider those routing based solutions like Connexions or WINMO). The center issue of mobility support is resolving the location and identity conflict, that every solution must address. We believe it makes a good tradeoff to laser focus on this center issue in a single survey, to keep it within both a well defined focus and also reasonable in size. Lixia On Mar 7, 2011, at 2:52 AM, Zhenkai Zhu wrote: Thanks for the review. We plan to briefly mention link layer and application layer mobility approaches. However, security and how they deal with NAT and firewalls are separate issues, as this document focuses on how the protocols handle the mobility. For S5.3, we agree that it is political and we are willing to remove it. We'll also address other minor issues you mentioned. Thanks, Zhenkai On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-zhu-mobility-survey-03 Reviewer: Richard Barnes Review Date: 2011-02-28 IETF LC End Date: 2011-03-09 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Its discussion of mobility technologies is thorough, but incorrect in some places, and could use some more context. Major issues: General: The document hypothesizes at a few points reasons why IP mobility techniques haven't caught on, without really looking at competitor technologies. In particular, it would be good to spend a little time talking about techniques for mobility at the link layer (such as the 3GPP GTP approach) and at the application layer (SIP REGISTER, XMPP, etc.) General: The document does not discuss security considerations at all. While I'm sure these considerations are discussed in individual documents, it could be helpful to pull up common high-level issues up to this document. General: There's not really any mention here of how these technologies interact NATs and firewalls, both of which could seriously limit their scope. S5.3: I found Section 5.3 duplicative of the previous section and mainly full of political, rather than technical content. Suggest removing. S6.2: TCP is not the only transport-layer protocol! In particular, in voice and video calls, the stuff that goes on for a long time is all UDP, and sessions are managed through a separate signaling protocol, which can be UDP or TCP. All of the discussion of session management (especially for VoIP) should take into account the mobility features that are already available at the application layer (e.g., SIP re-INVITEs), and discuss how these features interact with mobility at other layers. Minor issues: none S4.7: How does NEMO relate to normal use of the routing protocols to detach and reattach a network? A couple of sentences would be helpful here. S4.15: It's not really accurate to say that global HAHA avoids triangle routing, since it actually does make a triangle. In Figure 6, there's a missing arrow from the CN to the nearby HA, which completes the HA-HA-CN triangle. So it's not that sufficient density avoids triangle routing, it just makes it less of a big deal because the HAs are close to the endpoints. S4.17 P1: I'm a little mystified as to how something is published in the DNS, and only accessible to the subscriber. Quick clarification would be helpful. Nits/editorial comments: S2, Locator: It could be helpful to note here that you're talking about *topological* location, not geolocation.s S4.8 P1: The phrase universally deployed is used a couple of times in this paragraph; it inspires unnecessary pessimism in the reader :) You might want to re-scope to say that mobility is naturally supported in domains where multicast is enabled. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Ge-ART LC review of draft-zhu-mobility-survey-
That's fine, just thought it would be an interesting area to discuss. --Richard On Mar 7, 2011, at 3:36 PM, Lixia Zhang wrote: On Mar 7, 2011, at 12:22 PM, Richard L. Barnes wrote: Zhenkai, Thanks for following up. With regard to security/NATs: These could be relevant in your comparison, since I would think that different proposals would have different properties along these lines. For example, it seems like the degree of trust placed in the HA/rendezvous function varies quite a bit, as does the safety of the binding update mechanism (i.e., its ability to prevent an attacker from using spoofed updates to steal traffic). --Richard first, I agree that some of the solutions have different properties regarding security/NAT handling. However note that the solution approaches span a very wide range, hence the relevance degree of security/NAT also varies in a rather wide range (e.g. consider those routing based solutions like Connexions or WINMO). The center issue of mobility support is resolving the location and identity conflict, that every solution must address. We believe it makes a good tradeoff to laser focus on this center issue in a single survey, to keep it within both a well defined focus and also reasonable in size. Lixia On Mar 7, 2011, at 2:52 AM, Zhenkai Zhu wrote: Thanks for the review. We plan to briefly mention link layer and application layer mobility approaches. However, security and how they deal with NAT and firewalls are separate issues, as this document focuses on how the protocols handle the mobility. For S5.3, we agree that it is political and we are willing to remove it. We'll also address other minor issues you mentioned. Thanks, Zhenkai On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-zhu-mobility-survey-03 Reviewer: Richard Barnes Review Date: 2011-02-28 IETF LC End Date: 2011-03-09 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Its discussion of mobility technologies is thorough, but incorrect in some places, and could use some more context. Major issues: General: The document hypothesizes at a few points reasons why IP mobility techniques haven't caught on, without really looking at competitor technologies. In particular, it would be good to spend a little time talking about techniques for mobility at the link layer (such as the 3GPP GTP approach) and at the application layer (SIP REGISTER, XMPP, etc.) General: The document does not discuss security considerations at all. While I'm sure these considerations are discussed in individual documents, it could be helpful to pull up common high-level issues up to this document. General: There's not really any mention here of how these technologies interact NATs and firewalls, both of which could seriously limit their scope. S5.3: I found Section 5.3 duplicative of the previous section and mainly full of political, rather than technical content. Suggest removing. S6.2: TCP is not the only transport-layer protocol! In particular, in voice and video calls, the stuff that goes on for a long time is all UDP, and sessions are managed through a separate signaling protocol, which can be UDP or TCP. All of the discussion of session management (especially for VoIP) should take into account the mobility features that are already available at the application layer (e.g., SIP re-INVITEs), and discuss how these features interact with mobility at other layers. Minor issues: none S4.7: How does NEMO relate to normal use of the routing protocols to detach and reattach a network? A couple of sentences would be helpful here. S4.15: It's not really accurate to say that global HAHA avoids triangle routing, since it actually does make a triangle. In Figure 6, there's a missing arrow from the CN to the nearby HA, which completes the HA-HA-CN triangle. So it's not that sufficient density avoids triangle routing, it just makes it less of a big deal because the HAs are close to the endpoints. S4.17 P1: I'm a little mystified as to how something is published in the DNS, and only accessible to the subscriber. Quick clarification would be helpful. Nits/editorial comments: S2, Locator: It could be helpful to note here that you're talking about *topological* location, not geolocation.s S4.8 P1: The phrase universally deployed is used a couple of times in this paragraph; it inspires unnecessary pessimism in the reader :) You might want to re-scope to say that mobility is naturally supported in domains where
Re: [Gen-art] Ge-ART LC review of draft-zhu-mobility-survey-
Hi Jari, We are doing revision according to the comments we received. What do you suggest as our next step? Thanks! Zhenkai On Mar 7, 2011, at 1:48 PM, Richard L. Barnes wrote: That's fine, just thought it would be an interesting area to discuss. --Richard On Mar 7, 2011, at 3:36 PM, Lixia Zhang wrote: On Mar 7, 2011, at 12:22 PM, Richard L. Barnes wrote: Zhenkai, Thanks for following up. With regard to security/NATs: These could be relevant in your comparison, since I would think that different proposals would have different properties along these lines. For example, it seems like the degree of trust placed in the HA/rendezvous function varies quite a bit, as does the safety of the binding update mechanism (i.e., its ability to prevent an attacker from using spoofed updates to steal traffic). --Richard first, I agree that some of the solutions have different properties regarding security/NAT handling. However note that the solution approaches span a very wide range, hence the relevance degree of security/NAT also varies in a rather wide range (e.g. consider those routing based solutions like Connexions or WINMO). The center issue of mobility support is resolving the location and identity conflict, that every solution must address. We believe it makes a good tradeoff to laser focus on this center issue in a single survey, to keep it within both a well defined focus and also reasonable in size. Lixia On Mar 7, 2011, at 2:52 AM, Zhenkai Zhu wrote: Thanks for the review. We plan to briefly mention link layer and application layer mobility approaches. However, security and how they deal with NAT and firewalls are separate issues, as this document focuses on how the protocols handle the mobility. For S5.3, we agree that it is political and we are willing to remove it. We'll also address other minor issues you mentioned. Thanks, Zhenkai On Feb 28, 2011, at 5:45 PM, Richard L. Barnes wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-zhu-mobility-survey-03 Reviewer: Richard Barnes Review Date: 2011-02-28 IETF LC End Date: 2011-03-09 IESG Telechat date: Summary: This draft is almost ready for publication as an Informational RFC. Its discussion of mobility technologies is thorough, but incorrect in some places, and could use some more context. Major issues: General: The document hypothesizes at a few points reasons why IP mobility techniques haven't caught on, without really looking at competitor technologies. In particular, it would be good to spend a little time talking about techniques for mobility at the link layer (such as the 3GPP GTP approach) and at the application layer (SIP REGISTER, XMPP, etc.) General: The document does not discuss security considerations at all. While I'm sure these considerations are discussed in individual documents, it could be helpful to pull up common high-level issues up to this document. General: There's not really any mention here of how these technologies interact NATs and firewalls, both of which could seriously limit their scope. S5.3: I found Section 5.3 duplicative of the previous section and mainly full of political, rather than technical content. Suggest removing. S6.2: TCP is not the only transport-layer protocol! In particular, in voice and video calls, the stuff that goes on for a long time is all UDP, and sessions are managed through a separate signaling protocol, which can be UDP or TCP. All of the discussion of session management (especially for VoIP) should take into account the mobility features that are already available at the application layer (e.g., SIP re-INVITEs), and discuss how these features interact with mobility at other layers. Minor issues: none S4.7: How does NEMO relate to normal use of the routing protocols to detach and reattach a network? A couple of sentences would be helpful here. S4.15: It's not really accurate to say that global HAHA avoids triangle routing, since it actually does make a triangle. In Figure 6, there's a missing arrow from the CN to the nearby HA, which completes the HA-HA-CN triangle. So it's not that sufficient density avoids triangle routing, it just makes it less of a big deal because the HAs are close to the endpoints. S4.17 P1: I'm a little mystified as to how something is published in the DNS, and only accessible to the subscriber. Quick clarification would be helpful. Nits/editorial comments: S2, Locator: It could be helpful to note here that you're talking about *topological* location, not geolocation.s S4.8 P1: The phrase universally deployed is used a
