[Ballot discuss]
1. The security considerations section here appears to be way
too brief. I'd like to have known when it is safe to use
this, and especially when it is not safe, e.g. if the g/w is
on the customer premises and the CID is an IPv4 address,
could the customer (hacking the g/w) hijack someone else's
(guessable) CID? (That may or may not be a real threat,
but I found it hard-to-impossible to figure out based on
this draft.)

[Ballot comment]
- p7, what does "must have a proper understanding" mean?

- p8, CE, PE and ECMP are not expanded (and maybe need a
reference/definition, particularly ECMP)

- Please consider the points raised in Tobias Gondrom's
secdir review. [1]

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03029.html

[Ballot discuss]
1. The security considerations section here appears to be way
too brief. I'd like to have known when it is safe to use
this, and especially when it is not safe, e.g. if the g/w is
on the customer premises and the CID is an IPv4 address,
could the customer (hacking the g/w) hijack someone else's
(guessable) CID? (That may or may not be a real threat,
but I found it hard-to-impossible to figure out based on
this draft.)

2. RFC 6275's security considerations don't appear to apply
to this in an obvious way, which part(s) of RFC6275 section
15 are relevant here? Same question applies to RFC 5213.

3. TS29060 seems like a normative reference, why is it not?
Is version 9.1.0 the right version to reference? (there seem
to be many) That document (on page 143 of 155) has a two line
section 12 on security which is just a reference to something
else. I don't know what is meant by referring to this from
section 9 here.

[Ballot comment]

- p7, what does "must have a proper understanding" mean?

- p8, CE, PE and ECMP are not expanded (and maybe need a
reference/definition, particularly ECMP)

- Please consider the points raised in Tobias Gondrom's
secdir review. [1]

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03029.html

[Ballot comment]
I have no objection to the publication of this document, but I note that
the Security Considerations section is flimsy. Surely there are security
issues with how the mapping table at the AFTR is built. Although that is
a "local matter" inplementers and deployers need to be aware that this
feature must be secured.

[Ballot comment]
There is only one use of 2119 language, and I'm not convinced it's necessary:

  o  The softwire between the Gateway and the AFTR MAY be created at
      system startup time OR dynamically established on-demand.

Is this a protocol option that one or both sides needs to be aware of? That is, does the Gateway or the AFTR need to prepare itself for on-demand establishment, or to be prepared that on-demand might not be available? I suspect you can change it to "may" or "can" and delete the reference to 2119.

[Ballot comment]
Section 6 lists a set of abbreviations to describe the type of IPv4 addresses being used in a deployment.  I understand all the possibilities, except for "nm" (described as non-meaningful/dummy).  This that just a diplomatic way of describing a network deployment that is squatting on someone's public IPv4 address space?

State changed to In Last Call from In Last Call.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <softwires@ietf.org>
Reply-To: ietf@ietf.org
Subject: REVISED Last Call: <draft-ietf-softwire-gateway-init-ds-lite-06.txt> (Gateway Initiated Dual-Stack Lite Deployment) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'Gateway Initiated Dual-Stack Lite Deployment'
  <draft-ietf-softwire-gateway-init-ds-lite-06.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual-
  Stack lite (DS-lite) applicable to certain tunnel-based access
  architectures.  GI-DS-lite extends existing access tunnels beyond the
  access gateway to an IPv4-IPv4 NAT using softwires with an embedded
  context identifier that uniquely identifies the end-system the
  tunneled packets belong to.  The access gateway determines which
  portion of the traffic requires NAT using local policies and sends/
  receives this portion to/from this softwire.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1411/
  http://datatracker.ietf.org/ipr/1630/

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <softwires@ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call: <draft-ietf-softwire-gateway-init-ds-lite-05.txt> (Gateway Initiated Dual-Stack Lite Deployment) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'Gateway Initiated Dual-Stack Lite Deployment'
  <draft-ietf-softwire-gateway-init-ds-lite-05.txt> as a Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Gateway-Initiated Dual-Stack lite (GI-DS-lite) is a variant of Dual-
  Stack lite (DS-lite) applicable to certain tunnel-based access
  architectures.  GI-DS-lite extends existing access tunnels beyond the
  access gateway to an IPv4-IPv4 NAT using softwires with an embedded
  context identifier that uniquely identifies the end-system the
  tunneled packets belong to.  The access gateway determines which
  portion of the traffic requires NAT using local policies and sends/
  receives this portion to/from this softwire.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-gateway-init-ds-lite/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1411/
  http://datatracker.ietf.org/ipr/1630/

Please advance in the process and publish the draft from the
Softwires WG. Here is the proto writeup for the draft:
draft-ietf-softwire-gateway-init-ds-lite-05.txt

>(1.a) Who is the Document Shepherd for this document? Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?
Yong Cui is the Shepherd. I have reviewed the documents and
believes they ready for publication.

> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members? Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?
We saw evidence of some reviews on the mailing list. The documents
has been presented in softwires. Comments from the meetings and
Mailing list were integrated.


> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?
No concerns.

> (1.d) Does the Document Shepherd have any specific concerns or
> issues 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. Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.
This is strictly a protocol specification.
No IPR disclosures have been submitted directly on this I-D, but there
are related disclosures.
http://datatracker.ietf.org/ipr/search/?option=document_search&id_document_
tag=20006
Both companies who submitted IPR claims on the document were using
the standard terms, allowing any party to implement the standard.


> (1.e) 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?
We had WG last call and there's no further comments.

> (1.f) 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
> entered into the ID Tracker.)
No.

> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See theInternet-Drafts
>Checklist <http://www.ietf.org/id-info/checklist.html>
> andhttp://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough. Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?
There is an obsoleted normative reference, RFC 3775, which should be
replaced by RFC 6275.
No other nits issues, and no need for MIB Doctor reviews.

> (1.h) Has the document split its references into normative and
> informative? 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
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].
Clean.

> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document? If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC5226]. If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?
There is no IANA registry needed in this document.


> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?
There is no formal language in the document.

> (1.k) 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
> Relevant content can frequently be found in the abstract
> and/or introduction of the document. If not, this may be
> an indication that there are deficiencies in the abstract
> or introduction.
Gateway-Initiated DS-Lite
This document specifies a Gateway-Initiated Dual-Stack lite
(GI-DS-lite) applicable to certain tunnel-based access
architectures. GI-DS-lite extends existing access tunnels beyond the
access gateway to an IPv4-IPv4 NAT using softwires.

> Working Group Summary
> Was there anything in WG process that is worth noting? For
> example, was there controversy about particular points or
> were there decisions where the consensus was particularly
> rough?
This document was discussed in depth and well-reviewed. The overall
WG consensus is strong to publish this document.

> Document Quality
> Are there existing implementations of the protocol? Have a
> significant number of vendors indicated their plan to
> implement the specification? Are there any reviewers that
> merit special mention as having done a thorough review,
> e.g., one that resulted in important changes or a
> conclusion that the document had no substantive issues? If
> there was a MIB Doctor, Media Type or other expert review,
> what was its course (briefly)? In the case of a Media Type
> review, on what date was the request posted?
As we know, there is no existing implementations now, but some vendors
have the plan to implement and release the related product.