RE: Node requirements: draft-ietf-6man-node-req-bis-03.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Node requirements: draft-ietf-6man-node-req-bis-03.txt



I would support Applicability Statement status as that would give us more room to make some recommendations on specifications outside of the core set of IPv6 standards.  If you look at what Tim is asking for MLDv2, others are asking for SeND/CGA, etc. - I think it makes a lot of sense ot have a document that can give more guidence than just informational. 

-----Original Message-----
From: ipv6-bounces at ietf.org [mailto:ipv6-bounces at ietf.org] On Behalf Of ext Brian E Carpenter
Sent: Monday, July 20, 2009 9:29 PM
To: Thomas Narten
Cc: ipv6 at ietf.org
Subject: Re: Node requirements: draft-ietf-6man-node-req-bis-03.txt


>  - proper status of this document (info vs. BCP) and whether this
>    document can update any existing RFC

There's a standards-track beast defined in section 3.2 of RFC2026 as an "Applicability Statement":

"  An Applicability Statement specifies how, and under what
   circumstances, one or more TSs [technical specifications] may be applied to support a particular
   Internet capability.
   ...
   An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective..."

I think we can choose, if we want, to make the present document an "Applicability Statement" Proposed Standard or BCP that describes the functionality of a full-spec IPv6 node, and therefore elevates MAY to SHOULD or MUST if we want to.

Personally, I think that's a good idea, rather than issuing an informational document that leaves wiggle room on basics such as ND.

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.