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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Suresh,
On Apr 7, 2015 23:33, "Suresh Krishnan" <[e-mail]>
wrote:
>
> 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 <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     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.
> >
> >
> > 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.
>
> Sounds good.
>
> >
> > I'd prefer "off by default", but could be convinced that "on by default"
> > has benefits that outweigh the costs.
>
> 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
> 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.

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