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

[Mark Townsley <townsley@cisco.com>]

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




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

> <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>



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).


> 
>> 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.
> 
> <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.

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
> 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>
> 

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJLsQ+qAAoJEBAcHDFx3DUI2UwIAIYS1SHePJOi9jFfhng8a+T6
iRovWGC21yGCdKNyhw2jnTOrlUSTezNCOOwTeagNHUD2hAUeMPaC2uGr3XL3jKgX
jKLHNkmJyjH4N/ZnTQMRbWWQykxHt4IdxuMr2cwephKXyZjCiTDSlzqY96iZdcLP
+/RkYHpDJaGo1/SwtHggzZFlk8Sk4oMvZ9+WP/dfv8IrIlKsYe2LoQxHW8v6R7W1
vrd3kZIVyDkABUnErwz20SLjU6mRdbRaQGRrUXaZS9bVWi7+XfIU94vX3oBtW/Qo
lgbOCSw1giB0amMl689C6MzMSx2R4M3LAaR/gKqKMVZgIxCFuFuy0J/6aAxXi64=
=Ycgt
-----END PGP SIGNATURE-----