Ben Campbell writes: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Apologies for changing to DISCUSS after my initial NO OBJECTION position, > but I just realized an implication to my comment about copying the IKEv2 > text: > > The shepherd's write up says "[Informational] is the proper type of RFC > because the document describes implementation recommendations for a > proposed standard and is not a proposed standard in itself.". But this > document does not merely make recommendations; it claims to stand alone > as a full specification of everything needed for a minimal > implementation that works with IKEv2. I'd like to discuss why this > should not be standards track, as it's currently written.
The document contains Appendix A which makes it stand alone and that whole appendix is clearly marked of being copied from the 7296: ---------------------------------------------------------------------- Appendix A. Header and Payload Formats This appendix describes actual packet payload formats. This is required to make the document self contained. The descriptions are mostly copied from the RFC7296 and more information can be found from there. ---------------------------------------------------------------------- So I think this document do clearly mark which parts are copied from the RFC7296. It also mentions in the abstract that: ---------------------------------------------------------------------- This document does not update or modify RFC 7296, but provides more compact description of the minimal version of the protocol. If this document and RFC 7296 conflicts then RFC 7296 is the authoritative description. ---------------------------------------------------------------------- I.e. RFC7296 is and will be authorative answer for IKEv2. If the RFC7296 is obsoleted in a way which will make it incompatible with old RFC7296 meaning it will also be incompatile with this draft, then we need to explain in that new version what it means for this document and what it means for RFC7296. If RFC7296 is just updated in a way which does not make old version incompatible, then this document should stay compatible with those changes too. I.e. adding new optinal extensions to IKEv2 (for example the clone-ike-sa) will not affect this document at all, as minimal implementations will be able to ignore the notification payloads used to negotiate it, thus minimal implementations will indicate the other ends that they do not support that extension. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I question the choice of copying IKEv2 text forward into this document, > at least without clearly marking (and citing) the copied text. The copied part is the whole Appendix A, and I think it is quite clearly marked in the beginning of that appendix. Do you think we need better wording in the beginning of that appendix? The reason it says "mostly copied" indicates that not all of the packet formats are copied there, and some of the copied parts are made shorter by removing parts which are not relevant for minimal implementations. > What happens if 7296 gets updated or obsoleted? If 7296 gets updated, then nothing should happen with this document provided that updated IKEv2 is something that will still be compatible with current 7296. I.e if we still keep same major version number then minimal document should still be compatible with updated IKEv2 versions. If the 7296 will be obsoleted by IKEv3 using new major version number, then I assume this document will be obsoleted too and completely new document might need to be written for minimal IKEv3... Note, that IKEv2 has already been updated twice (RFC5996 and 7296 when the original was 4306), and the last version is still compatible with the original one, meaning original 4306 implementations will work with latest 7296 versions. > It seems like that would effectively fork the protocol. RFC7296 is already a fork of IKEv2. Similarly are RFC5996 and RFC4306 versions. All of those versions are interoperable, but newer versions do have some changes which older versions do not know about, but they are made in such way that they are still interoperable with each other. > And since this draft does not seem to distinguish copied text from > new text, I wonder if the other authors of 7296 should be considered > authors of this document. The appendix A is copied from the 7296 and that is clearly stated there. The Acknowledgements section also states that most of the contet of this document is copied from the RFC7296. -- [email protected] _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
