Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
RFC 6629

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

(Jari Arkko) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-03-07 for -03)
No email
send info
As a courtesy  to the RFC Editor, the authors should scrub the document for terms not expanded on first use.

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-03-15 for -03)
No email
send info
The first two paragraphs of the Security section reads oddly.

Suggest:
OLD
   This section considers the applicability of the Shim6 protocol from a
   security perspective, i.e. which security features can expect
   applications and users of the Shim6 protocol.

   First of all, it should be noted that the Shim6 protocol is not a
   security protocol, like for instance HIP.
NEW
   This section considers the applicability of the Shim6 protocol from a
   security perspective, i.e. which security features can be expected by
   applications and users of the Shim6 protocol.

   First of all, it should be noted that the Shim6 protocol is not a
   security protocol, unlike for instance HIP.
END

(Stephen Farrell) No Objection

Comment (2012-03-09 for -03)
No email
send info

- I wondered how IPsec was affected by or affects shim6.  Figure 3
didn't really tell me.

- Section 3.3 seems a bit odd - why do you want to control CGA
parameters via DHCP? (That's also the subject of a discuss on
ietf-csi-dhcpv6-cga-ps.) Its also not the case (is it?) that private
key information is ever exchanged like this. Similarly with 3.4.
Could both these sections not actually just be deleted?

(Russ Housley) (was Discuss) No Objection

(Pete Resnick) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2012-03-14 for -03)
No email
send info
I like the edits agreed as a result of Stephen's comments.