[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-notifymsg-00.txt (long)
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
References: