Ben Campbell writes: > On 3 Dec 2015, at 6:33, Tero Kivinen wrote: > > > 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. > > Does Appendix A contain all of the copied text? If so, then perhaps the > earlier mention of copied text could point out that the copying is > restricted to the appendix.
Appendix A has text that is copied from the IKEv2 RFC, and which have then been shorteded a bit, for example some text which were not needed for minimal implementations were removed from those sections, and certain subsections were left out completely. The main body of the document also has some copied text, but that has been modified much more to make the description shorter, and leaving out text talking about different options etc when that was not needed for the minimal implementations. > However, the point of the discuss was about whether a "stand-alone" > draft should be standards track or informational. The questions about > copied text and updates to 7296 address my (non-blocking) comments. Ok. > > 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. > > > > Do I correctly understand this to mean that 7296 would become burdened > to explain how it differs from a dependent draft that copied text? That > seems error prone at best. If we make change in the IKEv2 which is interoperable with 7296, then that change will most likely also be inteoperable with this one. If we make change in the IKEv2 which will not be interoperable with 7296, then most likely that new IKEv2 will not be interoprable with this document either. In that case the new IKEv2 will most likely need to explain how it proposes to handle the old RFC7296 versions of the IKEv2, and how they are supposed to interoperate. The answer will most likely be same for this document too. On the other hand I do not really see it very useful to try to speculate what kind of changes we might do for IKEv2, that might cause problems with this or RFC5996 or RFC4306 versions of the IKEv2. When we make changes to the IKEv2 we always try to keep changes done in such way that all older version will also work nicely with the new version. If we keep doing that this will mean that this document will also keep working nicely, as this document is based 7296 and we will try to keep new IKEv2 to work with RFC7296 versions of IKEv2... > > 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. > > There are a number of ways that 7296 could be updated that would be > relevant to this draft, but might not make it incompatible per se. For > example, updates to security considerations. I do not really see that happening, can you give me some kind of example what you are meaning there? > [I think the discussion above already covers the comment points > below--please point it out if I missed something.] > > > > >> ---------------------------------------------------------------------- > >> 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] -- [email protected] _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
