Skip to main content

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

Yes

(Brian Haberman)

No Objection

(Alvaro Retana)
(Ben Campbell)
(Jari Arkko)
(Kathleen Moriarty)
(Terry Manderson)

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

Brian Haberman Former IESG member
Yes
Yes (for -05) Unknown

                            
Spencer Dawkins Former IESG member
(was Discuss) Yes
Yes (2015-04-09 for -05) Unknown
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".
Alia Atlas Former IESG member
No Objection
No Objection (2015-04-07 for -05) Unknown
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.
Alvaro Retana Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-03-13 for -05) Unknown
-- 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.
Ben Campbell Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (2015-04-08 for -05) Unknown
Similar to Barry's comment, I would expect some operators' would prefer a system-wide default also be supported vs. per interface granularity.
Jari Arkko Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-04-08 for -05) Unknown
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.
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (2015-04-09 for -05) Unknown
In support of Spencer's discuss.
Stephen Farrell Former IESG member
No Objection
No Objection (2015-04-08 for -05) Unknown
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:-)
Terry Manderson Former IESG member
No Objection
No Objection (for -05) Unknown