Re: Reigning in "bad" extensions to PPP

> Could we do this for all of the PPP state machines with a single
> document?  This seems like a worthwhile effort that should be done
> immediately.

I agree. This gets the biggest bang for the buck.

> > If you want to reign in bad uses of PPP, there are ways of documenting
> > that too, but it's a bit more work. One  possible example is:
> >
> >      RFC 3427 "Change Process for the Session Initiation Protocol (SIP)"
> >
> > That document contains the steps that must be followed for extending
> > SIP. Having such documents makes it a lot easier for the IESG to say
> > "no" to bad requests, since we would be speaking for the PPP
> > community.

> There are a lot of words in RFC 3427.  Some, such as those about X-headers
> don't seem relevant.

yep. Maybe enough ground can be covered in an IANA considerations
document. For example, when describing the IPCP name space, one could
say it is intended for link-specific PPP-specific configuration
information and is not intended to be used for carrying generic stuff
that can be carried by more general protocols like DHCP or RIP/OSPF.

> Perhaps it would be sufficent to corral all of the PPP (sub)option numbers.

> What do we need to do to get at least that started?

Go to the IANA web page for PPP and look at all the name spaces. Start
with a document modeled after draft-aboba-radius-iana-07.txt and have
a section or sub-section for each name space and say what the policy
should be for each of them and under what conditions an allocation is
appropriate (Reading RFC 2434 is probably also a good thing at this
point). The key thing it to ensure that sufficient review takes place
by someone familiar with PPP before an assignment is allowed that
might lead to "abuse" of PPP.

Thomas