Deployment Considerations for Dual-Stack Lite
RFC 6908

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

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.

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

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.

I support Barry's discuss points.

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.

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

I support Barry's and Stephen's discusses.

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

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.