[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEv2 issue in RFC2486bis



> o  Define the new IKEv2 ID type as Yoshihiro suggests
>    below.

I'd support this alternative.  IKEv2 is already incompatible with RFC
2486, so this would need to be done anyway.

> Finally, does anyone have a full list of places where the
> NAI can appear? Either because the protocol specs say that
> a particular field is a NAI, or because people take a
> particular application identifier and put it into a place
> which traditionally carries a NAI (such as RADIUS User-Name).
> I think we are talking about PPP, EAP, RADIUS, Diameter,
> SIP and Mobile IPv4, but is this all? What do these specifications
> say about non-RFC822 compliant names?

In PPP, EAP, RADIUS and Diameter the structure of the NAI is not
constrained, so I don't think there is an issue.

In RFC 2794, it defines the NAI field as "A string in the NAI format
defined in [1]." So I don't think there is an issue there either.

I didn't know that SIP utilized the NAI.  Where is this usage defined?

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