RE: Re: Last Call: 'Accommodating an MTU/MRUgreaterthan1492in PPPoE' to Informational RFC

Ok, then we have diverging philosophies on default settings...

In any case, irrespective of the default setting, the protocol isn't
broken since the setting can be changed.

Anybody else having views on this topic, notably folks actually involved
in corresponding implementations & deployments?

-----Original Message-----
From: James Carlson [mailto:[email protected]] 
Sent: Thursday, February 23, 2006 12:47 PM
To: Jerome Moisand
Cc: [email protected]
Subject: RE: [Pppext] Re: Last Call: 'Accommodating an
MTU/MRUgreaterthan1492in PPPoE' to Informational RFC

[Dropping ietf and iesg from the list, as we probably should have done
quite some time ago.]

Jerome Moisand writes:
> I don't know of any real-life use case where an AP is in the way,

That's precisely my point.  We don't know.  And we can't know.  I'm
explicitly arguing that any protocol that relies this strongly on
deployment considerations in order to be "correct" is just plain
broken.

If someone wants to make a knowing violation of an RFC's
recommendations because his particular deployment scenario allows or
encourages it, that's fine.  I see no problem at all with that.  It's
not as if there are "RFC police" who will stop him.  But I do *NOT*
believe that such local "optimizations" are what should be described
or encouraged in the RFC itself.

> but
> the protocol extension *IS* general-purpose, the MTU/MRU testing
> mechanism option is there, and can be used. Tuning the default
behavior
> to the main use cases doesn't preclude to enable the other behavior in
> other (yet unforeseen) environments. 

I think this is backwards.  The default should be to be robust.  For
those who don't care about robustness for some reason, then the safety
features can be disabled.

> Adding an unnecessary round-trip (hence adding latency & burden) is
> definitely a protocol issue, not an implementation issue.

I still don't see it.  This is a test that can be assumed to succeed
and can be performed in parallel with starting up IPCP and other
services.  It should have essentially *zero* cost in any reasonable
implementation.

I don't think that assuming either poor implementation or bad overall
design should be a requirement.

> I really have troubles to understand why a default setting should not
be
> tuned with the main use cases as known at the time of writing.

Because RFCs are meant to capture good practice, not just some quirk
of the deployment issues we see today.

> << This capability SHOULD be disabled by default, but SHOULD be
>    available for debug & test purpose, or for topologies where a
>    dynamically adaptive behavior is required.>>
> 
> Is this better? If you have a better wording, please speak up. I do
> agree this sentence needs to be improved.

No.  This would be better:

  This capability SHOULD be enabled by default, because the failure
  mode is difficult for users to diagnose correctly and otherwise
  impossible to protect against.  It MAY be configurable and MAY be
  disabled on networks where there is some prior knowledge indicating
  that the test is not necessary.

-- 
James Carlson, KISS Network                    <[email protected]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pppext