RE: [Pppext] Suggesting Improvements in RFC 1990.

[Vernon Schryver <vjs at calcite.rhyolite.com>]

> From: "John Bray \(bray\)" <bray at cisco.com>
> To: "Hariharasubramanian CS" <meetcarey at gmail.com>
> Cc: pppext at ietf.org
>
> 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    vjs at rhyolite.com

_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www1.ietf.org/mailman/listinfo/pppext