Subject: editorial comments on draft-ietf-v6ops-nap-06

From: james woodyatt <[email-masked]>
Date: Mon, 12 Mar 2007 16:15:12 -0700

gentlemen--

My attention was recently drawn to [draft-ietf-v6ops-nap-06], and I  
have found what I think are some easily corrected editorial problems,  
which I hope you will consider making when the AUTH48 event happens.

The document is Informational, not Best Current Practice, so I'm  
concerned about the possibility that excerpts which appear to make  
recommendations for implementers could be quoted out of context  
inappropriately.  I scanned the text for the word "should" and came  
up with a few places where that seems to be an easily corrected error.

In section 4.1: "A basic IPv6 router should have a default  
configuration to advertise inside the site a locally generated random  
ULA prefix, independently from the state of any external  
connectivity."  Also: "With external connectivity the simple gateway  
should use DHCP-PD to acquire a routing prefix from the service  
provider for use when connecting to the global Internet."  Recommend  
replacing "should" with "may" in both cases here.

In section 4.2: "To implement simple security for IPv6 in, for  
example a DSL or Cable Modem connected home network, the broadband  
gateway/router should be equipped with stateful firewall  
capabilities.  These should provide a default configuration where  
incoming traffic is limited [...]."  Also, "There should also be an  
easy interface which allows users to create inbound  
'pinholes' [...]."  Recommend replacing "should" with "may" in all  
three of these cases.

Also in section 4.2: "Administrators and the designers of  
configuration interfaces for simple IPv6 firewalls need to provide a  
means of documenting the security caveats [...]" Recommend inserting  
"may" before the word "need" in this sentence.

In section 4.4: "In any case the approach should be limited to uses  
with substantially fewer than the maximum number of routes that the  
IGP can support [...]" and "Hosts should also listen to the IGP for  
duplicate use [...]" Recommend replacing "should" with "may" here.

Thank you for your time and attention.

-- 
james woodyatt <[email-masked]>
member of technical staff
apple computer, inc.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Mar 2007 15:20:25 +0100

I don't agree. Lower case 'should' in an informational
RFC is not normative; it's an opinion. Using RFC 2119
language would be a problem, but we don't.

     Brian

On 2007-03-13 00:15, james woodyatt wrote:
> gentlemen--
> 
> My attention was recently drawn to [draft-ietf-v6ops-nap-06], and I have 
> found what I think are some easily corrected editorial problems, which I 
> hope you will consider making when the AUTH48 event happens.
> 
> inappropriately.  I scanned the text for the word "should" and came up 
> with a few places where that seems to be an easily corrected error.
> 
> In section 4.1: "A basic IPv6 router should have a default configuration 
> to advertise inside the site a locally generated random ULA prefix, 
> independently from the state of any external connectivity."  Also: "With 
> external connectivity the simple gateway should use DHCP-PD to acquire a 
> routing prefix from the service provider for use when connecting to the 
> global Internet."  Recommend replacing "should" with "may" in both cases 
> here.
> 
> In section 4.2: "To implement simple security for IPv6 in, for example a 
> DSL or Cable Modem connected home network, the broadband gateway/router 
> should be equipped with stateful firewall capabilities.  These should 
> provide a default configuration where incoming traffic is limited 
> [...]."  Also, "There should also be an easy interface which allows 
> users to create inbound 'pinholes' [...]."  Recommend replacing "should" 
> with "may" in all three of these cases.
> 
> Also in section 4.2: "Administrators and the designers of configuration 
> interfaces for simple IPv6 firewalls need to provide a means of 
> documenting the security caveats [...]" Recommend inserting "may" before 
> the word "need" in this sentence.
> 
> In section 4.4: "In any case the approach should be limited to uses with 
> substantially fewer than the maximum number of routes that the IGP can 
> support [...]" and "Hosts should also listen to the IGP for duplicate 
> use [...]" Recommend replacing "should" with "may" here.
> 
> --james woodyatt <[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Tue, 13 Mar 2007 11:20:23 -0700

> language would be a problem, but we don't.

There's no question that lower-case "should" in an informational RFC  
is not normative.

Perhaps, for the sake of consistency then, you might consider  
replacing the word "can" with "should" in the following sentence in  
Section 1, Introduction:

    It then shows how the goals of the network manager *can be* met  
in an
    IPv6 network without using the header modification feature of NAT.

Also, it might be wise to delete the following two sentences altogether:

    It should be noted that this document is 'informational', as
    it discusses approaches that will work to accomplish the goals of  
the
    network manager.  It is specifically not a BCP that is recommending
    any one approach, or a manual on how to configure a network.

If an informational RFC is to be a vehicle for expressing the  
opinions of its authors, then I would argue that it should not  
mislead the reader about that fact in the introduction.

---

From: [email-masked]
Date: Tue, 13 Mar 2007 15:39:26 -0600

james woodyatt writes: 

>    it discusses approaches that will work to accomplish the goals of  the
> If an informational RFC is to be a vehicle for expressing the  opinions of 
> its authors, then I would argue that it should not  mislead the reader 
> about that fact in the introduction. 
>
I would tend to disagree. Although this RFC was written by us, it has gone 
through 5 rounds of comments and changes so that it reflects a consensus of 
the v6OPS working group over the past 2 years and at least 2 (or was it 3) 
IETF conferences. 

Although it is informational it is not an opinion piece. It explains why the 
working group made the decision to do away with NAT in IPv6 in spite of real 
resistance at the beginning. It is meant to explain why NAT is not needed 
and how features that were presumed to be useful in NAT have other options 
in IPv6 natively without the patch work nature of NAT. 

If anything rather than a Best Practices paper this can be considered the 
basis for a white paper to be used to help sell IPv6 within organizations, 
at least that is how the IPv6 Forum seems to be looking at it. 

So stating all of that, I would prefer to leave in the 2 sentences in 
question. 

Eric