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

From: "Dorothy Stanley" <[email-masked]>
Date: Mon, 5 Feb 2007 11:58:01 -0800

All,

I believe that issue 153 is distinct from issue 239; issue 153 refers to
behavior in the presence of known messages with unknown message elements,
while 239
seems to refer to unknown messages.

Proposed text to resolve Issue 153 is provided below:

Issue 153:

4) Can "additional" message elements be added to a message? (I believe
so for reporting capabilities, statistics, and     events. For
configuration, there is nothing in the protocol that says what happens
when one end gets an configuration     element it doesn't know about.
Should it be ignored, and the other elements processed, or should the
complete operation     failed?)

Discussion of Issue 153 from the January ad-hoc:
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).

Proposed Resolution of Issue 153:
- Note that some response messages do not carry message elements, e.g.
Change
State event. I've written the text below to require a response only when the
reponse message currently carries information elements.

Insert the following text in section 4.4.1.5:

When a WTP or AC receives a CAPWAP message without a message element that is
specified
as mandatory for the CAPWAP message, then the CAPWAP message is
discarded. If the received message was a request message for which the
corresponding
response message carries message elements, then a corresponding
response message with a Result Code of "Failure - Missing Mandatory Message
Element"
is returned to the sender.

When a WTP or AC receives a CAPWAP message wth a message element that the
WTP or AC does not recognize, the CAPWAP message is discarded. If the
received message was a request message for which the corresponding response
message
carries message elements, then a corresponding
response message with a Result Code of "Failure - Unknown Message Element"
and
one or more Returned Message Element message elements is included,
containing
the unrecognized message element(s).

Add to 4.5.31:

15  Failure - Missing Mandatory Message Element
16  Failure - Unknown Message Element

Comments welcome,

Thanks,

Dorothy Stanley

On 1/30/07, Pat Calhoun (pacalhou) <[email-masked]> wrote:
>
> 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
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > 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
> > elements be added to amessage?
> >
> >
> > On Jan 25, 2007, at 3:38 PM, Sudhanshu wrote:
> > > - 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).
> > >
> > > [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
> >
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: http://lists.frascone.com/pipermail/capwap
>
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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