On 3 Dec 2015, at 18:39, Tero Kivinen wrote:
Ben Campbell writes:
On 3 Dec 2015, at 6:33, Tero Kivinen wrote:
[...]
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.
I am reading this to say that copied text, with modifications (i.e.
mixed with new or changed text), occurs both inside and outside Appendix
A. If that's the case, then I disagree that the copied text is clearly
marked as such.
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.
You didn't respond to that point, so I will try to clarify it.
I understand, perhaps incorrectly, that you expect this draft to be able
to stand alone; that is, people would be able to implement this draft
just by reading the text in this draft, without having to read 7296.
OTOH, the shepherd's writeup argues that this draft is informational
because it does not define protocol. I think that, as written, this
draft _does_ define protocol, at least constructively. That protocol may
happen to be identical to that from 7296--but this draft, not 7296, is
the authoritative definition.
That being said, I don't really think your intent was to define a new
protocol, constructively or otherwise. As Barry mentioned in his ballot
position, this really seems like an applicability statement for using
7296 in low-power devices, and that implementors really need to
understand 7296. I think it would be reasonable and proper to do that in
an informational RFC. But the attempt to make this draft stand alone
sabotages that.
I think that some text that instructs implementors that they need to
understand 7296, and some markup to clarify _in_detail_ which parts of
this draft merely copy or restate bits of 7296, and which parts describe
changes from 7296 behavior.
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...
I agree that it's not useful to speculate what changes might happen. The
best thing is to assume changes _will_ happen, and not assume they will
just work fine with this draft.
If a reader looks 4306 or 5996, they will find them clearly marked as
obsoleted by the later drafts. If 7296 is obsoleted or updated in the
future, a _this_ draft will not be marked show it. I note that 7296
_already_ has an update, and also has errata. A reader of this draft
will not learn of either of those.
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?
Errata. Deprecation and/or addition of crypto algorithms. Implementation
and security guidance based on implementation experience. BCPs that
describe or change preferred ways to deploy IKEv2. (These are examples,
not an exhaustive list.)
[...]
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
