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

[Brian Haberman <[e-mail]>]

Hi all,

On 4/6/15 11:07 PM, Spencer Dawkins wrote:
> 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 ...

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

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Extreme nit alert:
> 
>    In general, the delay may be unacceptable in some
>    scenarios.
>    
> would make more sense to me without the "in general".
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
>