Subject: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals

From: Gopal Dommety <[email-masked]>
Date: Mon, 15 Aug 2005 18:03:57 -0700

Hello All,

During the last IETF, I realized that some of the submitted proposals might 
differ from what is  implemented significantly.  I was wondering if there 
is any documentation of the number of implemetations for each of the CAPWAP 
Protocols (as submitted)? Is there any emphasis to "running code" for the 
CAPWAP protocols being considered?

Regards,
-Gopal

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Mon, 15 Aug 2005 23:26:52 -0600

There's no emphasis yet to running code - at least not set as an
Objective or Evaluation criterion.

One way to look at this is that as many as 15-16 implementation
experiences broadly fell into two categories; and the focus was to
identify and seek commonality in architecture/split which by itself has
been something to converge on; before contemplating possible
implementation adoptions - given most of the candidate protocol specs
kept evolving quite a bit across the last two-three IETF sessions.

-mani

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Gopal Dommety
Sent: Monday, August 15, 2005 6:04 PM
To: [email-masked]
Subject: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP
Proposals

Hello All,

During the last IETF, I realized that some of the submitted proposals
might differ from what is  implemented significantly.  I was wondering
if there is any documentation of the number of implemetations for each
of the CAPWAP Protocols (as submitted)? Is there any emphasis to
"running code" for the CAPWAP protocols being considered?

Regards, 

-Gopal

---

From: Gopal Dommety <[email-masked]>
Date: Tue, 16 Aug 2005 11:34:06 -0700

Thanks for the clarification. I am bit surprised  that there is no need for 
an implentation of a protocol for it to be selected.

I understand that making minor extensions to Protocols are necessary. 
However,  Fundmental/Significant deviations between the specifications and 
implentations will not get us anycloser to the goal of interoperability.

Cheers,
-Gopal

At 11:26 PM 8/15/2005 -0600, Mani, Mahalingam (Mahalingam) wrote:

>There s no emphasis yet to running code at least not set as an Objective 
>or Evaluation criterion.
>
>
>
>implementation adoptions given most of the candidate protocol specs kept 
>evolving quite a bit across the last two-three IETF sessions.
>
>
>
>-mani
>
>Subject: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP Proposals
>
>
>
>Hello All,
>
>might differ from what is  implemented significantly.  I was wondering if 
>there is any documentation of the number of implemetations for each of the 
>CAPWAP Protocols (as submitted)? Is there any emphasis to "running code" 
>for the CAPWAP protocols being considered?
>
>
>Regards,
>
>-Gopal

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 17 Aug 2005 11:19:55 +0800

Hi Gopal,
 
Having running code is nice. However, before the group agree on the
common objective details and selection criteria, running code means
nothing. Interoperability is achieved by a well defined specification,
not the implementation of that specification (the running code). People
can implement the IP ugly, but it should still be able to interoperate
with other IP nodes. I guess the top priority now is to work on a
specification that contains features to meet our agreed objectives.
Emphasizing on running code now will just deviate us from the real goal.

cheers
 
Cheng Hong

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Gopal Dommety
	Sent: Wednesday, August 17, 2005 2:34 AM
	To: Mani, Mahalingam (Mahalingam)
	Cc: [email-masked]
	Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted
CAPWAP Proposals

	Thanks for the clarification. I am bit surprised  that there is
no need for an implentation of a protocol for it to be selected. 
	
	I understand that making minor extensions to Protocols are
necessary. However,  Fundmental/Significant deviations between the
specifications and implentations will not get us anycloser to the goal
of interoperability. 
	
	Cheers,
	-Gopal
	
	At 11:26 PM 8/15/2005 -0600, Mani, Mahalingam (Mahalingam)
wrote:

		There s no emphasis yet to running code at least not set
as an Objective or Evaluation criterion.

		One way to look at this is that as many as 15-16
implementation experiences broadly fell into two categories; and the
focus was to identify and seek commonality in architecture/split which
by itself has been something to converge on; before contemplating
possible implementation adoptions given most of the candidate protocol
specs kept evolving quite a bit across the last two-three IETF sessions.

		-mani

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Gopal Dommety
		Sent: Monday, August 15, 2005 6:04 PM
		To: [email-masked]
		Subject: [Capwap] Exisiting Implementation(s) for
Submitted CAPWAP Proposals

		Hello All,
		
		During the last IETF, I realized that some of the
submitted proposals might differ from what is  implemented
significantly.  I was wondering if there is any documentation of the
number of implemetations for each of the CAPWAP Protocols (as
submitted)? Is there any emphasis to "running code" for the CAPWAP
protocols being considered?

		Regards, 
		
		-Gopal

---

From: "Darren Loher" <[email-masked]>
Date: Wed, 17 Aug 2005 07:58:00 -0700

One of the tenets of the IETF is "running code".  This is in fact a
requirement to elevating a draft to a draft-standard.  It is also (on
the "soft-side") a measure of strength and value for a given standard
when it is in place.  We are not at that stage yet, but it is a hurdle
that will need to be overcome to get a standard.

From BCP 9 / rfc2026:

4.1.2  Draft Standard
 
   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.  For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.  If patented or otherwise controlled technology
   is required for implementation, the separate implementations must
   also have resulted from separate exercise of the licensing process.
   Elevation to Draft Standard is a major advance in status, indicating
   a strong belief that the specification is mature and will be useful.
 
   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.
 
   The Working Group chair is responsible for documenting the specific
   implementations which qualify the specification for Draft or Internet
   Standard status along with documentation about testing of the
   interoperation of these implementations.  The documentation must
   include information about the support of each of the individual
   options and features.  This documentation should be submitted to the
   Area Director with the protocol action request. (see Section 6)

 

-Darren

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cheng Hong
Sent: Tuesday, August 16, 2005 9:20 PM
To: Gopal Dommety; Mani, Mahalingam (Mahalingam)
Cc: [email-masked]
Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP
Proposals

Hi Gopal,

 

cheers

Cheng Hong

	

	
	
	Cheers,
	-Gopal

	

	There s no emphasis yet to running code at least not set as an
Objective or Evaluation criterion.

	
	-mani

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Gopal Dommety
	Sent: Monday, August 15, 2005 6:04 PM
	To: [email-masked]
	Subject: [Capwap] Exisiting Implementation(s) for Submitted
CAPWAP Proposals

	Hello All,
	
	During the last IETF, I realized that some of the submitted
proposals might differ from what is  implemented significantly.  I was
wondering if there is any documentation of the number of implemetations
for each of the CAPWAP Protocols (as submitted)? Is there any emphasis
to "running code" for the CAPWAP protocols being considered?

	Regards, 
	
	-Gopal

---

From: "Cheng Hong" <[email-masked]>
Date: Thu, 18 Aug 2005 10:31:06 +0800

Hi Darren,
 
Thanks for dig out that text. Would like to point out that the text is
about bring a specification to the draft standard. Something described
there doesn't really apply to the down selection process (e.g. about the
remove of options). Also, as pointed out by the Chair and yourself, we
are not at that stage yet. Do we have "at least two independent
implementation" for each of the proposal now? (I guess this was already
debated in other thread. Seems none of the proposal qualified for that)
So, how should the "running code" be used for the down selection? I
don't think we can simply dictate that one proposal is better since it
has two implementations, and others are bad. Therefore, I would like to
argue against putting "emphasis to running code" AT THIS STAGE.

cheers
 
Cheng 

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Darren Loher
	Sent: Wednesday, August 17, 2005 10:58 PM
	To: Cheng Hong; Gopal Dommety; Mani, Mahalingam (Mahalingam)
	Cc: [email-masked]
	Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted
CAPWAP Proposals

	One of the tenets of the IETF is "running code".  This is in
fact a requirement to elevating a draft to a draft-standard.  It is also
(on the "soft-side") a measure of strength and value for a given
standard when it is in place.  We are not at that stage yet, but it is a
hurdle that will need to be overcome to get a standard.

	From BCP 9 / rfc2026:

	4.1.2  Draft Standard
	 
	   A specification from which at least two independent and
interoperable
	   implementations from different code bases have been
developed, and
	   for which sufficient successful operational experience has
been
	   obtained, may be elevated to the "Draft Standard" level.  For
the
	   purposes of this section, "interoperable" means to be
functionally
	   equivalent or interchangeable components of the system or
process in
	   which they are used.  If patented or otherwise controlled
technology
	   is required for implementation, the separate implementations
must
	   also have resulted from separate exercise of the licensing
process.
	   Elevation to Draft Standard is a major advance in status,
indicating
	   a strong belief that the specification is mature and will be
useful.
	 
	   The requirement for at least two independent and
interoperable
	   implementations applies to all of the options and features of
the
	   specification.  In cases in which one or more options or
features
	   have not been demonstrated in at least two interoperable
	   implementations, the specification may advance to the Draft
Standard
	   level only if those options or features are removed.
	 
	   The Working Group chair is responsible for documenting the
specific
	   implementations which qualify the specification for Draft or
Internet
	   Standard status along with documentation about testing of the
	   interoperation of these implementations.  The documentation
must
	   include information about the support of each of the
individual
	   options and features.  This documentation should be submitted
to the
	   Area Director with the protocol action request. (see Section
6)

	 

	-Darren

[mailto:[email-masked]] On Behalf Of Cheng Hong

	Hi Gopal,

	Having running code is nice. However, before the group agree on
the common objective details and selection criteria, running code means
nothing. Interoperability is achieved by a well defined specification,
not the implementation of that specification (the running code). People
can implement the IP ugly, but it should still be able to interoperate
with other IP nodes. I guess the top priority now is to work on a
specification that contains features to meet our agreed objectives.
Emphasizing on running code now will just deviate us from the real goal.

	cheers

	Cheng Hong

		

		Subject: RE: [Capwap] Exisiting Implementation(s) for

		Thanks for the clarification. I am bit surprised  that
there is no need for an implentation of a protocol for it to be
selected. 
		
		I understand that making minor extensions to Protocols
are necessary. However,  Fundmental/Significant deviations between the
specifications and implentations will not get us anycloser to the goal
of interoperability. 
		
		Cheers,
		-Gopal
		
		At 11:26 PM 8/15/2005 -0600, Mani, Mahalingam
(Mahalingam) wrote:

		

		-mani

		
		Hello All,

		Regards, 
		
		-Gopal

---

From: "Mani, Mahalingam (Mahalingam)" <[email-masked]>
Date: Thu, 18 Aug 2005 09:40:55 -0600

Gopal,

Let me fill you in on disconnects you may be having (possibly picking up
on CAPWAP thread again):

There is nothing wrong in general with having included implementation as
part of objective - perhaps just desirable. We just did not see such a
call for it in WG in course of Objectives review. We (chairs) considered
including it. In the context of taxonomy work yielding as many as 15-16
very similar implementations leading to support for two classes of
control (local & split) some supporting both modes; pointed to much
implementation and field deployment experience.

So the CAPWAP community has close implementation & deployment
experiences - more or less the outcome of which has resulted in RFC3990
and CAPWAP WG.

Nor did we try to make it an added evaluation criterion - as we don't
want to get into a rat-hole if 'interoperable' implementations are
independent or not.

The still-converging split-MAC/AP consensus was implicitly the primary
concern and goal; and it was decided that there's enough opportunity to
make implementation experience relevant on a post-evaluation consensus
protocol. 

The independent interoperable implementations, therefore, will be a
focus for post-evaluation.

Regards,

-mani

  _____  

From: Gopal Dommety [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2005 11:34 AM
To: Mani, Mahalingam (Mahalingam)
Cc: [email-masked]
Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP
Proposals

Thanks for the clarification. I am bit surprised  that there is no need
for an implentation of a protocol for it to be selected. 

I understand that making minor extensions to Protocols are necessary.
However,  Fundmental/Significant deviations between the specifications
and implentations will not get us anycloser to the goal of
interoperability. 

Cheers,
-Gopal

-mani

Hello All,

Regards, 

-Gopal

---

From: "Changming Liu" <[email-masked]>
Date: Fri, 19 Aug 2005 19:49:51 -0700

This brings up a very good question: is there any license/patent  issue
for any candidate proposal to be implemented by any vendor other than
the vendors of the authors? If so, has it be raised somewhere so that
whoever is willing  to implement is aware of it?

Thanks.

Changming

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Darren Loher
Sent: Wednesday, August 17, 2005 7:58 AM
To: Cheng Hong; Gopal Dommety; Mani, Mahalingam (Mahalingam)
Cc: [email-masked]
Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP
Proposals

From BCP 9 / rfc2026:

4.1.2  Draft Standard

 

 

-Darren

Hi Gopal,

 

cheers

Cheng Hong

	

	
	
	Cheers,
	-Gopal

	

	-mani

	
	Hello All,

	Regards, 
	
	-Gopal

---

From: "Changming Liu" <[email-masked]>
Date: Mon, 22 Aug 2005 23:04:41 -0700

Darren,
 
Thanks for the info. Just took a quick look at the Airespace's Statement
about IPR and found a statement below: 
 
"Airespace hereby covenants that it will not assert any patent
claims contained in any of the above-identified pending patent
applications (if and when issued as a Patent) against any party that
makes, uses, sells, imports, or offers for sale, an implementation of
the LWAPP protocol as specified in the Specification, assuming it is
adopted."

I have a trivial question: What does "adopted" mean? Does it mean when
it is selected by the eval team as the "chosen one", when it becomes an
experimental standard or when it becomes a full standard? If the last
one is the case, how can other vendors implement it so that two or more
interoperable copies can be implemented to meet RFC2026's requirement?  

Pat, do you mind elaborating it a bit more? 

Thanks.

Changming

From: Darren Loher [mailto:[email-masked]] 
Sent: Monday, August 22, 2005 4:49 PM
To: Changming Liu; Cheng Hong; Gopal Dommety; Mani, Mahalingam
(Mahalingam)
Cc: [email-masked]
Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP
Proposals

I've asked similar questions.  To my knowledge, the only intellectual
property disclosure that has been filed in the CAPWAP working group is
regarding LWAPP.  You can read it at:

http://www.ietf.org/ietf/IPR/airespace-ipr-draft-calhoun-seamoby-lwapp.t
xt

I have not seen any disclosure from the authors of CTP, WiCoP or SLAPP.

-Darren

From: Changming Liu [mailto:[email-masked]] 
Sent: Friday, August 19, 2005 8:50 PM
To: Darren Loher; Cheng Hong; Gopal Dommety; Mani, Mahalingam
(Mahalingam)
Cc: [email-masked]
Subject: RE: [Capwap] Exisiting Implementation(s) for Submitted CAPWAP
Proposals

Thanks.

Changming

-----Original Message-----

From BCP 9 / rfc2026:

4.1.2  Draft Standard

 

 

-Darren

Hi Gopal,

 

cheers

Cheng Hong

	

	
	
	Cheers,
	-Gopal

	

	-mani

	
	Hello All,

	Regards, 
	
	-Gopal