Hi Martin, Thank you for a thorough review! I have few comments/answers inline.
On Aug 9, 2011, at 8:53 AM, Thomson, Martin 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>. > > Document: draft-ietf-v6ops-3gpp-eps-03 > Reviewer: Martin Thomson > Review Date: 2011-08-10 > IETF LC End Date: 2011-08-12 > IESG Telechat date: > > Summary: This draft is ready for publication as an informational RFC. > > The document does a reasonable job of summarizing the state of IPv6 > deployment for 3GPP access. There are a number of editorial issues that > affect readability, but nothing that should prevent this from going to the > RFC editor. > > Major issues: none > > Minor issues: none > > Nits/editorial: > > The draft relies on a definition of "layer-2" that is implied. For instance, > from Section 5: > > [...] The mobile host must > always support layer-2 based address configuration, [...] > > It's easy to infer from reading further that "layer-2" implies "pre-IP", but > that view is at odds with the view that other nodes necessarily have: > signaling is distinctly layer-7 to those that operate upon it. Is this > accurate? Right.. maybe we should also say that PDP context/EPS bearer setup procedures equals setting up the layer-2 link and the address configuration can be part of that signaling? > > The mobile host must always support address configuration using signaling > during bearer setup, ... > > Idnits picked up two warnings, one of which is a false alarm, the other of > which is a downref to draft-ietf-dhc-pd-exclude. What is the publication > status of the prefix delegation exclusion draft? > > [...] IETF is working on a solution > for DHCPv6-based prefix delegation to exclude a specific prefix from > the 'delegated prefix' [I-D.ietf-dhc-pd-exclude]. In its 3rd WGLC as we speak. > Rather than make this statement, which wont be of any value once pd-exclude > is published or not. Could you make a statement that is less temporary? > Does 3GPP reference the mechanism in pd-exclude? The pd-exclude is referenced from 3GPP. How about: is not part of the 'delegated prefix'. IETF defined solution to exclude a specific prefix from the 'delegated prefix' is used to enable this [I-D.ietf-dhc-pd-exclude]. > > There are more than the usual quantity of acronyms in this document. I > encourage you to do a final pass to check that Welcome to 3GPP ;) > each is expanded on first use. There were a few that I encountered, but I > probably missed a few instances. PDN, "PDP Type" (as opposed to context), > NAT44. Fortunately [*], the target audience should have sufficient context > to wade through the dense thicket of acronyms and terms without needing this; > I pity the reader who is unfamiliar with the 3GPP architecture. Ok. I'll check for these. > Also missing: "user plane". Ok. > The decision to interchangeably use UE, MN, Mobile, etc... is greatly > confusing to a reader. My experience with 3GPP specifications shows a > consistent use of "UE", can you not also choose one form and consistently use > that? Ok. Will consistently change everything to UE. > In addition to the above, I didn't see any reason to make a distinction > between TE+MT and UE. Ok. If you refer to Figure 2 I can change that to the UE. > Section 2, Terminal Equipment: s/to the use./to the user./ Ok. > Figure 2 shows the UTRAN and BSS as nodes (boxes) rather than composite > systems (clouds). That might be misleading. Ok. I'll try fitting clouds there. > Sections 3 and 4 duplicate some of the information that is provided in > Section 2. For instance, the definition of the eNodeB and MME is duplicated > at the end of Section 4.1. Ok. Will remove duplicates. > Section 5.2 includes a citation for DHCPv6 that is placed in a way that > implies more than I think is intended. RFC 3315 supports the definition > rather than the statement. > Stateful DHCPv6-based address configuration is not supported by 3GPP > specifications [RFC3315]. > Suggest: > Stateful DHCPv6-based address configuration [RFC3315] is not supported > by 3GPP specifications. Sounds better. Will change this. > Section 5.2 needs a citation for RFC 4861. Ok. > Section 5.2 uses "must" and "may" several times. Since these statements are > not prescriptive, they could probably use other forms, for instance: > > This implies that the M-bit _is_ always clear in the Router Advertisement > (RA) [RFC4861] sent to the UE. Ok. > Section 8.1, Point 3: s/be build on IPv6/be built on IPv6/ Ok. > The language in Section 8.5 is hard to parse. Consider breaking the first > paragraph (the list structure). Re-consider the use of colloquialisms like > "basically" and the use of parenthetical statements. Right.. I'll try to reword this section. > Section 8.6: > Other types of configurations are considered network planning > mistakes. > Seems like a value statement, rather than a statement of fact. [*] See also > statements containing "unfortunately". Do you have a suggestion for better wording? The statement is here because it is possible and rather easy to deploy a network that allow other types of handovers. However, in that case the outcome is unpredictable, especially when the network has equipment from multiple vendors.. and those cases and recovery procedures are not even documented. - Jouni _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
