> On Mon, 26 Apr 2004 22:28:05 -0700,
> Alain Durand <[EMAIL PROTECTED]> said:
> My biggest question is: can we recycle rfc2462bis as DS despite fact
> 3?
> I failed to see what is wrong with the unused feature elimination
> Christian described
> when moving along the standard track.
No
On Apr 26, 2004, at 10:02 PM, S. Daniel Park wrote:
To give a hint that DHCPv6 is present?
Don't you consider this useful?
I have no hard stance whether to remove M&O bits
or not at this stage, however if we remove it, I
guess somebody will sporadically define similar
flags into the RA repeatly so
(B (BOn Apr 26, 2004, at 10:09 PM, JINMEI Tatuya / (B[EMAIL PROTECTED]@C#:H(B (Bwrote: (B (B (BMy biggest question is: can we recycle rfc2462bis as DS (Bdespite fact (B (B3? (B (B (B (BI failed to see what is wrong with the unused feature elimination (BChristian described (B (Bwh
> On Mon, 26 Apr 2004 17:28:02 -0700,
> Alain Durand <[EMAIL PROTECTED]> said:
>> At this time, the chairs believe that there is code that
>> sets the M&O bits and at least one implementation that reads and acts
>> on these bits.
> This is certainly not enough to claim interoperability.
> >> To give a hint that DHCPv6 is present?
> >
> > Don't you consider this useful?
I have no hard stance whether to remove M&O bits
or not at this stage, however if we remove it, I
guess somebody will sporadically define similar
flags into the RA repeatly so as to perform that
kind of operatio
Alain
(B
(BYour point about security is valid but is relevant to securing RAs
(Bin general, and is not specific to the M/O bits. If you want to be sure
(Bthey're
(Bsecure just use SEND.
(B
(BHesham
(B
(B
(B > -Original Message-
(B > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTEC
On Apr 26, 2004, at 2:50 PM, Brian Haberman wrote:
At this time, the chairs believe that there is code that
sets the M&O bits and at least one implementation that reads and acts
on these bits.
This is certainly not enough to claim interoperability.
- Alain.
JINMEI wrote:
On Sat, 24 Apr 2004 22:08:28 -0700,
"Christian Huitema" <[EMAIL PROTECTED]> said:
Some people commented that we needed to clarify what's bad with the
M/O flags if we want to deprecate (or remove) them.
(folding a long line)
The normal IETF practice is that when a document pr
On Apr 26, 2004, at 1:10 PM, Iljitsch van Beijnum wrote:
On 26-apr-04, at 19:14, Alain Durand wrote:
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
It is not that DHCPv6 cannot be made secure, it is that the M/O bits
are
an automatic and insecure way to tri
On 26-apr-04, at 19:14, Alain Durand wrote:
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
It is not that DHCPv6 cannot be made secure, it is that the M/O bits
are
an automatic and insecure way to trigger an external configuration
mechanism.
So you object t
Let me try to explain why I, as an implementor, do not like the M/O
bits very much.
It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
an automatic and insecure way to trigger an external configuration
mechanism.
The are security implication for the hosts in implementing t
> Baseline is, it would be good to postpone the deprecation discussion and
(B> at the same time update the definition of the use of the M/O bits. I can
(B> think of scenarios where M/O is useful but the mental picture of these
(B> is not clear enough yet to really make a point. Deciding upon
(
> (Note: In this message, I'm basically speaking just as an individual
> in this list. I'll propose an action as a 2462bis editor after the
> entire discussion; it may or may not be same as what I'm going to say
> below)
I think your approach to look at the two sides of the medal is very
useful, b
13 matches
Mail list logo
