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

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

> Glen Zorn writes...
> 
> > 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.
> 
> Agreed.
> 
> > The document allocates two tunnel types but briefly discusses only
> one of
> > them; the other, proprietary to Microsoft Corporation, receives no
> > attention whatsoever.
> 
> > 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.
> 
> Well, there is no attempt to standardize SSTP here, just to allow
> RADIUS to
> provision it.  

In a standard fashion...

> Given that adding a new value of an integer-type
> enumerated
> value attribute is not likely to have any adverse impact on the RADIUS
> protocol, I see no need for extensive discussion there.  One can argue
> whether SSTP itself is a good or bad thing, but that discussion seems
> somewhat orthogonal to the issue at hand.

In that case, perhaps all the discussion of IPSec is extraneous, as well?
My point is that at least a couple of paragraphs in the draft are devoted to
providing justification of the new IPSec tunnel type, but there is no
justification given whatsoever for the allocation of the proprietary one.
This seems a bit backwards to me; OTOH, if we're just going to sanction
allocation for the asking, then why require a document at all?

> 
> > The only reference given for SSTP is to a Microsoft marketing Web
> site.
> 
> Well, the MSDN Library is not a marketing site, but rather a technical
> reference site.  

Ever heard of technical marketing? ;-)

...


--
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/>