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:james.d.carlson@xxxxxxx]
> Sent: 23. februar 2006 18:47
> To: Jerome Moisand
> Cc: pppext@xxxxxxxx
> 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
> <james.d.carlson@xxxxxxx>
> 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
> Pppext@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/pppext
>
_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext
|
