As a general comment, IMHO we're wasting cycles on this
discussion and I agree with Iljitsch's email on this.
Specific comments below
> Some people commented that we needed to clarify what's bad with the
> M/O flags if we want to deprecate (or remove) them. That's a fair
> comment. My points are as follows (some of which have already been
> shown in the thread):
>
> - the lack of interoperable implementation (or the fact that
> there are
> very few implementations) regarding the flags, at the host side
> particularly, will probably be a barrier to recycle the document as
> a DS. From my honest impression on Section 4.1.2 of RFC2026, even
> 2462 should have not become a DS document. I've still not
> heard why
> they could make it at that time, so I know I may be wrong.
=> FWIW this is a valid point but not against the M/O flags. This is
a point of discussion about the process. It _is_ a DS now. We can
discuss whether that's a mistake if we want to make it a PS.
I'm not sure what this achieves though.
>
> - each flag can only convey information of a single-bit, causing
> several problems:
> + we'd need to specify a single protocol corresponding to each flag
> in order to avoid combination mess and interoperability problems.
> For the M flag, it's probably okay, because we seem to
> have agreed
> on the protocol is DHCPv6 (RFC3315). For the O flag,
> however, I'm
> not sure if the situation is mature enough. Stateless DHCPv6
> (RFC3736) is likely to be a candidate (and I'd personally take
> it), but can we really agree on it? Aren't there other
> possibilities? For example, the full DHCPv6 protocol (RFC3315)
> can also work as the protocol for the O flag. Others may want to
> propose non DHCPv6 protocols like SLP...then, are we really sure
> we won't want to introduce flexibility by a separate mechanism
> allowing a particular protocol?
=> Sure there are other possibilites, but there is also plenty of
space for new options. So if there is a need for more space to
indicate which protocols should be used and at some point in future
there are no more flags, then a new option will do.
>
> + there is no way to turn off the use of "stateful" protocols.
> (Note that changing the flag from set to clear does not mean
> turning off the protocol)
=> How does this argue for removing the flags though? What would be
the new way of turning off "stateful" that cannot be done today with
the flags?
>
> + if we adopt stateless DHCPv6 as the protocol for the O
> flag, we'll
> need a separate trick to handle renumbering events, e.g., as
> proposed in draft-vijay-ipv6-icmp-refresh-otherconf-00.txt. Of
> course, we'd probably be able to separate this as a future
> extension, but then why can't we reconsider the purpose of the O
> flag from the beginning? (If you're going to say "because it
> will break existing work", please see below first).
=> I don't understand how this is a "+". But anyway, it's not a big issue.
> The obvious one is that this action may break existing
> implementations. In fact, this is the most typical objection I've
> seen in this thread.
>
> To discuss this point precisely, I'd fist like to talk about the host
> side. That is, implementations that
>
> A. invoke some "stateful" protocol on the reception of an
> RA with the
> M flag being set
> B. invoke some "stateful" protocol on the reception of an
> RA with the
> O flag being set
>
> As far as I know, there is no type-A implementation. And,
> as far as I
> know, there are only two type-B implementations: Cisco's host
> implementation, and the one implemented by KAME (that I
> myself wrote):
> both of them (can) invoke an RFC3736 client in this case.
>
> I don't know how Cisco would feel if the O flag were deprecated.
> Perhaps Ralph can comment on it. If they strongly want to keep this
> flag, of course it will be a strong reason to do so.
>
> Regarding KAME's implementation, at least the implementor (myself) is
> okay to deprecate the flags. Also, it's just an experimental
> implementation to identify issues, so this feature (invoking an
> RFC3736 client) is disabled by default in the implementation and is
> not officially released in the BSD community. In fact, I'm
> tempted to
> deprecate the flags based on my experiments with the implementation,
> identifying the issues described above.
>
> Of course, as someone said in the thread, this does not mean
> there are
> no implementors who have an implementation that would be broken by
> deprecating the flags and thus would complain about it. However, I'd
> respectfully say this argument is unfair, considering the scale of
> this mailing list and the number of participants in this particular
> thread. Actually, (at least) 7 people from different organizations
> have commented, and none of them could show concrete examples except
> the above two. In general, it is hard to prove the non-existence of
> something, and I think it's almost impossible in this kind of topic
> (you could always say "someone in an isolated island only with
> computers and RFCs might have implemented this feature" - no one can
> refute this argument).
=> A final comment on the above text and the whole issue:
First of all, since the point of "existing implementations" has been raised
several times, I think the onus is on people who want to remove this
feature to do a survey of all existing implementations and prove that
nothing will be affected. Of course it's very hard to do that but how else
do we make sure that we're not stuffing people around ? Is it enough
to note that Cisco and KAME are happy to remove it? I don't think so.
There are many other router, host, and embedded systems vendors
that have their own implementations and I haven't heard anything
from them about this.
Second, given the above discussion, what is the bottom line, concrete
reason for doing this? It seems to me like "it's cleaner" or "it's better
this way". I can think of many more significant improvements to both
RFCs, for example due to MIPv6 that the WG didn't want to solve because
it was "too much" or "out of scope for this update". Given that, if we try
to use the same standards, then these changes are not needed and are
definitely out of scope for this update.
Hesham
========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review or distribution by others is
strictly prohibited. If you are not the intended recipient please contact
the sender and delete all copies.
========================================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
