Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04

From: james woodyatt <[email-masked]>
Date: Fri, 26 Mar 2010 10:33:49 -0700

[added V6OPS list]

On Mar 26, 2010, at 08:11, Ole Troan wrote:

>> Yeah, I think that after the bloody simple-security debates of the past
>> week, that many are amazed that anyone on this list was able to miss the
>> carnage. Anyway, the current CPE router draft has the following security
>> requirements in section 4.4:
>> 
>>  S-1:  The IPv6 CE router SHOULD support
>>        [I-D.ietf-v6ops-cpe-simple-security].
>> 
>>  S-2:  The IPv6 CE router MUST support ingress filtering in accordance
>>        with [RFC2827](BCP 38)
>> 
>> The simple-security draft referenced in S-1 describes exactly what
>> you're asking for (IMO), only in much greater detail. So I think what
>> you're asking for is already in the cpe-router draft, and it would be a
>> good idea for you to look at the simple-security draft and provide
>> comments to it, if you think there's something missing. 
> 
> indeed, apart from the fact that it does not/will not make any recommendation about default on or off.

If the editors of I-D.ietf-v6ops-ipv6-cpe-router would like to host the debate over whether or not to make such a recommendation, then that would make me very, very happy.  We could declare all such flames out of scope for the discussion to review I-D.ietf-v6ops-cpe-simple-security.  I might even consider bribing you with chocolates and fruit baskets if that would help.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Ole Troan <[email-masked]>
Date: Fri, 26 Mar 2010 10:43:31 -0700

James,

> If the editors of I-D.ietf-v6ops-ipv6-cpe-router would like to host the debate over whether or not to make such a recommendation, then that would make me very, very happy.  We could declare all suc…

I'm known to both like chocolate and be gullible, but not _that_ gullible. ;-)

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Fri, 26 Mar 2010 23:08:29 +0100

>>>         [I-D.ietf-v6ops-cpe-simple-security].
What does "support" mean?

I would like it to be very clear that "support" does not imply that it 
be set to "transparent" or "non-transparent" mode by default, just that 
the functionality exist and be available to be turned on or off.

- Mark
> james woodyatt<[email-masked]>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Ole Troan <[email-masked]>
Date: Sat, 27 Mar 2010 15:57:43 +0100

Mark, et al,

[removed ipv6]

> I would like it to be very clear that "support" does not imply that it be
> set to "transparent" or "non-transparent" mode by default, just that the
> functionality exist and be available to be turned on or off.

that was also indeed my understanding when we wrote that requirement.

would this be even clearer:

S-1:  The IPv6 CE router SHOULD support
[I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling this
functionality MUST be user configurable.

to me this means that the default would be decided by a vendor or operator.

not quite sure what the process is for updating a draft which has passed WG LC?

cheers,
Ole

---

From: Fred Baker <[email-masked]>
Date: Sat, 27 Mar 2010 12:21:07 -0700

I have not yet sent it to the IEG. If you want to change it, post one now.

In any event, I expect there would be another round of community review.

> not quite sure what the process is for updating a draft which has passed WG LC?

http://www.ipinc.net/IPv4.GIF

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 27 Mar 2010 15:15:22 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fred Baker (fred)
>Sent: Saturday, March 27, 2010 12:21 PM
>To: Ole Troan
>Cc: Mark Townsley (townsley); IPv6 v6ops
>Subject: Re: draft-ietf-v6ops-ipv6-cpe-router-04

>In any event, I expect there would be another round of community
review.

Good to hear that, Fred.  Mark Townsley also jabbered a comment on
Friday in the v6ops meeting that the Intro or Abstract of the Phase I
IPv6 CE Rtr should be a little more clear to define its goals for simple
vs. Advanced etc.  Did I get this fact correctly? If yes, then once I
get the exact quote from Mark's comments we can look into editing our
document.   Mark also commented on what does one mean by "support" in
his email.  But now the bullet seems to need more work because soon as
one says a feature is configurable, the next question others will ask
is, "well, what's the default"?  So here is a little more modified text
suggestion from me for the relevant bullet.

S-1:  The IPv6 CE router SHOULD implement
[I-D.ietf-v6ops-cpe-simple-security]. Enabling or disabling the security
functionality MUST be user configurable.  The default for whether simple
security is enabled or disabled is specified in
I-D.ietf-v6ops-cpe-simple-security].

Now so we have single source to reference our bullet's properties from;
the source being the I-D.ietf-v6ops-cpe-simple-security.  Now it's up to
v6ops as a WG to nail down which of enabled or disabled is the default
in the I-D.ietf-v6ops-cpe-simple-security.document.

Hemant

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Mon, 29 Mar 2010 09:46:50 -0400

Eee! No! I disagree completely. It is clear to me that there is no
consensus within the IETF as to what such a default will be. I don't see
this changing. Therefore, there should be no default recommendation in
either simple-security or cpe-router. Vendors and service providers are
perfectly capable of deciding for themselves what default they want. If
the IETF did manage to make a recommendation, I suspect that probably
half of the vendors and service providers would choose to ignore that
recommendation, no matter which way it went. Default enabled/disabled
needs to be completely and totally out of scope for both documents.

As for the sentence that Ole recommended adding ("Enabling or disabling
this functionality MUST be user configurable."), that is (IMO)
completely redundant with text that already exists inside
simple-security:

   REC-41: Gateways MUST provide an easily selected configuration option

   that permits a "transparent mode" of operation that forwards all

   unsolicited flows regardless of forwarding direction, i.e. to disable

   the IPv6 simple security capabilities of the gateway.

Therefore, the additional sentence is unnecessary.

Support means support. In general, the more words that get added to try
to restate the same thing, over and over again, because you're worried
people might not interpret the first set of words per your intent, the
more likely it is that you will confuse people and cause them to
misinterpret your intent. To me, the original text is simple, concise,
and says exactly what it needs to say.

Barbara

<snip> Mark also commented on what does one mean by "support" in his
email.  But now the bullet seems to need more work because soon as one
says a feature is configurable, the next question others will ask is,
"well, what's the default"?  So here is a little more modified text
suggestion from me for the relevant bullet.

Hemant </snip>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 29 Mar 2010 20:42:38 +0200

On 3/29/10 3:46 PM, STARK, BARBARA H (ATTLABS) wrote:
> perfectly capable of deciding for themselves what default they want.If

Don't forget the case where the CPE doesn't have a service-provider
managing the gateway. The operational model (and importance of defaults)
is quite different when the primary operator is a consumer vs. an SP.

That's why there is all this stress over defaults. If all CPE in the
world were owned and operated by SPs with active management planes like
TR-69 and the like, a lot more would be "left up to configuration."

> Support means support. 

It was confusing to me.

In general, the more words that get added to try
> and says exactly what it needs to say.

My experience is that certain things must be repeated to be heard. For
example, even if RFC 4864 plainly states "It does not specify an
Internet standard of any kind." people clearly interpret it as such, as
has been discussed at length here.

- - Mark

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Mon, 29 Mar 2010 15:47:44 -0400

> > Vendors and service providers are

<bhs> Which is exactly why I used the phrase "vendors and service
providers". Vendors determine/set the defaults of all CPE that they sell
directly to consumers. I expect such vendors to decide for themselves
how to set the defaults on any such CPE. CPE vendors act a lot like
service providers in this regard. The most successful ones include
functions and set defaults according to what generates the greatest
sales and causes the fewest returns (devices returned for refunds). They
figure out what it is that consumers really want and are willing to pay
for. In my experience, vendors, as a community, tend to be good at
providing different products geared towards different segments of the
market, with different functions and defaults. No matter whether the
IETF recommends default on or off, there will be vendors who ignore that
recommendation. Clearly the community is split over what the right
recommendation is -- so I think we should just let the market decide,
and stop arguing. The market will decide, anyway. </bhs>

> has been discussed at length here.

<bhs> I haven't heard of anyone who interprets RFC 4864 as being "an
Internet standard". I know many who have read it, decided they agree
with what's said in that one section (4.2), and reference it as
describing a function they want. PPPoE isn't a standard, either. That
never kept vendors or service providers from implementing it or
referencing RFC 2516. If an RFC is perceived as being useful and
sensible, it will be widely implemented/referenced. If not, it won't.
This is true of RFCs as a whole, and of individual statements within an
RFC. And the IETF Category is irrelevant in this regard. But if you want
redundancy here, I won't fight it. While I think it's unnecessary, I
don't see that it hurts anything in this particular instance. </bhs>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 29 Mar 2010 22:38:02 +0200

On 3/29/10 9:47 PM, STARK, BARBARA H (ATTLABS) wrote:
<< snip >>

> and stop arguing. The market will decide, anyway. </bhs>

Vendors don't actively manage the CPE being described here though, and
we are talking about configuration parameters in an operations and
management working group document.

I think we're down in a rathole on the relevance of SDOs and the Market
as the final judge. My only point is that there is a real difference
between SP-managed, and Consumer-managed CPE. Disagreements in terms of
base requirements, configuration items and defaults, etc. often reside
in these two very different operational points of view (at least that is
my observation in a number of cases).

> RFC. And the IETF Category is irrelevant in this regard.

Comments from James have me thinking that this is one of the shining
cases of misunderstanding of the difference between "RFC" and "IETF" -
but I do agree that this is a very general feature or bug of the RFC
series and IETF, depending on your point of view. We won't solve that
one way or another here, I'm just trying to live within the realities of
it here and now.

> But if you want

OK. I do think that being very clear about what the document is and is
not recommending when it says "support" is a good idea, outweighing the
danger of being redundant across two documents in this particular case.

Thanks,

- - Mark

---

From: Mark Smith <[email-masked]>
Date: Wed, 31 Mar 2010 18:50:38 +1030

On Mon, 29 Mar 2010 22:38:02 +0200
Mark Townsley <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> 

Unfortunately there is also a middle ground. Even in a market where the
customer owns/manages the CPE (like here in the .au ADSL market), it is
in the SP's interest to provide a level of CPE support, to make sure
the customer can use the services that the SP is selling.

Recommended defaults that make supporting customer owned CPE easy, or
even better, avoidable, have quite a lot of value to SPs. Their
helpdesks are pure cost to them

Regards,
Mark.