Yoav Nir writes:
> A bigger problem is that this text says that IKEv2 needs to be
> updated, but there is no draft for this update, nor has there been
> any message to this list about this proposed change.
>
> The simple change they require is to section 3.16:
> o Code (1 octet) indicates whether this message is a Request (1),
> Response (2), Success (3), or Failure (4).
Note also that section 2.16 says:
While this document references [EAP] with the intent that new methods
can be added in the future without updating this specification, some
simpler variations are documented here.
and section 3.16 says:
Many
of these methods have been defined, specifying the protocol's use
with various authentication mechanisms. EAP method types are listed
in [EAP-IANA]. A short summary of the EAP format is included here
for clarity.
meaning that the rfc5996 does not even try to be definite guide for
EAP, it just includes some information about EAP protocol for clarity.
> I think this could be done with an errata or a 1-page draft, if all
> that was required was pass-through of codes (5) and (6). But I think
> it's more involved than that.
If it just for pass-through then I do not think even errata is needed,
as it does not change the protocol. The EAP payload contains full EAP
payloads inside, and the EAP payload format listed in the RFC5996 is
only there for clarity and is not mean to be definite protocol
description.
If it changes anything else than pass-through codes not listed in the
RFC5996 then new draft is needed. We should not make same mistakes
again and do techinal changes in errata.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
