Re: draft-ietf-ipsec-notifymsg-00.txt (long)
"Scott G. Kelly" <skelly@redcreek.com> Fri, 18 June 1999 18:44 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA05233; Fri, 18 Jun 1999 11:44:33 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29190 Fri, 18 Jun 1999 12:53:26 -0400 (EDT)
Message-ID: <376A7BEE.F5E813FF@redcreek.com>
Date: Fri, 18 Jun 1999 10:03:42 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Sheila Frankel <sheila.frankel@nist.gov>
CC: ipsec@lists.tislabs.com
Subject: Re: draft-ietf-ipsec-notifymsg-00.txt (long)
References: <3.0.2.32.19990618121400.0069e810@csmes.ncsl.nist.gov>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Hi Sheila, Thanks for your very timely review. Comments interspersed... > Sheila Frankel wrote: > <trimmed...> > > 1) In a number of messages, rather than placing the erroneous > data > > in the Notification Data field, you've incorporated it into another > > Notification Payload field (e.g., for INVALID-PROTOCOL-ID the invalid > > protocol value is placed in the Protocol ID field). This necessitates > > individualized processing for these messages; whether or not that > > processing will take place, it would be helpful if a standardized > > logging routine could just save the Notify Message Type and the > > Notification Data. Yes, I guess I agree. The intent was to use existing fields which matched the data, but which would be empty (taking up space) if the data were carried in the notification data field. I have no qualms with changing it if others don't object. > 2) For each message, you've indicated the Phase and the > > Differentiators. It would also be helpful to list the relevant > payloads > > to which the message applies. (I've added those in my comments; if the > consensus > > is that this isn't useful, that's OK with me.) > Okay with me. I'm going to clip this message at this point to keep the discussion more manageable, and I'll reply to some of the individual payload issues you raise after giving them some more thought, and perhaps hearing from others. I will comment on one other item, though: regarding the unrecognized vs. unsupported payload types, I think this is a very good point. I guess the question is, if I send a notify such as INVALID-PAYLOAD-TYPE, how could the receiver differentiate between the two cases? Scott
- Re: draft-ietf-ipsec-notifymsg-00.txt (long) Scott G. Kelly
- Re: draft-ietf-ipsec-notifymsg-00.txt (long) Sheila Frankel
- Re: draft-ietf-ipsec-notifymsg-00.txt Tamir Zegman
- Re: draft-ietf-ipsec-notifymsg-00.txt Valery Smyslov
- Re: draft-ietf-ipsec-notifymsg-00.txt Scott G. Kelly
- Re: draft-ietf-ipsec-notifymsg-00.txt Scott G. Kelly
- Re: draft-ietf-ipsec-notifymsg-00.txt Anupama Potluri
- Re: draft-ietf-ipsec-notifymsg-00.txt Scott G. Kelly
- Re: draft-ietf-ipsec-notifymsg-00.txt (long) Scott G. Kelly
- Re: draft-ietf-ipsec-notifymsg-00.txt (long) Sheila Frankel
- Re: draft-ietf-ipsec-notifymsg-00.txt (long) Scott G. Kelly