Re: Review of draft-bberry-pppoe-credit (Informational)
James Carlson <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
Mark Townsley writes: > This is an individual submission document for Informational publication. > Without getting into whether PPPoE itself should have been strangled at > birth or not, I would like a fair review of this document before > advancing it. Please send comments to the authors and this list before > August 24. I suppose I'm a bit curious why the existing RFC 1663 (PPP Reliable Transmission) and RFC 1989 (PPP Link Quality Monitoring) protocols weren't already sufficient for the job and, if not sufficient, couldn't have been built on to solve the problem. I don't see either mentioned in the draft as related work. I don't think I see a point to having flow control implemented here, as the transport layers already know how to deal with loss by slowing down. Perhaps the real solution might be to fix the "limited buffering" design problem in the affected devices that this draft mentions rather than imposing a new protocol on the rest of the world. There seems to be no description of how the "Receive only" flag might be used. Doesn't RFC 1661 already assume (and require) a bidirectional link? How could a valid and usable PPP link ever be running over a "receive only" link? This proposal seems to further degrade the already tortured PPPoE link MTU. If tag insertion is allowed with PPPoE Session Stage messages (something that RFC 2516 didn't allow), then what happens to the link MTU? Further, I suspect that section 5 of the draft is misworded. The magic value 0106 (which fortunately is not a legal PPP Protocol ID) is used to distinguish the presence of this TLV, and the system shouldn't just check for LCP. One other note: I'm not sure what the "Resources" field is doing in the PADQ message. The amount of remaining battery power (!) doesn't appear to have much to do with link quality. -- 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