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? 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]. 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? There are more than the usual quantity of acronyms in this document. I encourage you to do a final pass to check that 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. Also missing: "user plane". 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? In addition to the above, I didn't see any reason to make a distinction between TE+MT and UE. Section 2, Terminal Equipment: s/to the use./to the user./ Figure 2 shows the UTRAN and BSS as nodes (boxes) rather than composite systems (clouds). That might be misleading. 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. 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. Section 5.2 needs a citation for RFC 4861. 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. Section 8.1, Point 3: s/be build on IPv6/be built on IPv6/ 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. 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". _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
