Subject: Node requirements: Issue 12 - status/scope of document

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Jul 2009 17:36:27 -0400

The WG needs to decide what the scope and purpose this document should
be.

Overall, my sense is that the purpose of this document should be to
provide guidance to implementors (and others, e.g., those creating
IPv6 protocols for specific environments) on what IPv6 functionality
they should implement in their products. That is, to provide a proper
IPv6 stack, what needs to be provided.

Even within that, once could take narrow view and require just the
minimal basics needed to get useful IPv6 communication. Alternatively,
one could try and mandate more advanced features that might not be
critical for basic communications over IPv6, but would be "nice to
have". Or we could do something in between.

My personal opinion is that this document should only mandate core
functionality, features that we really want all nodes to implement in
order to provide reasonable IPv6 service to upper layer
applications. For less critical or extended functionality, the
document should apply guidance and advice as to the scenarios or
conditions where the feature has value, but leave the choice to the
implementor (i.e., a MAY or SHOULD). I believe that is also consistent
with what is currently in the document (though more context/guidance
would be appropriate in some cases).

Looking at RFC 2026 (thanks Brian), it does say:

   3.2  Applicability Statement (AS)

   An Applicability Statement specifies how, and under what
   circumstances, one or more TSs may be applied to support a particular
   Internet capability.  An AS may specify uses for TSs that are not
   Internet Standards, as discussed in Section 7.

   An AS identifies the relevant TSs and the specific way in which they
   are to be combined, and may also specify particular values or ranges
   of TS parameters or subfunctions of a TS protocol that must be
   implemented.  An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective (see section
   3.3).

   ...

I believe that in essence, we want to provide an applicability
statement for the various pieces of IPv6. That means we can make a
statement about an RFC as whole (i.e, the entire RFC), or even say
something about specific subfunctionality within an RFC.

What we wouldn't do is have this document try and update or clarify
ambiguities in the existing specifications.  E.g., the M&O bits
discussion, etc. For one thing, if try to do that, we will likely
never get done. Second, the right way to fix problems with specs is to
either reissue them, or just publish a short document that just
corrects/updates the one issue.

If we take the approach of being an AS, I think we can side step the
question of inforomational vs. BCP for now. Whatever route we end up
going, the content of the docuent would be the same.

Thoughts? Does this make sense?

Thomas

---

From: Hongyu Li <[email-masked]>
Date: Thu, 23 Jul 2009 16:59:04 +0800

Hi Thomas,

I think AS is a good idea to tell people what are prerequisites to make IPv6 works. There are already a lot of controversy in other
places, e.g. BBF, on what are the subsets we must have in an IPv6 network. An AS document in IETF is very useful reference for the
industry.

Hongyu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Narten
> Sent: Wednesday, July 22, 2009 5:36 AM
> To: [email-masked]
> Subject: Node requirements: Issue 12 - status/scope of document
> 
> The WG needs to decide what the scope and purpose this 
> document should be.
> 
> Overall, my sense is that the purpose of this document should 
> be to provide guidance to implementors (and others, e.g., 
> those creating
> IPv6 protocols for specific environments) on what IPv6 
> functionality they should implement in their products. That 
> is, to provide a proper
> Even within that, once could take narrow view and require 
> just the minimal basics needed to get useful IPv6 
> communication. Alternatively, one could try and mandate more 
> advanced features that might not be critical for basic 
> communications over IPv6, but would be "nice to have". Or we 
> could do something in between.
> 
> My personal opinion is that this document should only mandate 
> core functionality, features that we really want all nodes to 
> implement in order to provide reasonable IPv6 service to 
> upper layer applications. For less critical or extended 
> functionality, the document should apply guidance and advice 
> as to the scenarios or conditions where the feature has 
> value, but leave the choice to the implementor (i.e., a MAY 
> or SHOULD). I believe that is also consistent with what is 
> currently in the document (though more context/guidance would 
> be appropriate in some cases).
> 
> I believe that in essence, we want to provide an 
> applicability statement for the various pieces of IPv6. That 
> means we can make a statement about an RFC as whole (i.e, the 
> entire RFC), or even say something about specific 
> subfunctionality within an RFC.
> 
> What we wouldn't do is have this document try and update or 
> clarify ambiguities in the existing specifications.  E.g., 
> the M&O bits discussion, etc. For one thing, if try to do 
> that, we will likely never get done. Second, the right way to 
> fix problems with specs is to either reissue them, or just 
> publish a short document that just corrects/updates the one issue.
> 
> If we take the approach of being an AS, I think we can side 
> step the question of inforomational vs. BCP for now. Whatever 
> route we end up going, the content of the docuent would be the same.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>