Sent from my iPhone
> On Dec 4, 2015, at 5:07 PM, Ben Campbell <[email protected]> wrote: > >> 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. I agree with the draft being informational as per the comment on my ballot. However, language changes within the draft to make that point more clear seem to be what Ben is after. Ben, would you be able to provide a few text additions to add the caveats that would help? I do see your point on the copied text, but also that the intent of this draft is to document a PoC only. Thanks, Kathleen > > >>> 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
