Ignore my message, I didn't realize this was settled and was trying to help... Then my mail decided to finish synchronizing.
Kathleen Sent from my iPhone > On Dec 7, 2015, at 8:38 AM, Kathleen Moriarty > <[email protected]> wrote: > > > > 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
