Re: Revised PPP Encryption I-D

[John C Klensin <[e-mail]>]

In the recent tradition of picking draft RFCs to death, the first two
sentences of the last paragraph on page 4 are not written in English...

>   If both compression and encryption have been negotiated, compression
>   MUST be performed on the data prior to encryption.  It is explicitly
>   stated here to aid interoperability.  Performing them in this order
>   should maximise the effect of compression.  Truly encrypted data is
>   unlikely to be compressible.
>
>
>
>
>Meyer                                                           [Page 4]

I also note that the "Code" values are not specified _in this document_ as
to whether they are expressed in ASCII, as binary strings, or as something
else.  I know that is in another document, but it isn't explicitly
referenced in this context.

>   We expect that many vendors will want to use proprietary encryption
>   algorithms, and have made a mechanism available to negotiate these
>   without encumbering the Internet Assigned Number Authority with
>   proprietary number requests.

Arggh.   As written, the OUI material seems to indicate that vendors who
don't make Ethernet hardware, and hence don't have IEEE-assigned Ethernet
address prefixes, can't establish proprietary encryption procedures.  Since
the companies that design encryption tools often don't build hardware, and
since PPP is often practiced over serial links (rather than Ethernet), this
seems strange at best.

The documents describes the assignment process as being "by the IEEE
Standards Office" in one place and "by IEEE 802" in another.  These are not
the same.


To be satisfactory in this type of definition, the document must set forth
the criteria for describing/accepting a non-proprietary encryption type and,
specifically, whether IANA is expected to register types addition to those
specified in this document (zero of them, I note ...).  Section 4.2 does not
provide any information of that type, other than, by implication, publically
available but not necessarily free.

The document implies that there are some specific encryption mechanisms
specified and available on that basis, but does not identify any.

If you are putting out a ballot on this, vote me "discuss".

Sorry, folks.
    john