Re: Issue 61 (was: Comments ofdraft-ietf-mobike-protocol-04.txt)

Jari Arkko wrote:
> Tero,
> 
> >Perhaps the section 5.1 should say "There is no data associated
> >with this Notify type, and the when processing Notify received from
> >the other end the notify data MUST be ignored." Then we can later
> >add some data there and old version will ignore it. That will allow
> >us possibility to extend this payload later. With the current text
> >implementations can simply fail the whole IKE SA negotiation if
> >there is data in the this notify. (or if you consider this to be
> >too close to the already covered no-version-numbers case, then feel
> >free to ignore this comment).
>
> I don't want to re-open the old issue. But this approach to
> specifying processing of payloads is in general what I want to see
> in any payload, its simply makes sense from an extensibility point
> of view.
> 
> So I'd like to see Tero's proposal adopted.

Exactly this was proposed also earlier, during the discussion on
issue 35. But this is so small change that maybe we could do it.
How about replacing this text in Section 5.1

   The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1.  The
   Protocol ID and SPI Size fields are set to zero.  There is no data
   associated with this Notify type.

with this?

   The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1.  The
   Protocol ID and SPI Size fields are set to zero.  The notification
   data field MUST be left empty (zero-length) when sending, and its
   contents (if any) MUST be ignored when this notification is
   received. This allows the field to be used by future versions of
   this protocol.

Best regards,
Pasi