> First, I'll deal with the technical/content issues: > > (1) I think that this document should explicitly state, in the > introduction, that it is not a standard and is not intended to > modify or contradict any IPv6 standard documents. I thought that > we had agreed to something like this earlier.
=> This was in the document, then we received another comment stating that since the RFC states whether it is informational, standards ...etc, there is no need to say this in the doc. > > (2) The document states: > > "Additionally, due to special characteristics of the > cellular link, > lower layer connectivity information should make it > unnecessary to > track the reachability of the router. Therefore, while > the host must > support Neighbor Solicitation and Advertisement > messages, their use > is not necessary and the host may choose to not initiate them." > > Although I understand the desire to supress NUD messages on > point-to-point cellular links, this isn't how/why this should > be done. > > IPv6 hosts must include a full implementation of Neighbor Discovery, > including NUD with the full ND state machine, etc. Any compromise > on this effectively results in two different types of IPv6 hosts, > each with different behaviours/failure modes, etc. That > is something > that we definitely want to avoid. > There is no magic (in 3GPP or any other network) that can > guarantee that another node is always reachable, but it is > certainly possible for other layers of the protocol stack > (outside of IP) to maintain information about reachability, > and to know, at a given time, that another node is reachable. > ND includes the ability for those other protocol layers to > provide advice to the NUD code to indicate that a remote host > is reachable (only when those layers have confirmed two-way > reachability), which results in the supression of NUD messages > when the network is operating properly. The other layers of > 3GPP should provide this advice to ND. > > In cases were the GGSN actually does become unreachable, NUD > messages will be sent. But, in fact that NUD actually > _reduces_ the > amount of traffic that will sent over the air interface > while the GGSN is > unreachable, so this is actually a good thing for 3GPP. > > Instead of indicating that parts of ND are optional, or that > 3GPP hosts may "choose to not" use them, we should be indicating > what layers of 3GPP should provide reachability advice to ND at > what points. If those other layers can confirm two-way reachability > on an ongoing basis, they can provide frequent advice that will > result in the supression of all NUD messages when things are > operating properly. => I understand your points, however, we cannot say that 3GPP 'should' do anything. We are dealing with existing 3GPP and IETF specs. Luckily, for this particular case, the information is already available to those who can use it, so we can add more text to highlight that hosts should use the lowe layers' reachability information. > > (3) The document states: > > "This specification [RFC-2402] must be supported. The > IPsec WG has > discussed the role of AH in the future, and it is > possible that it > will be made optional in the future versions of the > IPsec protocol > set. Implementers are recommended to take this in account." > > I don't like the idea of writing a document today that tells > implementors that it is possible that something will be made > optional in the future. Today it is mandatory. Period. => OK. > > (4) The document states: > > "4. Mobility > > For the purposes of this document, IP mobility is not > relevant. When > Mobile IPv6 specification is approved, a future update to this > document may address these issues, as there may be some > effects on > IPv6 hosts due to Mobile IP. The movement of cellular > hosts within > 3GPP networks is handled by link layer mechanisms." > > There is a portion of mobility -- I believe that is is called the > "correspondent node option", or something like that -- that must be > implemented in all IPv6 hosts, in order to allow optimal routing > to mobile nodes that are away from their home networks. > This document > should indicate that support for that feature is required. => Within the current MIPv6 spec, this CN portion is nothing. I.e. nothing to add to a standard IPv6 host. I'll send a separate reply for editorials. Thanx, Hesham > Now, for the editorial issues: > > (5) In section "1 Introduction", the only paragraph is not > properly laid out -- not clear if it is meant to be one or > two paragraphs. > > (6) The document states: > > "Cellular hosts should not support configured or > automatic tunnels to avoid unnecessary tunneling over the air > interface, unless there are no other mechanisms > available. Tunneling > can lead to poor usage of available bandwidth. " > > The "should not support...unless there are no other" construct > is somewhat confusing, since there probably isn't any way for > a host to know whether there are other mechanisms available. > > Although I understand why tunneling should be avoided over the > air interface if possible, I don't understand why this is a host > implementation issue. Isn't this more of an issue for the > operators? If so, it probably doesn't belong in this document. > > (7) As someone else mentioned, the following sentence is > similarly confusing: > > "Multicast Listener Discovery [RFC-2710] may be > supported, if the > cellular host is supporting applications that require > the use of > multicast services." > > (8) I also think that the following sentence is more advice for 3GPP > network operators, than it is specific to cellular hosts: > > "Hence, > intermediate 6to4 routers should carry out 6to4 > tunneling, instead > of cellular hosts." > > There is an ongoing effort in the ngtrans WG to discuss transition > scenarios for 3GPP (run by Jonne Soininen), and it is expected that > that group will define what type of transition mechanisms are most > applicable to 3GPP networks. So, perhaps it is best to leave this > operator advice for that group? > > (9) I don't think that you should put "Manyfolks" in the footers, > in the place of the author name. List the first author with et.al. > Or, better yet, switch to listing an editor in the footer and at > the top of the document, and list the authors in a section at the > end. > > Margaret > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
