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

Hi,

the authors of the draft are fine with changing the last paragraph
of section 5.2 from:
---
This capability SHOULD be disabled by default, and SHOULD only be
available for debug, test purpose.
---

into a new text, and we propose this text as a compromise between
the different suggestions voiced on the list.

---
This capability SHOULD be enabled by default. It SHOULD be configurable 
and MAY be disabled on networks where there is some prior knowledge 
indicating that the test is not necessary.
---

This will be included in the version-3 text as soon as we finish the
last-call comments.

thanks for all the good comments,
Peter


> -----Original Message-----
> From: James Carlson [mailto:[email protected]] 
> Sent: 23. februar 2006 18:47
> To: Jerome Moisand
> Cc: [email protected]
> Subject: RE: [Pppext] Re: Last Call: 'Accommodating an 
> MTU/MRUgreaterthan1492inPPPoE' 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
> 



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