Here are some additional review comments from various IESG reviewers: > RFC 3155 should be added to the normative refs in my > opinion. I'm not opposed to keeping the non-normative > ref to the 2.5/3G TCP issues draft that started me on > this.
Another reviewer: > Comments on draft-ietf-ipv6-cellular-host-02.txt > 2.4.1 says that the host must support receipt of > Neighbor Solicitation and Advertisement messages. > But 2.5.1 says "will not be sent or received" which might seem > conflicting at least with respect to the receive part. > DAD for 3041 addresses? > Will the router only have a link-local address on the link? > If not, how to detect a 3041 conflicting with one of the routers > addresses? > 2.12 - 3041 MAY be used. Do we want something stronger? > MLD: > multicast services. There is no need for MLD if the host only > supports the well-known (hard coded in IPv6 implementations) link > local multicast addresses. MLD is not used for listening on such > addresses. > Only applies to all-nodes address (ff02::1). > RFC2461 says that a node must join > the solicited-node multicast address(es) on multicast-capable interface, > and point-to-point interface are specifically treated as > point-to-point - Neighbor Discovery handles such links just like > multicast links. > > Thus per the letter of the specifications MLD must be implemented > by cellular hosts. > This also effects the need to support RFC2711 (section 2.10). > 2.11 > (IPv4 vs. IPv6). 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 bandwidth concern is a reason not to *use* tunneling, but > the point about it being a last resort seems to say that it would > be useful to implement this. However, the text "should bot support" > seems to mean "should not implement". > Same issue for section 2.13 on 6to4 tunneling. > 2.15: and all useful hosts have at least a link-local address > and a larger scope address. So why not say "must be supported" > instead of qualifying it with a tautology? > 2.16 - add reference to RFC 3152. RFC 1886 talks about ip6.int > thus the ip6.arpa document must be referenced. > Section 3 - how about adding that future IPsec algoritms might be > useful/supported in the future. > Currently only DES, HMAC-MD5, and HMAC-SHA1 are listed. More comments: > AES is coming, should be supported in fugure. Mention this? > > The docuent is vague on key management. It basically doesn't say what > will be used for key management, and that begs the question of what > kind of interoperability will be achieved. > > If AKA is the solution, then this needs to be made more clear in the > document. Isn't it the case that AKA is what the overall > theme for 3GPP? > > What is needed is a clear statement on how interoperability with > regards to key management will be obtained. If this is not actually > known today, then the document should just say we haven't decided yet, > but will decide down the road. > > The document lists 7 authors. This number is considered on the high > side. See draft-rfc-editor-author-lists-00.txt (which is being Last > Called as we speak). -------------------------------------------------------------------- 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] --------------------------------------------------------------------
