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.
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.
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 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 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]
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
