Deployment Considerations for Dual-Stack Lite
draft-ietf-softwire-dslite-deployment-08

[Ballot comment]
I've not checked if these comments still apply to -08 or not
so ignore text below as appropriate:-)

- 2.6 is probably also a bit wrong in how it talks about users.
I also wasn't sure what was meant by "an abused user"?

- 2.11 could do with a reference to rfc 6280, since that
represents our BCP for location and location privacy handling.

- 2.13: Just checking, but does PCP base handle this with the
simple security model? I can never recall. There was a recent
thread on the pcp list about that and it might be worth a look
to see if PCP-base is ok here. (The statement in this draft is
true though, PCP-base was designed to handle this, the question
is whether or not the security model in PCP-base does that well
enough.)

- secdir review [1] has a couple of nits

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

[Ballot discuss]
-07 addressed my discuss point 1, but I don't believe that
I see changes for the others, nor have I seen mail on them,
so I'd still like to DISCUSS them. (Sorry if I missed some
mail with a different subject or something.)

-08 tried to fix point 2, but missed the point. Still no
mail so I mailed them:-)

1) cleared

2) 2.5 is incorrect in talking about "users," what is being
identified is really a B4 isn't it? And there could be many
users/hosts in the customer premises. I think that is
sufficiently important to fix since it has happened that people
have been wrongly blamed for actions simply due to this
confusion of addresses and users.

3) cleared

[Ballot discuss]
-07 addressed my discuss point 1, but I don't believe that
I see changes for the others, nor have I seen mail on them,
so I'd still like to DISCUSS them. (Sorry if I missed some
mail with a different subject or something.)

-08 tried to fix point 2, but missed the point. Still no
mail so I mailed them:-)

1) cleared

2) 2.5 is incorrect in talking about "users," what is being
identified is really a B4 isn't it? And there could be many
users/hosts in the customer premises. I think that is
sufficiently important to fix since it has happened that people
have been wrongly blamed for actions simply due to this
confusion of addresses and users.

3) 3.1: Wasn't there some issue with DNSSEC here? (I don't
recall right now) If so, I think that'd warrant a mention. If
not, sorry:-)

[Ballot comment]
I've not checked if these comments still apply to -07 or not
so ignore text below as appropriate:-)

- 2.6 is probably also a bit wrong in how it talks about users.
I also wasn't sure what was meant by "an abused user"?

- 2.11 could do with a reference to rfc 6280, since that
represents our BCP for location and location privacy handling.

- 2.13: Just checking, but does PCP base handle this with the
simple security model? I can never recall. There was a recent
thread on the pcp list about that and it might be worth a look
to see if PCP-base is ok here. (The statement in this draft is
true though, PCP-base was designed to handle this, the question
is whether or not the security model in PCP-base does that well
enough.)

- secdir review [1] has a couple of nits

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

[Ballot comment]
(Clearing the discuss points. I still encourage adding a discussion as below)

Consider explicitly pointing to HELD (RFC5985) when discussing the effect this architecture has on determining geolocation based on an IP address, and to HELD's extensions as examples of ways to get better identifiers to use as input.

[Ballot comment]
The -07 version resolves my DISCUSS items and addresses my non-blocking comments as well.  I think it's a much better document than the previous version, and thanks very much for the work you've done on it.

[Ballot discuss]

-07 addressed my discuss point 1, but I don't believe that
I see changes for the others, nor have I seen mail on them,
so I'd still like to DISCUSS them. (Sorry if I missed some
mail with a different subject or something.)

1) cleared

2) 2.5 is incorrect in talking about "users," what is being
identified is really a B4 isn't it? And there could be many
users/hosts in the customer premises. I think that is
sufficiently important to fix since it has happened that people
have been wrongly blamed for actions simply due to this
confusion of addresses and users.

3) 3.1: Wasn't there some issue with DNSSEC here? (I don't
recall right now) If so, I think that'd warrant a mention. If
not, sorry:-)

[Ballot comment]

I've not checked if these comments still apply to -07 or not
so ignore text below as appropriate:-)

- 2.6 is probably also a bit wrong in how it talks about users.
I also wasn't sure what was meant by "an abused user"?

- 2.11 could do with a reference to rfc 6280, since that
represents our BCP for location and location privacy handling.

- 2.13: Just checking, but does PCP base handle this with the
simple security model? I can never recall. There was a recent
thread on the pcp list about that and it might be worth a look
to see if PCP-base is ok here. (The statement in this draft is
true though, PCP-base was designed to handle this, the question
is whether or not the security model in PCP-base does that well
enough.)

- secdir review [1] has a couple of nits

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

[Ballot comment]
While I agree with most of the DISCUSS and COMMENT (not all btw), I believe this "Deployment Considerations" draft is useful.
I'm available to help the authors/ADs on this document, if necessary

See also the OPS-DIR review from Tim Chown. Feel free to discuss it with me

[Ballot comment]
`I stongly support Stephen's Discuss related to wiretap. I understand
that the provision of wiretap is something that operators may be
required to think about by their regulators. However, with RFC 2804 in
place, the IETF should not publish documents that "encourage" wiretap.

---

In section 2.6

  an abused user

Is this an abusive user, or maybe an abusing user?

---

I tried, but couldn't find any other issue that is not already caught by
another AD's Discuss or Comment.

[Ballot comment]
I ballot no objection, solely on the basis that the other DISCUSS ballots cover all of my issues that would be worth a DISCUSS or comments.

One general concern:
This document lacks a terminology section, e.g., that readers should be familar with certain other documents, e.g., RFC 6333 and the terminology of it.

[Ballot comment]
While I agree with most of the DISCUSS and COMMENT (not all btw), I believe this "Deployment Considerations" draft is useful.
I'm available to help the authors/ADs on this document, if necessary

[Ballot discuss]
General
======-
A major flaw of this document is that it

- restates protocol details that are described normatively in other documents
- offers implementation advice
- recommends new features for implementations

Once all of that is stripped away, I wonder whether the remaining document will be worth publishing



Section 2.1
===========
Recommends that operators deploy two interfaces, as opposed to a single, dual-stacked interface. The only rationale offered is "to segregate the functions". Could you explain why segregation is desirable?

Section 2.2
===========
Doesn't appear to say anything that isn't already said by Section 6.3 of RFC 6333. Beyond that, it offers no deployment advice. A good piece of deployment advice would be to do everything possible to eliminate the need for fragmentation. Even if fragmentation is possible, it will adversely impact performance.

Section 2.3
==========
Appears to be implementation advice, and not a deployment consideration. However, I am not sure that I agree with the advice that it offers. The v4 packet set the DF bit. Why should that preclude fragmentation of the v6 packet.

Section 2.4
===========
Concur with Stephen Farrell's DISCUSS

Section 2.6
===========
Does not offer advice to the party deploying DS-Lite. It offers advice to a much, much larger community of Internet users and application developers.

Section 2.8
===========
Reminds the operator that he can't collect accounting information from an encapsulated packet (i.e., between the B4 and AFTR). Beyond that, it doesn't offer much helpful advice.

Section 2.0
===========
Appears to be a feature request.

Section 2.11
============
Concur with Brian's DISCUSS

Section 2.12
============
Offers no advice beyond that offered by RFC 2983

Section 3
==========
Concur with Brian's DISCUSS

[Ballot comment]
`I stongly support Stephen's Discuss related to wiretap. I understand
that the provision of wiretap is something that operatros may be
required to think about by their regulators. However, with RFC 2804 in
place, the IETF should not publish documents that "encourage" wiretap.

---

In section 2.6

  an abused user

Is this an abusive user, or maybe an abusing user?

---

I tried, but couldn't find any other issue that is not already caught by
another AD's Discuss or Comment.

[Ballot comment]
I support the discusses raised the other ADs and think these
comments overlap with theirs, but just in case...

In view of the volume of discusses, please can I suggest that the authors respin the document and it is returned to the IESG with a fresh ballot.

====


"DS-Lite is part tunneling protocol." does not scan.

===

the B4 element .. does not seem to be defined before use

===

I agree that section 2.4 should be deleted as its inclusion
is a violation of IETF policy.

===

Depedning on the rate of NAT table changes
Typo Depending

===

I agree:

  Internet hosts
  such as servers must no longer rely solely on IP address to identify
  an abused user. 

looks out of scope for this document, and should be in a host
specification RFC.

====

Another possibility is that the applications could rely
  on location information such as GPS co-ordination to identify the
  user's location.  This technique is commonly used in mobile
  deployment where the mobile handheld devices are probably usually
  behind a NAT device.


"probably usually" is an odd combination, but in any case I can't
see fixed and semi-fixed systems providing this information, indeed
they have a strong incentive to lie about it.

===

  An operator may assign the
  same IPv4 address (e.g. 192.0.0.2/32) to all AFTRs.  This IPv4
  address only used to respond to the requests from the B4 elements
  over the softwire.  IANA allocates 192.0.0.0/29 [RFC6333] which can
  be used for this purpose.

I am unclear if the two 192 addresses are supposed to be that same of not.
The para could use rewording for clarity.

===

  Some of the security issues result directly from sharing routable
  IPv4 addresses.  Addresses and timestamps are often used to identify
  a particular user, but with shared addresses, more information (i.e.,
  protocol and port numbers) is needed. 

This needs a back ref to where you discuss the issue in more detail.
I am surprised that there is not more discussion of this problem in
conjunction with the IPv4 CGN that is referenced here.

[Ballot discuss]
I agree with Stephen's discuss on Section 2.4, and the suggestion to remove the section. This is a special case considerations around "identifying the endpoint" that is already discussed elsewhere in the document.

[Ballot comment]
Consider explicitly pointing to HELD (RFC5985) when discussing the effect this architecture has on determining geolocation based on an IP address, and to HELD's extensions as examples of ways to get better identifiers to use as input.

I support Barry's discuss points.

[Ballot discuss]
1. In addition to Barry's list of sections that talk about implementation issues, rather than deployment issues, I would note that:

* The last sentence of 2.2 certainly sounds like implementation guidance
* Section 2.8 seems to mandate certain functions within implementations to support accounting
* Section 3 is mandating features for a B4 implementation

2. The guidance in section 2.11 seems to imply that operators should put more exact information into Geo-IP databases in order to facilitate location-based services.  If that is the intent, it should be stated more explicitly.  In the long run, I don't see this advice being useful given the whole list of issues that arise with the maintenance of such databases.

[Ballot comment]
1. I support both Barry's and Stephen's DISCUSS points.

2. The term B4 does not seem to be defined anywhere even though AFTR is defined.

3. In section 2.5 : s/Deny-of-Service/Denial-of-Service/ and s/Depedning/Depending/

4. Section 2.7 : s/polices/policies/

5. Section 3.2.1 : It would be good to add a reference for TR-069.

6. It is unclear why Section 5 even exists.

[Ballot discuss]

1) section 2.4 discusses lawful intercept but the IETF have a
consensus (see RFC 2804) to not standardise wiretapping
features. While this isn't a standards-track document, 2.4 is
recommending how to do wiretap. I'd rather see 2.4 deleted
since I think that's the simplest and cleanest way to follow
2804, but if the section remains then I think the language
needs to be changed (e.g. s/should/could/) and a reference
to 2804 should be inserted.

2) 2.5 is incorrect in talking about "users," what is being
identified is really a B4 isn't it? And there could be many
users/hosts in the customer premises. I think that is
sufficiently important to fix since it has happened that people
have been wrongly blamed for actions simply due to this
confusion of addresses and users.

3) 3.1: Wasn't there some issue with DNSSEC here? (I don't
recall right now) If so, I think that'd warrant a mention. If
not, sorry:-)

[Ballot comment]


- 2.6 is probably also a bit wrong in how it talks about users.
I also wasn't sure what was meant by "an abused user"?

- 2.11 could do with a reference to rfc 6280, since that
represents our BCP for location and location privacy handling.

- 2.13: Just checking, but does PCP base handle this with the
simple security model? I can never recall. There was a recent
thread on the pcp list about that and it might be worth a look
to see if PCP-base is ok here. (The statement in this draft is
true though, PCP-base was designed to handle this, the question
is whether or not the security model in PCP-base does that well
enough.)

- secdir review [1] has a couple of nits

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

[Ballot discuss]

  The Gen-ART Review by David Black on 15-Oct-2012 raised five issues,
  and the authors have agreed to make changes to address them.  The
  revised I-D has not been posted yet.

[Ballot discuss]
(Sorry: re-doing this to move the DISCUSS comments up here, rather
than referring to them down there.)

1. I have some questions where I think that this document is either
giving implementation advice, rather than deployment advice, or
making demands that are out of its scope:

-- Section 2.3 --
  the Tunnel-Entry Point and Tunnel-Exit Point should fragment
  and reassemble the oversized datagram.  If the DF bit is set in the
  IPv4 header, the B4 element should send an ICMP "Destination
  Unreachable" with "Fragmentation Needed and Don't Fragment was Set"
  and drop the packet.  If the DF is unset in the IPv4 header, the B4
  element should fragment the IPv6 packet after the encapsulation.

Fine, but what does that have to do with deployment and operation?
This seems to be telling us how to implement DS-Lite, not how to
deploy it.

-- Section 2.6 --
  Internet hosts
  such as servers must no longer rely solely on IP address to identify
  an abused user.  The server should combine the information stored in
  the transport layer (e.g. source port) and application layer (e.g.
  HTTP) to identify an abused user [RFC6302].

I presume you mean an "abusive" user, not an abused one.  But let me
see if I understand this: you are giving deployment advice to DS-Lite
deployments by trying to tell arbitrary Internet servers what to do --
servers that have no connection to any DS-Lite deployment, and that
perhaps have never heard of DS-Lite and have no idea what it is?

You see where I'm going with this?
The deployment consideration you need to address here is exactly that
these Internet servers will NOT be playing in your sandbox and will
NOT accommodate your configuration in the way you're describing above,
and they WILL block and blacklist your shared IPv4 addresses.  Discuss
that problem and perhaps give the deployments advice about what they
might do to mitigate it.

-- Section 2.11 --
  Another possibility is that the applications could rely
  on location information such as GPS co-ordination to identify the
  user's location.

Again, it's just not in the scope of this document to tell application
developers how to re-code their applications.  And most non-mobile
applications have no GPS capabilities.  Indeed, we're largely talking
about applications provided as web services, so see my comment about
Section 2.6.

-- Section 2.12 --
Same comment as for Section 2.3: this is implementation advice, not
deployment considerations.


2. Section 4, Security Considerations
The security considerations are very fluffy: "The AFTR needs to
protect against such abuse." and "The AFTR needs to ensure equitable
access.", but nothing that talks about HOW.  On the one hand, it's
true that this document doesn't introduce those security issues.  On
the other hand, this document is about deployment and operational
considerations, and those are exactly the sorts of security-related
issues that need to be addressed when we're talking about deployment
and operational considerations.

[Ballot comment]
Given that this is about deployment considerations, I really want to
see the OpsDir review that I'm told is expected early next week.  It's
entirely possible that, as a non-Ops guy, some of my concerns are off.

That said, here we go:

-- Section 2.1 --
  Although an operator can configure
  a dual-stack interface for both functions, we recommend to configure
  two individual interfaces (i.e. one dedicated for IPv4 and one
  dedicated for IPv6) to segregate the functions.

I rather hoped to see some explanation of why this is recommended.
What are the advantages of such segregation?  What is lost or
adversely affected by not having them segregated?

-- Section 2.7 --
Maybe it's just because I'm not a DS-Lite guy, but this section
doesn't seem to be doing much in the way of discussing deployment
considerations.  It seems to be saying that there are a bunch of
configuration options, and listing some of them.  Shouldn't it be
talking about consideratins for using those options?
-- The AFTR can be configured to only accept B4's connections
originating from the IPv6 prefixes configured in the AFTR.
-- The AFTR can be configured to give priority to the packets marked
by certain DSCP values.
-- The AFTR can be configured to limit the rate of port allocation for
a single B4's IPv6 address.

Why might I want to do each of these things, and when are they contraindicated?

-- Section 2.8 --
Question to the OPS ADs: Does this section really say enough to be useful?

-- Section 2.9 --
Are there references for these standby modes?  I expected citations to
show me where to look to see how to do these, and there are none.

-- Section 2.11 --
  To minimize the impact, an operator could deploy AFTR
  closer to users so that existing location based assumptions of the
  clients source IP address by geographically aware servers can be
  maintained.

Is "closer to users" really the best way to describe this?  What
you're really saying is that the operator could deploy AFTRs that each
serve relatively small geographic regions, making the geolocation by
IP address "accurate enough", right?

-- Section 2.13 --
What advice are you giving to deployment and operations here?  What
are you suggesting that I *do*?

[Ballot discuss]
1. I'm going to mark some of my comments, below, as DISCUSS points.
Those are the ones where I think that this document is either
giving implementation advice, rather than deployment advice, or
making demands that are out of its scope.

The DISCUSS points, then, are the comments (see below) to the following:
-- Section 2.3
-- Section 2.6
-- Section 2.11, second comment
-- Section 2.12


2. Section 4, Security Considerations
The security considerations are very fluffy: "The AFTR needs to
protect against such abuse." and "The AFTR needs to ensure equitable
access.", but nothing that talks about HOW.  On the one hand, it's
true that this document doesn't introduce those security issues.  On
the other hand, this document is about deployment and operational
considerations, and those are exactly the sorts of security-related
issues that need to be addressed when we're talking about deployment
and operational considerations.

[Ballot comment]
Given that this is about deployment considerations, I really want to
see the OpsDir review that I'm told is expected early next week.  It's
entirely possible that, as a non-Ops guy, some of my concerns are off.

That said, here we go:

-- Section 2.1 --
  Although an operator can configure
  a dual-stack interface for both functions, we recommend to configure
  two individual interfaces (i.e. one dedicated for IPv4 and one
  dedicated for IPv6) to segregate the functions.

I rather hoped to see some explanation of why this is recommended.
What are the advantages of such segregation?  What is lost or
adversely affected by not having them segregated?

-- Section 2.3 --
  the Tunnel-Entry Point and Tunnel-Exit Point should fragment
  and reassemble the oversized datagram.  If the DF bit is set in the
  IPv4 header, the B4 element should send an ICMP "Destination
  Unreachable" with "Fragmentation Needed and Don't Fragment was Set"
  and drop the packet.  If the DF is unset in the IPv4 header, the B4
  element should fragment the IPv6 packet after the encapsulation.

Fine, but what does that have to do with deployment and operation?
This seems to be telling us how to implement DS-Lite, not how to
deploy it.

-- Section 2.6 --
  Internet hosts
  such as servers must no longer rely solely on IP address to identify
  an abused user.  The server should combine the information stored in
  the transport layer (e.g. source port) and application layer (e.g.
  HTTP) to identify an abused user [RFC6302].

I presume you mean an "abusive" user, not an abused one.  But let me
see if I understand this: you are giving deployment advice to DS-Lite
deployments by trying to tell arbitrary Internet servers what to do --
servers that have no connection to any DS-Lite deployment, and that
perhaps have never heard of DS-Lite and have no idea what it is?

You see where I'm going with this?
The deployment consideration you need to address here is exactly that
these Internet servers will NOT be playing in your sandbox and will
NOT accommodate your configuration in the way you're describing above,
and they WILL block and blacklist your shared IPv4 addresses.  Discuss
that problem and perhaps give the deployments advice about what they
might do to mitigate it.

-- Section 2.7 --
Maybe it's just because I'm not a DS-Lite guy, but this section
doesn't seem to be doing much in the way of discussing deployment
considerations.  It seems to be saying that there are a bunch of
configuration options, and listing some of them.  Shouldn't it be
talking about consideratins for using those options?
-- The AFTR can be configured to only accept B4's connections
originating from the IPv6 prefixes configured in the AFTR.
-- The AFTR can be configured to give priority to the packets marked
by certain DSCP values.
-- The AFTR can be configured to limit the rate of port allocation for
a single B4's IPv6 address.

Why might I want to do each of these things, and when are they contraindicated?

-- Section 2.8 --
Question to the OPS ADs: Does this section really say enough to be useful?

-- Section 2.9 --
Are there references for these standby modes?  I expected citations to
show me where to look to see how to do these, and there are none.

-- Section 2.11 --
  To minimize the impact, an operator could deploy AFTR
  closer to users so that existing location based assumptions of the
  clients source IP address by geographically aware servers can be
  maintained.

Is "closer to users" really the best way to describe this?  What
you're really saying is that the operator could deploy AFTRs that each
serve relatively small geographic regions, making the geolocation by
IP address "accurate enough", right?

  Another possibility is that the applications could rely
  on location information such as GPS co-ordination to identify the
  user's location.

Again, it's just not in the scope of this document to tell application
developers how to re-code their applications.  And most non-mobile
applications have no GPS capabilities.  Indeed, we're largely talking
about applications provided as web services, so see my comment about
Section 2.6.

-- Section 2.12 --
Same comment as for Section 2.3: this is implementation advice, not
deployment considerations.

-- Section 2.13 --
What advice are you giving to deployment and operations here?  What
are you suggesting that I *do*?

IANA has reviewed draft-ietf-softwire-dslite-deployment-06 which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Deployment Considerations for Dual-Stack Lite) to Informational RFC


The IESG has received a request from the Softwires WG (softwire) to
consider the following document:
- 'Deployment Considerations for Dual-Stack Lite'
  as Informational RFC

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-10-16. 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


  This document discusses the deployment issues and describes
  requirements for the deployment and operation of Dual-Stack Lite.
  This document describes the various deployment considerations and
  applicability of the Dual-Stack Lite architecture.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-softwire-dslite-deployment/ballot/


No IPR declarations have been submitted directly on this I-D.

Here is the proto writeup for the draft:
draft-ietf-softwire-dslite-deployment-06.txt


(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?

Intended status: Informational
This document discusses the deployment issues for DS-Lite.

(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

Dual-stack Lite (DS-Lite) [RFC6333] is a transition technique that
enable operators to multiplex public IPv4 addresses while
provisioning only IPv6 to users. This document discusses the
deployment issues and describes requirements for the deployment
and operation of Dual-Stack Lite.


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.
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?

This is deployment discussion rather than a protocol definition,
while DS-Lite has been deployed/tested in some production networks.

Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

Softwire co-chair, Yong Cui, is the Document Shepherd.
Ralph Droms is the Responsible AD.

(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 is well writen and ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(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.

N/A.

(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.

No IPR issue.

(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?

The WG consensus is strong and most of the active participants
strongly agree on the advancement of this document.

(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.

(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 is a nits warning: 2 instances of lines with non-RFC5735-compliant
IPv4 addresses in the document.
In the draft, we reference an address and a prefix (192.0.0.2/32 and
192.0.0.0/29). They are non-RFC5735-compliant IPV4 addresses, but they
are reserved for dslite's use, so we ignore the system warning for them.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(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).

N/A.

(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.

N/A.

(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.

N/A