(Sorry for not responding sooner)
> On Tue, 9 Mar 2004 20:10:13 -0500 (EST),
> Suresh Krishnan <[EMAIL PROTECTED]> said:
> Don't if it is concrete or not but Section 4.2.4 of RFC2026 states
>Note: Standards track specifications normally must not depend on
>other standards
Hi Jinmei,
Don't if it is concrete or not but Section 4.2.4 of RFC2026 states
Note: Standards track specifications normally must not depend on
other standards track specifications which are at a lower maturity
level or on non standards track specifications other than referenced
On Tue, 9 Mar 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H(B wrote:
> > Jinmei - I mistyped and you guessed what I had intended to ask. Good catch
> > and thanks for the clarification.
>
> > Can anyone supply a direct reference to an explicit statement that "a DS
> > spec cannot ha
> On Thu, 04 Mar 2004 03:00:08 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Jinmei - I mistyped and you guessed what I had intended to ask. Good catch
> and thanks for the clarification.
> Can anyone supply a direct reference to an explicit statement that "a DS
> spec cannot have a
Jinmei - I mistyped and you guessed what I had intended to ask. Good catch
and thanks for the clarification.
Can anyone supply a direct reference to an explicit statement that "a DS
spec cannot have a normative reference to a PS spec."?
- Ralph
At 04:52 PM 3/4/2004 +0900, JINMEI Tatuya /
=?ISO-2
John - I agree that "the goal of 2462(-bis) is STATELESS ADDRESS
AUTOCONFIG." However, the bits controlling use of stateless/stateful are
also defined in RFC 2462bis, so RFC 2462bis goes a little beyond just
defining how stateless address autoconfig. Invoking the camel's nose
principle, and striv
Hi Ralph,
> John - I agree that "the goal of 2462(-bis) is STATELESS ADDRESS
> AUTOCONFIG." However, the bits controlling use of stateless/stateful are
> also defined in RFC 2462bis, so RFC 2462bis goes a little beyond just
> defining how stateless address autoconfig. Invoking the camel's nose
>
> On Thu, 04 Mar 2004 02:33:23 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
>> In the wg meeting on Tuesday, several concerns were raised regarding
>> this issue (and the proposed resolution). To summarize (some of)
>> them,
>>
>> 1. the resolution proposes to say "the stateful protoc
At 02:19 AM 3/4/2004 +0900, JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
In the wg meeting on Tuesday, several concerns were raised regarding
this issue (and the proposed resolution). To summarize (some of)
them,
1. the resolution proposes to say "the stateful protocol is DHCPv6"
Jinmei,
(B
(B> So far, all the responses in this thread seem to support having
(B> RFC3315 (DHCPv6) in rfc2462bis as an informative reference, and not
(B> referring to the node-req draft. Is my understanding correct?
(B
(BYes, I think so.
(B
(B> I can live with this approach. But I also
> On Thu, 4 Mar 2004 06:39:46 +0200,
> [EMAIL PROTECTED] said:
>> Personally, I don't think there's any need to refer to the
>> node-req doc.
> I agree. But I think we can even include a ref to DHCPv6
> as informative. I don't see how there can be a normative
> reference to Stateful A
Hi all,
> Personally, I don't think there's any need to refer to the
> node-req doc.
I agree. But I think we can even include a ref to DHCPv6
as informative. I don't see how there can be a normative
reference to Stateful Add Autoconf. if we are defining
Stateless Add Autoconf.
John
LR¿¬(®
Pekka,
I suspect we are playing games with language, but ...
> > The easiest solution to them would be to list RFC3315 as an
> > informative reference. I don't know whether this is acceptable.
> > According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt,
> > Normative references specify
>
> -Original Message-
> From: JINMEI Tatuya / çæéå [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 04, 2004 11:24 AM
> To: Dave Thaler
> Cc: [EMAIL PROTECTED]
> Subject: Re: [rfc2462bis] M/O flags and DHCPv6
>
> >>>>> On Wed, 3 Mar 2004 17:47:
> On Wed, 3 Mar 2004 17:47:17 -0800,
> "Dave Thaler" <[EMAIL PROTECTED]> said:
>> But the first condition seems to me a bit subjective. Under which
>> requirement can we decide a document must be read for a different
>> document?
>>
>> The second condition is a bit clearer, but assuming
On Thu, 4 Mar 2004, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H(B wrote:
[...]
> The easiest solution to them would be to list RFC3315 as an
> informative reference. I don't know whether this is acceptable.
> According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt,
> Normative ref
JINMEI Tatuya writes:
[...]
> The easiest solution to them would be to list RFC3315 as an
> informative reference. I don't know whether this is acceptable.
> According to Section 2.7 of draft-rfc-editor-rfc2223bis-07.txt,
> Normative references specify
>
> - documents that must be read to unde
17 matches
Mail list logo