From: Alan Kavanagh [mailto:alan.kavanagh at ericsson.com]
Sent: 14 October 2009 19:50
To: Wojciech Dec (wdec); ancp at ietf.org
Subject: RE: ANCP Versioning - next stepsIn general i support this way forward by adding "Informative Reference" to the ANCP Protocol Draft when going to WG last call.Just for clarification, what is the reason for not offering guarantess for backward compatibility?Woj> Since there in effect is no standard for v3.1, and there won't be one, it's unclear as to how any form of backwards compatibility could be guaranteed-Woj.Alan
From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: October 14, 2009 7:07 AM
To: ancp at ietf.org
Subject: [ANCP] FW: ANCP Versioning - next steps
Hi All,
During the ITEF75 WG meeting a discussion was had on ANCP protocol versioning and the need to revise the protocol version. A follow-up e-mail discussion on the WG alias took place and it seems appropriate now (if not overdue) to draw up a set of recommendations and settle the issue:
Recommended protocol draft changes and WG actions
- The currently used ANCP version 3.1 is to change to 3.2 at the time of publishing as an RFC. An instruction to execute such a change should be placed as part of an editors' note in the next revision of draft-ietf-ancp-protocol. This instruction is expected to only come into effect at the time of final review past a WG last-call, which means that until then v3.1 will be in evidence. Current implementers should make a note of this fact.[Alan Kavanagh] Agree it makes sense to include the noted change of ANCP Version/Sub-version to 3.2 and agree that this should be captured in the current draft as an editors note.
- Another note (not editorial though) should be placed in an appropriate section, possibly Section 2 or Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) based on early versions of the ANCP protocol draft. The note should be clear in offering no guarantees in terms of backwards compatibility of the RFC spec to those early-draft implementations. The note must also not be seen as passing a normative reference to the early protocol draft. [Alan Kavanagh] Agree an Normative Reference should note the reason for change from 3.1 to 3.2 and I support the recommendation here, the most appropiate section i believe is Section 5 imho.
- Along with the above note, the existing GSMP/ANCP version negotiation mechanisms could be highlighted, indicating that it provides a way to distinguish between the different versions if the adjacency establishment negotiation mechanism followed by all is as per GSMPv3 (rfc3292).
[Alan Kavanagh] Agree, though RFC 3292 does not have sub-version.- For the sake of clarity it is recommended that the adjacency negotiation be more fully described in the ANCP protocol draft instead of the current reference to rfc3292. Specifically, it would appear reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-edit describing the version negotiation behaviour.
[Alan Kavanagh] Agree, and this is what I proposed sometime back, though 3292 does currently not cover sub-version and this must be covered in the re-edited section to be included in the ancp protocol spec, For clarification, what is your recommendation for the adjacency negotiation? Is it to include the sub-version also?. Rather confusingly Rfc3292 Section 11.2 does not carry text or logic statements as to the expected behaviour in case of version differences, but such text is in evidence in the descriptive part of Section 11.1.[Alan Kavanagh] Therefore are you noting we should include text in the ANCP protocol draft as to what expected behaviour should be in the event of Version/sub-version differences?- The WG should identify what version of the ANCP protocol draft specification constitutes v3.1. A non-normative reference to such a reference could be passed in the v3.2 spec.
Rationale
From a technical point of view, given that a "current" (i.e. draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, with any newly added functions covered as negotiable capabilities, the version change does not appear to be fully warranted and not fully in line with the guidelines previously laid down (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from an operational perspective a reasonable case for such a version change has made based and presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.htm.
Now, given that normative compliance to an interim draft (such as draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text which may be perceived as mandating or claiming compatibility to such interim drafts needs to be avoided.
In the case of vendors and operators that already support/use v3.1 and have plans for v3.2, the version negotiation mechanism that ANCP inherited from GSMPv3 provides a way to disambiguate the two protocols and thus allows in theory for supporting running a pre-standard (v3.1) and a standards compliant v3.2 on any given ANCP node. [Alan Kavanagh] Agree, will this be noted in the ANCP protocol draft as opposed to a reference pointer to RFC3292? The issue of where v3.1 is documented can be solved by using non-normative references to one of the interim drafts. The issue of what rev of draft-ietf-ancp is considered to be v3.1 needs to be clarified.
Other than the above the WG is currently not chartered to be extending the protocol spec to cover issues around protocol version negotiation or remediation of incompatibilities of draft implementations. As such no such work is expected.
We welcome clarification questions on the above.
Regards,
Wojciech & Matthew.