Subject: Spencer Dawkins' Discuss on draft-ietf-6man-resilient-rs-05: (with DISCUSS and COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 06 Apr 2015 20:07:24 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-6man-resilient-rs-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Extreme nit alert:

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 07 Apr 2015 09:30:47 -0400

Hi all,

> http://datatracker.ietf.org/doc/draft-ietf-6man-resilient-rs/

I went back and re-read Barry's Comment and the resulting response and
felt unsatisfied.

Barry & Spencer, let me know if I am misinterpreting your concerns...

It appears odd to give such concrete guidance as "enable/disable
retransmissions on a per-interface basis" for a function that is
completely optional.  After some thought, I am trying to figure out why
it would be optional since typical NA/NS/RA/RS functionality is
per-interface anyway.

Given what is being described, I would think we would want to encourage
implementers to provide a configuration option rather than make it
optional.  The text could be re-written (without 2119 keywords) as such:

NEW:
Implementations of this specification are encouraged to provide a
configuration option to enable or disable potentially infinite RS
retransmissions. Providing an option to enable/disable retransmissions
on a per-interface basis allows network operators to configure RS
behavior most applicable to each connected link.

Regards,
Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 7 Apr 2015 10:06:28 -0500

Hi, Brian,

> behavior most applicable to each connected link.

So, without 2119 keywords, I'd prefer "strongly encouraged", but
"encouraged" is an improvement.

My other point was - if there's a  configuration option for this, I would
prefer that the group make a recommendation about default settings.

I'd prefer "off by default", but could be convinced that "on by default"
has benefits that outweigh the costs.

Without a recommendation, I'm visualizing a network where the option isn't
set, some devices default "on" and others default "off", and hilarity
ensues.

Again, I could be convinced that's not a problem, but wanted to ask.

I'll clear when we figure out what I'm clearing in favor of, but I'll clear
for "encouraged" or anything stronger in the text you proposed.

Thanks!

Spencer

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Apr 2015 00:15:43 -0400

Hi Brian,

> behavior most applicable to each connected link.

This text looks good. If this will help clarify things, I will make the 
change.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 8 Apr 2015 04:33:21 +0000

Hi Spencer,
   Thanks for your comments. Please find responses inline.

On 04/07/2015 11:07 AM, Spencer Dawkins at IETF wrote:
> Hi, Brian,
>
> On Tue, Apr 7, 2015 at 8:30 AM, Brian Haberman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>      > Please refer to
>     http://www.ietf.org/iesg/statement/discuss-criteria.html
> My other point was - if there's a  configuration option for this, I
> would prefer that the group make a recommendation about default settings.

Sounds good.

> has benefits that outweigh the costs.

I am not exactly sure what you mean by "off by default" but the goal is 
to enable persistent RS sending by default for increasing the robustness 
for ND. If you mean that the option to disable should be "off by 
default", I fully agree and can make the change right away.

Thanks
Suresh

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Apr 2015 02:43:01 -0500

Hi, Suresh,
On Apr 7, 2015 23:33, "Suresh Krishnan" <[email-masked]>
> I am not exactly sure what you mean by "off by default"

I'm sorry, that really wasn't clear ("unambiguous technical text is hard"
:-)

> but the goal is

Transport guys would be genetically predisposed to prefer
disabled-by-default in the absence of any other information, but I asked,
and you're saying enabled-by-default really is the goal, so, that's fine
("we had the Discussion").

I'm more comfortable with a consistent enabled-by-default than a default
that might differ unexpectedly among the devices in a single network, so if
you're ok with enabled-by-default, I'd appreciate you making the change.

Thanks,

Spencer