Re: #23 [*] KE interoperability (section 6.8)

> > so I would like to propose the following process.  any idea ?
> > 
> >    All node conformed to the document MAY implement the KE payload
> >    handling.  If a node receives a KE payload, and the receiver does not
> >    support the KE handling, and does not want to proceed the negotiation,
> >    then the receiver SHOULD send a Notify payload of the type
> >    NO_PROPOSAL_CHOSEN to the sender.  If the receiver wants to keep the
> >    negotiation without the KE payload handling, then the receiver sends
> >    a response witout a KE payload.  the sender MAY reject it by its policy
> >    in this case.

I meant the sender was the initiator.

> The sender (I assume you meant the initiator) can't reject it
> because the ACK message can't carry it.

the one does not need to proceed the ACK handling.  as referencing to
the section 7.2, when the initiator reject it, then the initiator
SHOULD re-send a CREATE message without KE payload.

> >    If the receiver does not want to process the KE payload by its policy,
> >    the receiver SHOULD send a Notify payload of tye type INVALID_KE_PAYLOAD
> >    to the sender.
> >    Notification Data MUST contain the KE payload in both case.  the Protocol
> >    ID MUST be 1, and the SPI Size MUST be zero.
> 
> What is the difference between NO_PROPOSAL_CHOSEN and
> INVALID_KE_PAYLOAD?  "Not supported" and "Rejected by policy"?

yes, correct.