1. Section 3.15.1:
o APPLICATION_VERSION - The version or application information of
the IPsec host. This is a string of printable ASCII characters
that is NOT null terminated.
"NOT" is uppercase. Although it might be an intention to ephasise
the fact, that it is not null terminated, but it looks like RFC2119 word,
that is not the case.
2. Section 3.16:
o Type (1 octet) is present only if the Code field is Request (1) or
Response (2). For other codes, the EAP message length MUST be
four octets and the Type and Type_Data fields MUST NOT be present.
In a Request (1) message, Type indicates the data being requested.
In a Response (2) message, Type MUST either be Nak or match the
type of the data requested. Note that since IKE passes an
indication of initiator identity in the first message in the
IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
requests (type 1). The initiator MAY, however, respond to such
requests if it receives them.
...
Note that since IKE passes an indication of initiator identity in the
first message in the IKE_AUTH exchange, the responder should not send
EAP Identity requests. The initiator may, however, respond to such
requests if it receives them.
The last para in the section is absolutely equal to the last two sentences
in the cited bullet, except that it doesn't use RFC2119 wording.
I failed to see that it adds any value here.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
