Subject: Re: reference dependency (DS to PS) (Re: [rfc2462bis] M/O flags and DHCPv6)

From: Suresh Krishnan <[email-masked]>
Date: Tue, 9 Mar 2004 20:10:13 -0500 (EST)

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
   specifications from other standards bodies.  (See Section 7.)

Since PS is lower than DS on the maturity level, a DS spec cannot have a 
normative reference to a PS spec. 

Regards
Suresh

On Tue, 9 Mar 2004, JINMEI Tatuya / [ISO-2022-JP] 神明達哉 wrote:

>>>>>> On Thu, 04 Mar 2004 03:00:08 -0500, 
>>>>>> Ralph Droms <[email-masked]> 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 normative reference to a PS spec."?
>
>I've not seen any responses yet...I guess we could deal with the
>original issue with leaving this open, but it's still very helpful to
>clarify this point to make a realistic decision.
>
>If no one can give a concrete pointer, I'll assume "a DS spec cannot
>have a normative reference to a PS spec" for safety.
>
>					JINMEI, Tatuya
>					Communication Platform Lab.
>					Corporate R&D Center, Toshiba Corp.
>					[email-masked]
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------
>

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 22 Mar 2004 19:07:58 +0900

(Sorry for not responding sooner)

>>>>> On Tue, 9 Mar 2004 20:10:13 -0500 (EST), 
>>>>> Suresh Krishnan <[email-masked]> said:

> normative reference to a PS spec. 

Thanks for the pointer.  My understanding from this and the I-D Pekka
provided (thanks) is:

- PS is at a lower maturity level than DS is (Sections 4.1.1 and 4.1.2
  of RFC2026).
- so, a DS spec must not "depend on" a PS spec (Section 4.2.4 of
  RFC2026)
- draft-ymbk-downref-01 clarifies what the dependency means in terms
  of the reference category.  It says in abstract that:

   IETF procedures generally require that a standards track RFC may not
   have a normative reference to a document at a lower standards level.

  (it seems to me that this draft rather concentrates on exceptions to
  this rule than the original rule itself, but I guess it's enough for
  now)

  The draft use the term "standards level", but it obviously means the
  maturity level.

As a conclusion, it should be wise not to have a normative reference
to a PS document from rfc2462bis, even though there may be exceptions.
This means we should not have a normative reference from rfc2462bis to
RFC3315 (PS) or to node requirements document (will be info).

Through the discussions so far, (my understanding of) the consensus is
that it is okay to use the documents as an informative reference
(which document should be used is a separate question).

					JINMEI, Tatuya