> 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.
=> OK, will fix that. > > 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. => I don't understand what you mean? It's a host issue because the tunnel originates from the host. > > (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." => Yep. Fixed that already in my hidden new version :) > > (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." => OK. I'm not sure that it is a bad thing though. > > 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? => OK. > > (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. => Yeah, we can fix that in the next revision. I hope that, if there are no major issues during the WG last call, we can update the draft once to include the WG last call comments and IESG last call comments. Is that possible? Hesham -------------------------------------------------------------------- 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] --------------------------------------------------------------------
