On 3 Dec 2015, at 7:46, Jari Arkko wrote:
For what it is worth, I at least saw the marking of the appendix
material as clear.
I have a comment on the status of the document. I have no objection
to using other status classifications (Proposed Standard and/or
Applicability Statement), but from my perspective of someone who
might use this technology, Informational is a good fit. We already
have the standard. We are not changing the standard. Someone has
provided information about how to implement the standard in a
given setting and under constraints. This useful information
and a useful reference for people who building things.
There is no presumption that the same answer is applicable for
other environments. The document is quite clear on what the
requirements of the standard are.
The document has some material copied instead of using the
by reference approach. I consider that an editorial choice, and
only an editorial choice. It should not affect the standing
of the document as such. FWIW, the editorial choice has
some trade-offs, but one that is not made in the document
is not an unreasonable one. And the document certainly
is clear in what it says. Other choices might have been
made with a different set of trade-offs, but that’s another
matter.
Hi Jari,
I actually agree that it would be appropriate to describe how to use
IKEv2 with constrained devices in an informational RFC. But I think the
way this draft handles the "copy vs reference" question goes beyond the
editorial.
My concern is that statements like "This document is intended to be
stand-alone, meaning everything needed to implement IKEv2 is copied here
except the description of the cryptographic algorithms." make this draft
the authoritative specification for IKEv2 on constrained devices. If RFC
7296 has errata (it does), is updated (it has been), or even obsoleted,
those changes will not be reflected in this spec. Likewise, errata and
updates to this draft won't be reflected back to 7296. That seems to me
to effectively fork the protocol.
I don't think the intent is to really fork IKEv2 into a
separate-but-compatible protocol for constrained devices. But if that is
the intent, then that seems like something that we should at least
discuss putting on the standards track.
Thanks!
Ben.
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
