WGLC comments on draft-ietf-radext-tunnel-type-00.txt

["Glen Zorn" <glenzorn@comcast.net>]

I was the first to comment on this draft, the day it came out; apparently,
however, my comments were lost in the flurry of positive comments from
unrecognized (by me) people with Yahoo! email addresses (I suppose that MSN
would have been too obvious ;-) so I'll try again.

The title is so vague as to be meaningless: suggest changing to the
extremely unwieldy "A RADIUS Tunnel Type for IP Encapsulating Security
Payload (ESP) in the Tunnel-mode with IKEv2" or some such thing (see below),
w/an appropriate abbreviation for the second & following pages.

The document allocates two tunnel types but briefly discusses only one of
them; the other, proprietary to Microsoft Corporation, receives no attention
whatsoever.  Were we not supposed to notice that it was there?  This is a
problem because RFC 2868 states that new Tunnel-Type values are to be
assigned using the "IETF Consensus" policy (note that RFC 2868 is
specifically _not_ updated by RFC 3575).  RFC 5226 says

      IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

Given that there is no discussion whatsoever of Microsoft SSTP in this
document, I can't see how anyone could judge from reading it whether the
proposed assignment will "negatively impact interoperability or otherwise
extend IETF protocols in an inappropriate or damaging manner" or not.  As I
mentioned in my original review, the best solution would be to separate the
Microsoft proprietary stuff into another document, both documenting SSTP and
allocating a Tunnel-Type value for it.

The only reference given for SSTP is to a Microsoft marketing Web site.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>