Packet-Loss Resiliency for Router Solicitations
draft-ietf-6man-resilient-rs-06

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

(Spencer Dawkins) (was Discuss) Yes

Comment (2015-04-09 for -05)
No email
send info
Thank you for working through my discuss (and Alia's comment), which was 

---

I'm piling on Barry's Comment as a Discuss, which should be easy to discuss, but ... in this text:

3.  Configuring the use of retransmissions

   Implementations of this specification MAY provide a configuration
   option to enable or disable the use of such potentially infinite
   retransmissions.  If the implementation provides such a configuration
   option, it MUST be able to enable/disable retransmissions on a per-
   interface basis.
   
You can tell me that it's a LAN, so the transport ADs can go back to sleep, but I was surprised that this configuration option was a MAY. 

I was also surprised that there was no guidance about the default setting (on or off), but let's start with the MAY.

IP does get tunneled to new and exciting places ... and infinite retransmissions are infinite ...

---

Extreme nit alert:

   In general, the delay may be unacceptable in some
   scenarios.
   
would make more sense to me without the "in general".

(Brian Haberman) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Comment (2015-04-07 for -05)
No email
send info
To continue a bit on Spencer's Discuss and Barry's Comment, I'd prefer to see a default for the configuration.  I'd assume it would be "off" to continue to provide current behavior, but I don't really care.   Consistency is my concern.

Deborah Brungard No Objection

Comment (2015-04-08 for -05)
No email
send info
Similar to Barry's comment, I would expect some operators' would prefer a system-wide default also be supported vs. per interface granularity.

(Ben Campbell) No Objection

(Stephen Farrell) No Objection

Comment (2015-04-08 for -05)
No email
send info
security considerations: I note that RFC 4861 has been
updated, including by RFC 5942, which specifically says it
addresses a security concern in 4861. (I didn't check the
others.) I think it'd be better to say here "beyond those
discussed in [RFC4861] and RFCs that update that" or some
such. Or point to all the relevant ones, or tell me that it
doesn't matter for this:-)

(Joel Jaeggli) No Objection

Comment (2015-04-08 for -05)
No email
send info
I can live with it.

It doesn't really dwell on costs to devices from the potential for devices on very large but unrouted adhoc networks to spend resources soliciting routers essentially forever.

Barry Leiba No Objection

Comment (2015-03-13 for -05)
No email
send info
-- Section 1 --

   In certain scenarios, these router solicitations
   transmitted by the host might be lost. e.g. The host is connected to
   a bridged residential gateway over Ethernet or WiFi.  LAN
   connectivity is achieved at interface initialization, but the
   upstream WAN connectivity is not active yet.

Purely minor editorial: I got a little tangled in that, and suggest tying it together better this way:

NEW
   In certain scenarios, these router solicitations
   transmitted by the host might be lost. For example, if the
   host is connected to a bridged residential gateway over
   Ethernet or WiFi, LAN connectivity is achieved at interface
   initialization but the upstream WAN connectivity is not
   yet active.
END

-- Section 3 --

   Implementations of this specification MAY provide a configuration
   option to enable or disable the use of such potentially infinite
   retransmissions.  If the implementation provides such a configuration
   option, it MUST be able to enable/disable retransmissions on a per-
   interface basis.

I find this a slightly odd usage of MAY and MUST: you're making the configuration option entirely optional, but then you're saying that if I have that configuration option, it MUST work a certain way.  Is it really better not to be able to disable the infinite retransmissions at all, than to make it all or nothing?  What is harmed by having a configuration option that affects all interfaces at the same time... that is worse than not having that configuration option at all?

In the end, do as you think best; I just wanted to bring up the comment.

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection

Comment (2015-04-09 for -05)
No email
send info
In support of Spencer's discuss.