Subject: [Hipsec] HIP Notify text

From: [email-masked] (Henderson, Thomas R)
Date: Tue Mar 23 11:51:01 2004

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]]=20
> Sent: Monday, March 22, 2004 3:49 AM
> To: [email-masked]
> Cc: Miika Komu; Henderson, Thomas R
> Subject: Re: [Hipsec] HIP Notify text
>=20
> OTOH, it would certainly be useful to be able to notify several error=20
> types within different parameters... One could achieve this by=20
> replacing the=20
>=20
> { Reserved (16 bit) | Notify Message Type (16 bit) | Notification=20
> data }=20
>=20
> proposed by Thomas by several Notify chunks:
>=20
> { Notify Parameter Type (16 bit) | Notify Parameter Type (16 bit)
> | Notification Data }
>=20
> The Parameter Type being set to the parameter type which triggered=20
> this notify (e.g., SPI, COOKIE, DH, etc.), or 0 if it's caused by the=20
> base HIP header, and the Notify Parameter sub-type being a per=20
> parameter defined sub type. For example, the parameter SPI could have=20
> the following notify subtypes:
>=20
> o UNKNOWN_SPI 0x01
> o ALREADY_USED_SPI 0x02
> o EXPIRED_SPI 0x03
>=20
> IMHO it gives much more flexibility in notifying errors while not=20
> being overly complex...
>=20
> Thoughts? Thanks,

My sense is that this is overkill-- I don't know how much it matters
to have hierarchical error reporting.  Allowing different notify
parameters to be included in a single packet should be allowed, however.

Tom

---

From: [email-masked] (Julien Laganier)
Date: Tue Mar 23 14:43:01 2004

On Tuesday 23 March 2004 18:35, Henderson, Thomas R wrote:
> > From: Julien Laganier [mailto:[email-masked]]
> > OTOH, it would certainly be useful to be able to notify several
> > error types within different parameters... One could achieve this
> > by replacing the
> >
> > { Reserved (16 bit) | Notify Message Type (16 bit) | Notification
> > data }
> >
> > The Parameter Type being set to the parameter type which
> > triggered this notify (e.g., SPI, COOKIE, DH, etc.), or 0 if it's
> > caused by the base HIP header, and the Notify Parameter sub-type
> > being a per parameter defined sub type. For example, the
> > parameter SPI could have the following notify subtypes:
> >
> > o UNKNOWN_SPI 0x01
> > o ALREADY_USED_SPI 0x02
> > o EXPIRED_SPI 0x03
> >
> > IMHO it gives much more flexibility in notifying errors while not
> > being overly complex...
> >
> > Thoughts? Thanks,
>
> My sense is that this is overkill-- I don't know how much it
> matters to have hierarchical error reporting.  Allowing different
> notify parameters to be included in a single packet should be
> allowed, however.

I can understand it is overkill ;-) 

I first think about this hierarchical error reporting mainly because 
the notify type allocation would be easier. This would allow:

o easier optionnal parameter error handling, because it allows to 
define error code independently for each parameter
o easier alternative informational reporting (apart from error 
reporting)

Anyway your proposal sounds just good to me. I just try to make it 
more flexible.

Thanks,

--julien