I thought that statement referred to one implementation
only, which is confirmed by Jinmei's response to my email
Hesham
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 27, 2004 12:14 PM
> To: Soliman Hesham
> Cc: IETF IPv6 Mailing List
John - I should have been more careful in my use of "we", which I had
intended to mean the IETF as a whole. I agree that the issue of
"implemented and interoperable" is not within the IPv6 WG's scope. It
wouldn't hurt for the WG to be aware of the potential issues and come to an
explciit decision
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : Management Information Base for the Internet Protocol (IP)
Author(s) : S. Routhier
On Apr 27, 2004, at 2:39 AM, Iljitsch van Beijnum wrote:
Now at present, it doesn't support DHCPv6. But suppose in the next
version of my favorite OS DHCPv6 is supported, and I decide I want to
run it. So far so good. But if I now take my laptop to a place where
there is no DHCPv6 server, I eit
On Apr 27, 2004, at 1:50 AM, Soliman Hesham wrote:
The facts are:
1. there is code that sets the M&O bits. (router implementations)
2. there are at least two implementations that read and
act on the O
bit. These two implementations both invoke stateless DHCPv6 as
the action.
=> So
On Apr 26, 2004, at 11:29 PM, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote: 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
> 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-implementatio
Hi Ralph,
> I also agree that we should be more precise in our acceptance of
> "implemented and interoperable". I fear that the current practice can be
> (and has been) applied selectively to allow advancement of some standards
> while holding back others.
I'm not sure that your point above is s
I agree 100% with Pekka's assessment of the current state of
interoperability testing, reporting and requirements as applied to
advancement of protocol standards.
I also agree that we should be more precise in our acceptance of
"implemented and interoperable". I fear that the current practice can
On Tue, 27 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote:
> In any event, I'd first like to clarify the general point before going
> to each detail to avoid further confusion. The question is:
>
> We do not have an implementation on some part of RFC2462. Can we
> st
I fully agree with the chair's decision to leave the M/O bits unchanged
for now.
I would like to quickly address (comments inline) the security argument
that was raised by Alain.
Alain,
> It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
> an automatic and insecure way to
Just checking, what is the current status of
draft-ietf-ipv6-scoping-arch-01.txt? According to the status tracker
page, it's still in the "Ready for WG Last Call" state, and I don't
think I've seen the 1-week last call you mentioned.
Thanks,
JINMEI, Tatuya
JINMEI wrote:
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.
Not
Alain Durand wrote:
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.
No one is claiming inte
> > => So based on 1) and 2) I suggest that people who want to continue
> > this discussion, despite the chairs' recommendation should
> limit the
> > discussion to the M flag. If there are implementations that support
> > the O flag then removing it should be out of the ques
On 26-apr-04, at 22:53, Alain Durand wrote:
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 to the security level of DHCPv6 rather than that of the
M and O bits?
You should rea
> On Tue, 27 Apr 2004 04:50:00 -0400,
> "Soliman Hesham" <[EMAIL PROTECTED]> said:
>> 1. there is code that sets the M&O bits. (router implementations)
>> 2. there are at least two implementations that read and
>> act on the O
>> bit. These two implementations both invoke stateless DHCP
On Mon, Apr 26, 2004 at 10:14:02AM -0700, Alain Durand wrote:
> Let me try to explain why I, as an implementor, do not like the M/O
> bits very much.
> ...
Alain,
Could you explain how the functionality of the O/M bits will be replaced
within the ND/etc protocols? Or should they not be replaced
> The facts are:
>
> 1. there is code that sets the M&O bits. (router implementations)
> 2. there are at least two implementations that read and
> act on the O
> bit. These two implementations both invoke stateless DHCPv6 as
> the action.
=> So b
Someone just pointed out that the text:
5.1.1 TCP and UDP over IPv6 Jumbograms - RFC2147
This specification MUST be supported if jumbograms are implemented [RFC-2675].
should be removed as 2147 is absoleted by 2675. I shall remove the text.
Otherwise, I'm still wait
20 matches
Mail list logo
