RE: Suggesting Improvements in RFC 1990.
Vernon Schryver <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
> From: "John Bray \(bray\)" <[email protected]> > To: "Hariharasubramanian CS" <[email protected]> > Cc: [email protected] > > I reiterate my earlier statement that I don't think your proposed > wording changes are significant enough to justify replacing RFC 1990. That would be entirely true even if most of proposed changes were not simply wrong. Replacing RFC 1990 would inevitiably introduce new placs where the wording confuses people. At this date, more than 10 years after the first interoperable implementations, there cannot be many significant bits of confusion. There are textbooks that explicate the current text. Combined with the RFC and the open source implmentations, they surely resolve any questions. If there were to be a new RFC, I would: - change the name of the protocol to match common practice. I've always tried to follow the RFC and call it "MP", but most people call it something like "MLPPP." - get rid of or deprecate Self-Describing-Padding. I disagree with James Carlson. I believe there are no existing implementations except perhaps student exercises that include Self-Describing-Padding. I always thought self-describing-padding was a solution in search of a problem and not just in MP. PPP implementations that lacked byte- agile DMA hardware could always use other tactics to reach an even number of bytes. Today, hardware often uses buses a lot wider than 16 bits and have mechanisms to make them look narrow. I think section 3.1 exists mostly to document a compromise between my steadfast objections to Self-Describing-Padding and some equally determined advocacy of it. - get rid of or deprecate section 5. Reliable PPP was another solution in search of a problem. I vaguely recalled that RFC 1663 was deprecated, but it is still PROPOSED STANDARD in the Index and I can't find the RFC deprecating it that I thought I recalled. Maybe I'm thinking of the RFC that reclaimed many dead and never used DHCP options. - get rid of most of the Endpoint Discriminator Option types and keep the couple that have actually been used, and might ever be used. But again, the unavoidable new errors in a new version are not justified by minor housecleaning. Vernon Schryver [email protected] _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext