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:-) 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. 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
