Re: Murray Kucherawy's No Objection on draft-ietf-6man-grand-06: (with COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Jul 1, 2021 at 12:14 AM Jen Linkova <[e-mail]> wrote:

> Hi Murray,
>
> On Thu, Jul 1, 2021 at 3:21 PM Murray Kucherawy via Datatracker
> <[e-mail]> wrote:
> > I don't see a lot of transport documents that make me think this, but:
> Kudos
> > for an easy read.
>
> One of the reasons might be that it's not really a transport document..;))
> Thank you, I'm glad you find this document easy to read.
>

Oh yeah, you're right!  Somehow I saw "6man" and thought about TCP for some
reason.  It's late and I'm tired.  Well still, I think it's well done.

> To a transport expert the answer to this may be obvious, but I'm left
> wondering
> > why these are only SHOULD [NOT]s.  Is there a ever a good reason to
> deviate
> > from those instructions?  I generally find it helps to, when using SHOULD
> > [NOT], include a sentence or two about why it might be necessary to do
> > something else, to guide novice readers.  It's not strictly necessary,
> but
> > something to consider here.
>
> Well...AFAIR we discussed it during one of the meetings - should some
> of SHOULD be MUST?
> It's always such a grey area. In this case it's not like there are
> good reasons or scenarios to deviate from SHOULD. It's more about
> "MUST is a very strong requirement". IMHO "MUST" means "if we don't do
> this, smth bad will happen, smth will get broken". It's definitely not
> the case here.
> What this document proposes is an optimization, a mechanism to make
> IPv6 a bit more reliable.
> So I agree that it would be nice to always enumerate scenarios when
> it's OK to deviate from SHOULD but I do not think it's possible.  [...]
>

Yeah, I understand.  And I think we've had this conversation before too.

My problem with SHOULD when used this way is that it does make it clear you
could do something else and still interoperate successfully, but the
implementer is left without any particular guidance about when it might
actually be appropriate or justified to do something other than what the
SHOULD says.  If you can think of a valid reason, it's often a good idea to
include it as such guidance, even if just as an example.  If there is no
such good reason really, then it's worth considering whether it really
ought to be a MUST.  That's why I bring it up when I see this pattern.

Sometimes the answer is simply backward compatibility with older
implementations, for example.

To sum up, I'm just not sure if we can put any meaningful text there
> to address your comment ;(
>

Fair enough, thanks for the discussion.  I'm glad this got due
consideration already.

-MSK