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