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

["STARK, BARBARA H (ATTLABS)" <bs7652@att.com>]

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

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

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