Re: I-D Action: draft-ietf-6man-ipv6only-flag-03.txt

[神明達哉 <[e-mail]>]

At Fri, 19 Oct 2018 14:35:34 +0200,
Job Snijders <[e-mail]> wrote:

> I think it would be good to have some running code before advancing this
to
> IESG review and RFC publication. I don’t mean someone being able to send
> the flag in a RA, but an operating system reacting to receiving a RA with
> the flag set.
>
> Operating system implementers will be able to provide valuable feedback to
> the working group on how to mitigate risk for some of the suspected attack
> vectors - and it’ll be educational to see how this works in practice. I
> think running code will improve this specification.

I tend to agree.

If I recall the discussion in this group accurately, I've not yet seen
a host OS implementor interested in implementing this idea, while they
should be one of the primary stake holders who can benefit from this
option.  In fact, some implementors were even explicitly negative
about it.

IMO this is not a good sign, and suggests we might be developing
something useless at best, or harmful at worst.  I've seen the usual
response to that concern: "we IETF can't enforce developers to
implement anything; all we can do is to write a good protocol
specification and let the market decide".  That may be true in the
end, but I'm not comfortable with accepting the argument without even
seeing an attempt of actually implementing and running the proposal.

I guess we can also learn from the "DNS camel" discussion held in the
London meeting in March:
https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01
I'm afraid that mainly "standardizers" (see p.24 of the slides)
drive the discussion toward publication right now, while developers
and (at least some) operators raise concerns.  In my past experiences,
that's often a sign of having troubles in the future, when the latter
group of people will have to deal with them, while the "standardizers"
are now more interested in developing the next cool thing.  Hopefully
I'm wrong this time, but to be proved incorrect I'd like to see more
concrete evidences with running code and experiments, rather than just
having email discussions which are often hypothetical and where anyone
can validly make their arguments.

--
JINMEI, Tatuya