(1) What type of RFC is being requested (BCP, Proposed
Standard, Internet Standard, Informational, Experimental, or
Historic)? Why is this the proper type of RFC? Is this type
of RFC indicated in the title page header?
We are requesting publication as an Informational RFC.
Because the document describes a large-scale NAT deployment
scenario using BGP/MPLS VPNs, and does not specify a
protocol or protocols, it is appropriate for publication as
an informational document.
(2) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:
Technical summary: This document specifies a framework to
integrate a Network Address Translation layer into an
operator's network to function as a Carrier Grade NAT (also
known as CGN or Large Scale NAT). The CGN infrastructure
will often form a NAT444 environment as the subscriber home
network will likely also maintain a subscriber side NAT
function. The model included in this document utilizes
BGP/MPLS IP VPNs which allow for virtual routing separation
helping ease the CGNs impact on the network. This document
does not intend to defend the merits of CGN.
Working group summary: While there was clear support for
the document within the opsawg, there was little discussion
and no comments during working group last call. However, the
authors were quite proactive about getting feedback from
operators outside the working group context, and having
that feedback posted to the working group mailing list, so
we feel that the document received satisfactory expert
review prior to and during last call. (This was discussed
with the OPS ADs after closing working group last call).
Document quality: This is a well-written document that
clearly lays out the background, requirements, and
deployment scenarios using straightforward, unambiguous
language. It received expert review from cable and telecomm
operators during its development, and the authors are
employed by Rogers Communication, a large Canadian telecomm
firm.
Personnel: Melinda Shore is the document shepherd.
(3) Briefly describe the review of this document that was
performed by the Document Shepherd. If this version of the
document is not ready for publication, please explain why
the document is being forwarded to the IESG.
The document shepherd has read each version of the draft as
it has progressed, agrees that it is technically correct,
and feels that it is ready for publication.
(4) Does the document Shepherd have any concerns about the
depth or breadth of the reviews that have been performed?
No. This document received extensive review from experts
outside the opsawg, including from CableLabs, Comcast, and
NTT.
(5) Do portions of the document need review from a
particular or from broader perspective, e.g., security,
operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took
place.
No
(6) Describe any specific concerns or issues that the
Document Shepherd has with this document that the
Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there
really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.
None
(7) Has each author confirmed that any and all appropriate
IPR disclosures required for full conformance with the
provisions of BCP 78 and BCP 79 have already been filed. If
not, explain why?
Yes
(8) Has an IPR disclosure been filed that references this
document? If so, summarize any WG discussion and conclusion
regarding the IPR disclosures.
None
(9) How solid is the WG consensus behind this document? Does
it represent the strong concurrence of a few individuals,
with others being silent, or does the WG as a whole
understand and agree with it?
As described above, there was no comment during the working
group last call, and there has been no partisan orchestrated
political support. However, there is clear consensus among
those who have reviewed the document that it is both
valuable and mature. Again, this has been discussed with
the OPS area directors.
(10) Has anyone threatened an appeal or otherwise indicated
extreme discontent? If so, please summarise the areas of
conflict in separate email messages to the Responsible Area
Director. (It should be in a separate email because this
questionnaire is publicly available.)
No, there have been no dissenting comments.
(11) Identify any ID nits the Document Shepherd has found in
this document. (See http://www.ietf.org/tools/idnits/ and
the Internet-Drafts Checklist). Boilerplate checks are not
enough; this check needs to be thorough.
There are two outdated references, which will need to be
corrected prior to publication:
== Outdated reference: A later version (-06) exists of
draft-donley-behave-deterministic-cgn-05
== Outdated reference: draft-donley-nat444-impacts has
been published as RFC 7021
(12) Describe how the document meets any required formal
review criteria, such as the MIB Doctor, media type, and URI
type reviews.
Not applicable
(13) Have all references within this document been
identified as either normative or informative?
Yes.
(14) Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the plan
for their completion?
No.
(15) Are there downward normative references references (see
RFC 3967)? If so, list these downward references to support
the Area Director in the Last Call procedure.
No.
(16) Will publication of this document change the status of
any existing RFCs? Are those RFCs listed on the title page
header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the
document where the relationship of this document to the
other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.
No.
(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its
consistency with the body of the document. Confirm that all
protocol extensions that the document makes are associated
with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have
been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial
contents for the registry, that allocations procedures for
future registrations are defined, and a reasonable name for
the new registry has been suggested (see RFC 5226).
There are no IANA requests in this document.
(18) List any new IANA registries that require Expert Review
for future allocations. Provide any public guidance that the
IESG would find useful in selecting the IANA Experts for
these new registries.
None.
(19) Describe reviews and automated checks performed by the
Document Shepherd to validate sections of the document
written in a formal language, such as XML code, BNF rules,
MIB definitions, etc.
Not applicable.