Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

[Jen Linkova <[e-mail]>]

On Wed, Jul 24, 2019 at 4:39 AM Fernando Gont <[e-mail]> wrote:
> On 23/7/19 12:39, Brian E Carpenter wrote:
> > 1) Yes, we should *obviously* do this.
> > 2) If the charter prevents that, fix the charter.
>
> I'm all for fixing problems and getting stuff done. And, if there's no
> other way than fixing the charter, so be it.
>
> However, it would seem to me that, the "bug" here is that we're
> defaulting to "6man wouldn't get this done, so let's do it elsewhere".

I'm confused. I'm not sure I understand how you came to the conclusion
that we are trying fix the protocol in v6ops because 6man wouldn't do
this.

First of all, main goal of the draft in question is to describe an
operational problem and discuss potential ways to deal with it.
Based on the analysis the draft currently suggests that there  are
"valid reasons in particular circumstances when the particular
behavior (violate SHOULD NOT and create a STALE entry upon receiving
an unsolicited NA) is acceptable or even useful". It does not change
ND as a protocol because RFC4861 does allow such behaviour (otherwise
it would have said 'MUST NOT') so I'm inclined to say that it's not a
protocol change.
However I see why it might be seen as a protocol change and I'm
willing to either:
- write an additional 1-page draft for 6man updating 4861 based on
analysis provided in this draft;
- get this draft adopted and/or reviewed by 6man
- whatever other ways to make sure all appropriate  reviews are done, " full
   implications should be understood and the case carefully weighed" etc ;)


> If a BCP is to go against the protocol spec recommendation for the
> general case, that's an indication that the protocol should be updated.

BCP does not go against the specification for the general case. It
seems to me that the protocol discusses a general case and provides
rationale for 'SHOULD NOT'.
Then we have discovered one corner case which is not even in scope for
the rationale provided in the standard. For me it's a typical example
of 'valid reasons in particular circumstances when the
   particular behavior is acceptable'. If we were recommending that
any arbitrary host SHOULD create an entry upon receiving an
unsolicited NA - then yes, it's a clear indication that RFC4861 needs
to be updated.

Anyway, as I've said, I have no problem go to 6man with it - but I
guess we need to look at all proposed solutions, decide which way we
want to go and, if RFC4861 needs to be updated - well, I guess it
SHOULD be easy ;)



-- 
SY, Jen Linkova aka Furry