>>>>> On Tue, 27 Apr 2004 09:06:06 -0700,
>>>>> Alain Durand <[EMAIL PROTECTED]> said:
>> I would first like to be sure if it is okay to recycle the document as
>> DS even with the lack of implementation on a part of the protocol
>> description (in this case, the receiving side of the M flag),
>> *process-wise*.
>> If it's not okay, all the discussion we are having is meaningless;
>> Regardless of whether we prefer the idea of deprecating the flag, or
>> whether what Christian said is valid or not, we have no other choice
>> than deprecating/removing the feature (though there may be some
>> compromise on the details of "deprecate").
>> If it's okay, then we can continue the discussion.
> Ok, thanks for the clarification. IMHO, it is not OK to keep
> the document as DS with O&M given the general lack of implementation.
Hmm, this message of yours seems to have been sent just after my
latest one...so, please let me confirm your intention. Can you or
can't you live with my revised proposal (attached below)?
Regarding the process issue, I personally share your view. But I
understood the current practice of the IETF is much more generous than
I'd want to see, and I'd accept that for now.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> On Tue, 27 Apr 2004 06:21:24 -0400,
>>>>> Brian Haberman <[EMAIL PROTECTED]> said:
> As a I stated in an earlier message, I believe it is okay to recycle
> at DS given the granularity of detail in the interoperability reports.
> http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt
> clearly shows that the interoperation is being measured at the message
> level and not at the bit level.
Okay, thanks. Then it is probably okay to keep these flags in terms
of the standardization process, even if we don't have the
corresponding implementations at all. I personally would like to have
a closer review process, but as Pekka said, this is apparently what we
have, and I'm not intending to fight against it (at least for
rfc2462bis).
(wearing an editor's hat) through the discussion so far, it seems to
me that we should keep both the flags. The reasons are:
- there seems to be no process issue (about interoperable
implementations)
- the other points I raised to deprecate the flags were (apparently)
not convincing enough
- we may need some additional consideration for security concerns
Alain raised, but I think we can deal with them without deprecating
the flags:
+ as (implicitly?) described in the node requirements draft, it's
optional to implement DHCPv6 in the first place, and the node req
document warns administrators about the implication about turning
on the M flag. Perhaps the node req draft could also add the
security concerns, and/or rfc2462bis can describe the issues in
its security consideration section.
+ after all, the entire autoconfiguration mechanism using RA
(without SEND) is vulnerable to attacks from a malicious party in
the same link. It might be true that the concerns raised by Alain
increases the vulnerability, but I guess we can accept it by noting
the concerns in the security consideration section.
I hope this is acceptable for everyone.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--- End Message ---
