|
What about future versions that maybe defined??? It makes perfect sense
to do that now than later. Lets agree on the facts because you just don't seem
to get it, and i didn't even attend the meeting. We are going to make the
versions and sub-version noted in the draft to 3.2, agree? (simple yes or
no).
If in the future we want and need new capabilities for ANCP, then another
version/sub-version would be noted in another RFC, agree (simple yes or no). If
the working group feels it would be beneficial and see's that this may come to
light, then we need also a mechanism for negotiating this (imho) of which the we
may use the Adjacency Protocol! I will try and craft some details on this and
post it to the working group list if people find this useful and with
merit.
Woj, i keep my comments technical and not political, you should do the
same as the ANCP Working Group Chair
/Alan
Your post bears no useful or constructive input regarding the topic.
Attempting to define backwards compatibility means drawing on a normative
reference to non-standard drafts and is not reasonable (a reading of
http://tools.ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us advise the WG as
to where ANCP version 3.1 is defined and can be normatively referenced in a v3.2
RFC?
>> I wont
comment because that is
obvious.
If v3.2 and v3.1 are 100% compatible, except for new capabilities, then
there is hardly a reason for a version change. The only way to have a reference
to v3.1 in an rfc re v3.2 is either as a historic note, without claims of
backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Neither
of these proposals seem to be appealing.
In addition, you may also want to reflect on the quality of your
conclusions and comprehension of general facts...
-Woj.
So what are you sugegsting will happen with current
deployments....!!! Like it or not Woj, fact is it must be covered, if you dont
agree then thats just your single opinion here.
By the time you agree on everything we will be onto ANCP
Version 4.10 !!! We are spending far too long on getting this draft out the
door.
Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which
is NOT defined anywhere (in any normative reference or RFC) does not seem
to be acceptable.
The (minuted) discussion did not cover the notion of how ANCP "version
incompatibility" will be handled. Given that we're not out in the WG to
create version compatibility between an ANCP standard protocol and an
ANCP non-standard based one (or GSMP for that matter), it would seem
that no new definition needs to take place. Feel free to discuss this
further on this thread...
-Woj.
Exactly, hence we should ahve this explicitly noted in
the draft.
Alan
In order to ease
migration, it will help if BNGs are able to handle multiple peers with
different versions (e.g. a 3.2 compliant BNG implementation able to work
with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want
to explicitly state that version compatibility requirement is on an
adjacency basis.
The draft will also
need to define how the version incompatibility between BNG and AN needs to
be handled.
-Sanjay
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Alan Kavanagh
Sent: Wednesday, July 29, 2009 9:30
AM
To: Wojciech Dec (wdec);
ancp at ietf.org
Subject: Re: [ANCP] ANCP Protocol
Versioning
Cheers
Woj
The only point i
would note (excuse if it was already raised on Monday as i did not attend)
is "backward compatibility" between the different versions of 3.1, 3.2 and
future versions if/when/as needed. this should be noted in the
draft.
Alan
From:
Wojciech Dec (wdec) [mailto:wdec at cisco.com]
Sent: July 29, 2009 3:33 AM
To: Alan Kavanagh; ancp at ietf.org
Subject: RE: [ANCP] ANCP Protocol
Versioning
Not entirely. ANCP already has a
versioning field, hence nothing new is being defined. Also strictly
speaking there is no distinction between version and sub-version, so the
choice of 3.2 is purely based on custom (it can equally well have been
4.0).
Of course this will mean that
all "pre-rfc" implementations will automatically be 100% incompatible with
the rfc.
-Woj.
From:
Alan Kavanagh [mailto:alan.kavanagh at ericsson.com]
Sent: 28 July 2009 19:28
To: Wojciech Dec (wdec);
ancp at ietf.org
Subject: RE: [ANCP] ANCP Protocol
Versioning
Hi Woj
et.al
So are we
agreeing that option 1 as noted on slide 15 in the Thomas's presentation
is what was agreed on at yesterdays meeting?
BR
Alan
K
From:
ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec
(wdec)
Sent: July 28,
2009 5:30 AM
To:
ancp at ietf.org
Subject: [ANCP] ANCP Protocol
Versioning
Hi
All,
During yesterday's ANCP WG
meeting at IET75 we discussed the topic of ANCP versioning and in the room
arrived at the following conclusion:
The Pre-RFC version of ANC
will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC
Editor's note will be introduced to change version from 3.1 to 3.2 upon
publication of the RFC. This will clearly de-lineate any pre-RFC
implementations with post-RFC ones and alleviate the operators'' problems
presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)
Going beyond the publication
of the RFC, the introduction of new capabilities or TLVs is expected to be
handled by the capability negotiation mechanism (and new capabilities) or
possibly by generalizing the notion of sub-capability currently in place
for the multicast-control use-cases.
We would like to get feedback
from the wider WG on the above, especially in terms of anyone who was not
able to voice their opinion at the meeting. Based on the received
feedback, we'll make a call regarding the WG consensus on this
matter.
Regards,
Woj.
|