IDXP status

I have made all the updates I am planning to make, and have posted them in
the draft-ietf-idwg-beep-idxp-05 memo of June 17, 2002. The last unresolved
issue of Glenn's is shown below. Unless I hear anything to support Glenn or
requests to change the wording, the IDXP memo will stay the way it is.

On Mon, 24 Jun 2002, Glenn Mansfield Keeni wrote:
>  > GMK  4. Sec 5 Page 21
>  > ID    The [protocol] SHOULD be able to ensure non-repudiation of the
>  > ID    origin of IDMEF messages.
>  > ID
>  > ID        IDXP supports non-repudiation of message origin through the
use
>  > ID        of an appropriate underlying BEEP security profile.  The TLS
>  > ID        profile is an example of a security profile that offers non-
>  > ID        repudiation of message origin through the authentication of
>  >
>  > GMK  The above may be misleading. It is not clear how this will be
done.
>  > GMK  To my knowledge TLS does not guarantee non-repudiation of message
>  > GMK  origin. (It can ensure non repudiation of TLS session origination
>  > GMK  - but that does not ensure non-repudiation of message origin.).
This
>  > GMK  is probably a message content matter and thus beyond the
communication
>  > GMK  protocol.
>  >
>  > BSF  Point taken.  I've rewritten this section, hopefully more to
>  > BSF  Glenn's liking.
> Unfortunately not. non-repudiation of message origin cannot be done by
> BEEP/IDXP. And non-repudiation of session origin is not what is sought.
> I would recommend that you drop this. And maybe it should be dropped as
> from the (protocol) requirement document too.

> Ben Feinstein
>   Software Development Engineer, R & D
>   W: 678.585.7865 x6726 F: 770.645.8311 M: 678.772.4126
>   8302 Dunwoody Pl., Suite 320, Atlanta, GA 30350 www.guardent.com
> _____________________________________________________
> G U A R D E N T
>   Enterprise Security and Privacy Programs
>