Subject: [Capwap] Issue 153: Can "additional" message elements be added to a message?

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 25 Jan 2007 11:08:05 -0800

The agreement at the interim is the following:
- When an device receives a request that has a message element that is
not understood, the message is NOT processed and a response is sent with
the Result Code message element is set to a new value (Unknown message
element) and one or more Returned Message Element is included that
encapsulates the offending message element.
- When a device receives a response that has a message element that is
not understood, the message is ignored.
- If a request is received, and a message element is missing (that is
specified in the RFC), then the request is NOT processed and a failure
response is returned with a new Result Code (Missing message element).

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Sudhanshu" <[email-masked]>
Date: Thu, 25 Jan 2007 12:38:30 -0800

Pat,

Please see my inline comments.

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 11:08 AM
To: [email-masked]
Subject: [Capwap] Issue 153: Can "additional" message elements be added to
amessage?

The agreement at the interim is the following:
- When an device receives a request that has a message element that is
not understood, the message is NOT processed and a response is sent with
the Result Code message element is set to a new value (Unknown message
element) and one or more Returned Message Element is included that
encapsulates the offending message element.
[Suds] What is the meaning for the "Unknown Message Element"? Is it a
success, failure or either?
It is possible to have, these optional message element as *unknown* at WTP
and WTP could be operational with limited capabilities though. 

I don't think it is a good idea to put it as part of result code. Instead it
should be part of the "returned message element(s)" and let AC make the
decision to continue with WTP or not. 

[Suds] OK

[Suds] I think "specified" should be changed to "required"

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 25 Jan 2007 15:21:34 -0800

> - When an device receives a request that has a message 
> element that is not understood, the message is NOT processed 
> and a response is sent with the Result Code message element 
> is set to a new value (Unknown message
> element) and one or more Returned Message Element is included 
> that encapsulates the offending message element.
> [Suds] What is the meaning for the "Unknown Message Element"? 
> Is it a success, failure or either?
> It is possible to have, these optional message element as 
> *unknown* at WTP and WTP could be operational with limited 
> capabilities though. 

Unknown means the message element is not known, not recognized. This is
a failure.
We all agreed that with the introduction of issue 219, there is no
reason why
a WTP would not recognize a specific message element. it may not support
it,
but it MUST know what it is.

> - If a request is received, and a message element is missing 
> (that is specified in the RFC), then the request is NOT 
> processed and a failure response is returned with a new 
> Result Code (Missing message element).
> 
no, we agreed on specified. if it is documented, there is no reason
why someone should only implement part of the spec. Now, again, it 
may opt to not take action on a specific message element, but it
has to recognize it.

Pat Calhoun

---

From: "Sudhanshu" <[email-masked]>
Date: Thu, 25 Jan 2007 18:35:45 -0800

Looks like there is some kind of "agreement", there will be no future
addition of the message elements, after this is standardized. 

And there is "no" optional message elements. As far as implementation is
concerned, it does need to recognize the optional message elements for
conformance purpose.

And there is "no" scope for the vendor specific message elements.

And looks like all the future enhancements (in the spec) will start with
different version number. Not a very good idea.

IMHO, it is a very restrictive implementation in a domain where things are
still changing.

_Suds

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, January 25, 2007 3:22 PM
To: Sudhanshu; [email-masked]
Subject: RE: [Capwap] Issue 153: Can "additional" message elements be added
to amessage?

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 25 Jan 2007 20:39:29 -0800

No, I don't think that's what I said. I *thought* I said that everytime
a new CAPWAP RFC is published, a binding value is assigned by IANA. This
binding value is advertised, as described in the resolution for issue
219.
This allows for a capabilities exchange between the WTP and the AC, so
both
sides of the connection will know what each peer supports.

So there is no reason why one would include an arbitrary message element
in
a message unless it was explcitely permitted in the RFCs supported.

Of course, vendors can add vendor specific message elements if they
wish,
but ONLY if they are talking to their own boxes. Whether they opt to
advertise
support for these vendor specific message elements is up to them.

Hope this makes more sense.

Pat Calhoun

> From: Sudhanshu [mailto:[email-masked]] 
> Sent: Thursday, January 25, 2007 6:36 PM
> To: Pat Calhoun (pacalhou); [email-masked]
> Subject: RE: [Capwap] Issue 153: Can "additional" message 
> elements be added to amessage?
> 
> Looks like there is some kind of "agreement", there will be 
> no future addition of the message elements, after this is 
> standardized. 
> 
> And there is "no" optional message elements. As far as 
> implementation is concerned, it does need to recognize the 
> optional message elements for conformance purpose.
> 
> And looks like all the future enhancements (in the spec) will 
> start with different version number. Not a very good idea.
> 
> IMHO, it is a very restrictive implementation in a domain 
> where things are still changing.
> 
> _Suds
> 
> Subject: RE: [Capwap] Issue 153: Can "additional" message 
> elements be added to amessage?
> 
> element that is 
> > not understood, the message is NOT processed and a response is sent 
> > with the Result Code message element is set to a new value (Unknown 
> > message
> Unknown means the message element is not known, not 
> recognized. This is a failure.
> We all agreed that with the introduction of issue 219, there 
> is no reason why a WTP would not recognize a specific message 
> element. it may not support it, but it MUST know what it is.
> 
> no, we agreed on specified. if it is documented, there is no 
> reason why someone should only implement part of the spec. 
> Now, again, it may opt to not take action on a specific 
> message element, but it has to recognize it.
> 
> 
> Pat Calhoun

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 30 Jan 2007 20:34:02 -0500

Hi Suds,

There are two different mechanisms in CAPWAP that can be used to  
determine what CAPWAP capabilities are supported on a given AC or WTP.

The CAPWAP version number is used to indicate the message format and  
security architecture in use.  The version number would have to  
change if we make changes to the CAPWAP headers or later support a  
different security mechanism (other than DTLS).  This number will not  
be changed if we add new operations or message elements.

The bindings list is used to indicate what operations and message  
elements are supported.  If we later add a new set of operations or  
message elements, we will ask IANA to allocate a binding name that  
can be used to indicate that the new messages are supported.  Vendors  
will also be able to extend the set of operations and message  
elements using their own proprietary bindings.

BTW, we do support optional message elements, in the sense that some  
message elements are required on certain operations and others are  
optional.   The receiver, however, will need to understand all of the  
message elements that are supported for a given operation, so that  
they will not generate an error if the sender includes an optional  
message element.

Does that address your concerns?

Margaret

On Jan 25, 2007, at 9:35 PM, Sudhanshu wrote:

> implementation is

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 30 Jan 2007 20:38:30 -0500

> [Suds] I think "specified" should be changed to "required"

I'm not sure what word we should use here, but I think I see the  
point that you are making.  We would only send a failure response if  
one of the "must contain" message elements was missing, not if one of  
the "may contain" message elements wasn't present...  So perhaps we  
could say "(that is specified as a mandatory message element for this  
operation in the RFC)", or something like that?

Margaret

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 30 Jan 2007 19:19:15 -0800

All,

I made the mistake of opening a new issue for this, so I would
appreciate if folks that care about this issue comment on my proposed
text for issue 239 - send last Friday.

Thanks,

Pat Calhoun

> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Tuesday, January 30, 2007 5:39 PM
> To: Sudhanshu
> Cc: Pat Calhoun (pacalhou); [email-masked]
> Subject: Re: [Capwap] Issue 153: Can "additional" message 
> I'm not sure what word we should use here, but I think I see 
> the point that you are making.  We would only send a failure 
> response if one of the "must contain" message elements was 
> missing, not if one of the "may contain" message elements 
> wasn't present...  So perhaps we could say "(that is 
> specified as a mandatory message element for this operation 
> in the RFC)", or something like that?
> 
> Margaret
>