All, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments. My apologies for the ludicrous lateness of this review (which I gather is on the IESG telechat agenda today). I'll also note up front that following various converging employment changes since this document's birth, I am now a colleague of Victor Kurasingh (the top-listed editor of this document) at Dyn. I don't have any special reason to go easy on the document because of our day-job proximity, but full disclosure, etc. Executive Summary Ready with nits. Editorial A few sections of the document contain textual problems that seem worth calling out in this review, since it might not be as obvious to staff at the RFC Editor what suitable corrections should be as it is to a technical reviewer. I have hence included some, despite the fact that they would not normally belong in an Ops area review. Section 1.1, "Internal Realm" -- replace "been" with "between" Section 3, near end of first para -- replace "add additive" with "are additive" (or "add") Section 3.2, mid first para -- replace "be best served" with "be best served by" Section 3.2, suggest modifying the final paragraph to make it sound a little less hysterical, e.g. "are under considerable pressure to deliver greater access bandwidth, and any inefficiencies in forwarding due to the use of CGN must be minimised". Section 4.4.1, second para, replace "others options" with "other options". Terminology The document assumes in various places that address pools which are not globally unique will, however, be naturally unique within an operator's network. See for example section 3.3. To be more general, the document might define a term for the domain within which subscriber addresses are unique and mention that an operator's network might contain more than one such domain. This is illustrated explicitly in section 3.6, which as written seems at odds with this assumption. The acronym "GRT" is used in various diagrams apparently as a short-hand for a domain within the network in which reachability (and hence address assignment) is globally-unique. This might be spelt out, since otherwise the idea of forwarding a packet into a routing table is a bit mentally jarring (a bit like directions which send a car into a driver's licence). Operations (see RFC 5706 section 2.1) The document is motivated by a need to deploy CGN in a way that is operationally simple and flexible, and does a good job at outlining the corner cases that need to be considered before an operator chooses an approach. The proposed approach seems more sane than the alternatives that are summarised in the document. Installation and Initial Setup (see RFC 5706 section 2.2), and Migration Path (see RFC 5706 section 2.3) It is impractical to imagine that this document (or one like it) could make detailed recommendations for implementation that would be relevant generally to all networks. Sensibly, the document does not attempt to do so. Requirements on Other Protocols and Functional Components (see RFC 5706 section 2.4), and Impact on Network Operation (see RFC 5706 section 2.5), and Verifying Correct Operation (see RFC 5706 section 2.6), and Interoperability (see RFC 5706 section 3.1), and Management Information (see RFC 5706 section 3.2), and Fault Management (see RFC 5706 section 3.3), and Configuration Management (see RFC 5706 section 3.4), and Accounting Management (see RFC 5706 section 3.5), and Performance Management (see RFC 5706 section 3.6), and Security Management (see RFC 5706 section 3.7) The document's proposal makes conventional use of existing techniques and protocols, and does not introduce any new requirements on them. Similarly, there is no obvious impact on network operations beyond those already required for the operation of CGNs and MPLS networks. Documentation Guidelines (see RFC 5706 section 4) The document doesn't follow the guidelines outlined in RFC 5706. Doing so would have made this review a little easier, but I don't think would have significantly helped the clarity or usefulness of the text, given the context of the discussion which is clearly the presentation of an architectural approach rather than the design of a protocol or guidance for implementation. Joe Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail