Attribute-Value Pairs for Provisioning Customer Equipment Supporting IPv4-Over-IPv6 Transitional Solutions
RFC 7678

Note: This ballot was opened for revision 04 and is now closed.

(Stephen Farrell) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-08-05 for -04)
No email
send info
Thanks for an easy-to-read document. I have a few questions and comments, that I hope can be resolve easily:

-- 3.2:
Is it possible (or reasonable) for the FQDN to include an internationalized domain name? That is, is there a need for a idn or precis dependency? (I'm not saying there _is_ such a need; I'm just asking.)

-- 6.1, 2nd paragraph:

So you mean MiTM attacks _on_ peers, or _by_ peers? I assume the second, since the first can be mitigated with TLS. (I’m not sure I would call this a MiTM per se, it’s just an issue that compromised or malicious nodes already in the path may do bad things.)

-- 6.2:
Thanks for including this--but I think it needs a bit more.  I assume from these sections that some of these AVPs are "security-sensitive" as defined in the referenced section of RFC 6733. That section invokes requirements to use mutually authenticated TLS or IPSec, and to be sure that messages do not traverse any nodes that are not explicitly trusted. It would be good to explicitly list which AVPs from this draft qualify as such (unless the answer is "all of them"), and to explicitly mention that the additional requirements apply to their use.

(Benoît Claise) No Objection

Comment (2015-08-05 for -04)
No email
send info
As reported by Tim Chown in his OPS DIR review:
Overall, I believe the document is Ready. Despite its nature (as a list
of definitions) it generally reads very well.

There are some minor typos, and items to be checked, as listed below,
some of which would no doubt be picked up by the RFC Editor:

1. Section 2.1 line 4, should be “provisions” (plural).

2. Section 2.5, line 5 of second bullet point, “IPv4” not “Pv4”.

3. Section 3.3.2. I found the third paragraph a little clumsy to read;
   perhaps clarify the SSM prefix of ff3x::/32 in effect being a /96?. 
   Also, do you mean bits 33-95 here, or bits 32-95 (twice)?

4. Section 3.5, Figure 5. Should the vertical lines be below 8 and 16,
   rather than below 7 and 15?

5. Section 6 reads a little strangely, in that it says in 6.1 “hey, you can
   mitm Diameter”, then 6.2 says “you MUST use TLS/IPsec avoiding
   intermediate nodes”. Seems a little conflicting in outlook?

6. Two transition drafts cited in the text are now published as RFC 7596 
   and RFC 7597.

(Spencer Dawkins) No Objection

Comment (2015-08-04 for -04)
No email
send info
A nit - this text

   [RFC6519] sets a precedent for representation of the IPv6 address of
   a border router as an FQDN.  This can be dereferenced to one or more
   IP addresses by the provisioning system before being passed to the
   customer equipment, or left as an FQDN as it as in [RFC6334].
seems garbled.

In this text

3.4.1.  Delegated-IPv6-Prefix As the IPv6 Binding Prefix

   The Delegated-IPv6-Prefix AVP (AVP code 123) is of type Octetstring,
   and is defined in [RFC4818].  Within the Tunnel-Source-Pref-Or-Addr
   AVP, it conveys the IPv6 Binding Prefix assigned to the CE.  Valid
   values in the Prefix-Length field are from 0 to 128 (full address),
   although a more restricted range is obviously more reasonable.
I wonder if "obviously more reasonable" is the right thing to say. Is this saying something like "more scalable" (compared to bunches of 128-bit IP binding prefixes)? Or am I misunderstanding the point?

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-08-04 for -04)
No email
send info
Thanks for the extra mention of risks without end-to-end encryption int he security considerations section.  It is good to see this included as a consideration, would be even better if solved and deployed.  :-)

Alvaro Retana No Objection