Re: warning suggestions for draft-bberry-pppoe-credit
Bo Berry <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Well, we do agree on one point, this is silly. Guess it would not be unexpected to say that we disagree with the text and addition of the disclaimer. It appears from these emails (and from emails of past as well), that there is a lot of disagreement on PPPoE. We're not trying to to correct PPPoE. We're not here to debate the process and value of IETF Informational specs. We have proposed and documented extenstions to the PPPoE spec, which are within the context of that spec. These are documented as optional. The draft went through the IETF process and has gone through the expert review period. At this point we can agree to disagree. Therefore we request that the draft be published as is, without any inserted (bias) text, and without any further delay. Sincerely -Bo Berry James Carlson wrote: > Karl Fox writes: > >>Broken. Yes, I said broken. PPPoE is broken. A PPP-over-Ethernet- >>over-radio design that needs new options to work properly is, by >>definition, also broken. Broken because the designers designed their >>product improperly. And now they want us to accept their broken >>design as OK by standardizing it. > > > Agreed; the whole thing is swilly. > > However, I disagree with that last bit. The only intent here is to > publish as Informational (not Standards Track), and to make sure it's > specified to be minimally harmful. > > In an ideal world, we would have been able to argue the authors away > from this split-termination design. There wouldn't have been any > issue here at all, and no draft to write. However, we haven't quite > managed to do that, and they've asked the IESG to publish. > > In an ideal world, the IETF wouldn't have a vanity press feature such > as Informational. Instead, we'd just tell people working on things > that are tangential (or inimical) to our agreed-on technical direction > to go find or form another standards body. However, the IETF does > have this feature, and we've got some built-in limits to what we can > stop. > > I agree it's not pretty, but I think we're getting the best of world > that we can have. The authors were directed here to get input from > folks who know these protocols, even though they were under little > obligation to do so. They got the input and may be mostly > disregarding it, but at least the resulting document will have an > appropriate warning. > _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext