Re: Remaining open issues for RFC-2401bis

[Stephen Kent <kent@bbn.com>]

At 3:30 PM -0800 3/24/04, Mohan Parthasarathy wrote:
>
>
>>  At 11:36 AM -0800 3/24/04, Mohan Parthasarathy wrote:
>>  >  >
>>  >>
>>  >>  >>>>> "VPNC" == VPNC  <Paul> writes:
>>  >>      VPNC> No, we don't. We have ways of encoding the display name and
>>  >>      VPNC> the coments, but *not* the address itself (called the
>>  >>      VPNC> "addr-spec"). RFC 822 and 2822 are completely clear on this.
>>  >>
>>  >>    Ah, good point.
>>  >>
>>  >>      >> 2) we could agree to permit UTF-8 in RFC822_ADDR.
>>  >>
>>  >>      VPNC> Doing so and hoping that the Applications Area Directors don't
>>  >>      VPNC> barf is like
>>  >>
>>  >>    Fine. Point made.
>>  >>    So, we need an identifier that can carry UTF-8, is known to carry
>>  >>  UTF-8, and isn't ID_KEY_ID.
>>  >>
>>  >I hope this does not preclude ID_KEY_ID from carrying UTF-8 in an
>>  >opaque way. I think this is what Paul Koning mentioned in an earlier mail.
>>  >
>>
>>  For the reasons cited earlier, I think it is a bad idea to carry
>>  structured data like UTF-8 in what is described as an opaque octet
>>  string. there is no reason to assume that there will be management
>>  interfaces to facilitate entry of the data in a compatible fashion,
>>  even without the encoding options that Paul has pointed out.
>>
>ID_KEY_ID is defined as an opaque octet stream and UTF-8 can be
>carried as an opque stream of bytes where the two ends do a "memcmp" of the
>opaque byte stream to match on the ID contents. Why is this not possible ?
>As i mentioned in the other mail, this content may be dynamically generated.
>Perhaps we need a different ID to carry structured data like UTF8 that will be
>created through mangement interfaces. At least, that is what i understood from
>the emails on this topic.

My comments on management interfaces for this ID type get at the 
heart of the problem, and I'm a bit disappointed that your messages 
seem to keep ignoring that. This discussion has never been about how 
to perform a comparison of the data; it is about whether users and 
admins interacting with different vendor products will have 
appropriate management interfaces to enter the data that is sent and 
that forms the basis for checking, IF the description of the 
semantics of the data were as stated in IKEv2.

Nonetheless, I agree that a good way to resolve this is to change the 
IKE text back to the v1 version, that makes no mention of account IDs 
etc.

Then, if the WG wants, a separate ID type can be created to carriage 
of account info such as login IDs.

Steve