On 4 Dec 2015, at 17:15, Stephen Farrell wrote:
Hiya,
On 04/12/15 22:31, Ben Campbell wrote:
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.
Ah maybe that's where the disconnect is.
I'm quite sure there is no intent to fork here - implementations
following this are only useful because they interoperate with a full
IKEv2 implementation. They can't even interop with one another and
that is by design. If forking was to be a goal or done, that'd require
much more work and in another WG that'd be specifically chartered for
that (only after a major fuss no doubt).
And we really would notice if someone wanted to make a new version
of IKE or IPsec, honest:-)
Do you see no chance that, sometime down the road, people might update
IKE but forget about this RFC?
I don't think the concern is limited to non-backwards compatible
updates; for example an update to IKE might be backwards compatible, but
add some new feature or optimization that could be beneficial for
constrained devices, but not reflected in this draft.
There is a potential bookkeeping issue with errata etc yes but that's
IMO not much of a showstopper. I guess that as IKE and IPsec evolve
then this will need updating accordingly, though as Tero has done it,
I'd say the things he needs are less likely to change or will change
more slowly. It's likely fairly stable, as a profile. (Note: yes,
those could well be words that come back to haunt me, but I'm ok with
that:-)
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.
For completeness, I would strongly object to such an activity being
based on any concern with this document or the LWIG working group.
If we wanted to re-open IKE or IPsec, that'd require much more support
and much deeper consideration. LWIG is a fine WG, but is not the
vehicle for doing that and won't be. But that's all ok, as there is
no intent to fork that I know of.
Okay, I'm convinced that my concern about informational vs standards
track is a red herring. I'm going to clear the DISCUSS. I still think
the current approach is problematic, but not DISCUSS level problematic.
Cheers,
S.
Thanks!
Ben.
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
