| Re: Reserved bits and fields | <– Date –> <– Thread –> |
|
From: Bob O'Hara (boohara) (boohara |
|
| Date: Mon, 28 Aug 2006 11:49:48 -0700 (PDT) | |
Yes, I believe that is what "reserved" should mean.
-Bob
-----Original Message-----
From: Pat Calhoun (pacalhou)
Sent: Monday, August 28, 2006 11:48 AM
To: Bob O'Hara (boohara); 'capwap [at] frascone.com'
Subject: RE: [Capwap] Reserved bits and fields
so the bits could only be defined if the version number changed?
Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
> -----Original Message-----
> From: Bob O'Hara (boohara)
> Sent: Monday, August 28, 2006 11:35 AM
> To: Pat Calhoun (pacalhou); 'capwap [at] frascone.com'
> Subject: RE: [Capwap] Reserved bits and fields
>
> Yes, I still believe that there needs to be a specification
> for the receiver to ignore any value received in the reserved
> bits and fields..
>
> -Bob
>
> -----Original Message-----
> From: Pat Calhoun (pacalhou)
> Sent: Monday, August 28, 2006 10:31 AM
> To: Bob O'Hara (boohara); capwap [at] frascone.com
> Subject: RE: [Capwap] Reserved bits and fields
>
> Bob, based on the thread, do you still feel there are changes
> required to the document?
>
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
>
>
>
> > -----Original Message-----
> > From: Bob O'Hara (boohara)
> > Sent: Monday, August 14, 2006 9:03 AM
> > To: capwap [at] frascone.com
> > Subject: [Capwap] Reserved bits and fields
> >
> > I believe that we are overspecifying the use of the
> reserved bits and
> > fields in the draft. For example, we place a requirement on the
> > transmitter that these bits and fields MUST be zero ("All
> > implementations complying with version zero of this
> protocol MUST set
> > these bits to zero.").
> > However, we do not specify any behavior by the receiver. I believe
> > this is backwards.
> >
> > Because the version field is available to all receivers of a CAPWAP
> > packet and that version field will unambiguously identify all the
> > reserved bits and fields, I believe we should change the
> requirement
> > to be that the receiver MUST ignore any value received in a
> reserved
> > bit or field. This way, should a noncompliant transmitter send
> > something in these fields, the receiver will not be confused by it.
> >
> > -Bob
> >
> > Bob O'Hara
> > Cisco Systems - WNBU
> >
> > Phone: +1 408 853 5513
> > Mobile: +1 408 218 4025
> >
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/capwap
> >
> > Archives: http://lists.frascone.com/pipermail/capwap
> >
>
- Re: Reserved bits and fields, (continued)
- Re: Reserved bits and fields Nelson, David, August 15 2006
- Re: Reserved bits and fields Pat Calhoun (pacalhou), August 28 2006
- Re: Reserved bits and fields Bob O'Hara (boohara), August 28 2006
- Re: Reserved bits and fields Pat Calhoun (pacalhou), August 28 2006
- Re: Reserved bits and fields Bob O'Hara (boohara), August 28 2006
- Re: Reserved bits and fields Nelson, David, August 28 2006
-
Re: Reserved bits and fields Pat Calhoun (pacalhou), August 28 2006
- Comments on -02 version of capwap spec Puneet Agarwal, August 30 2006
Results generated by Tiger Technologies using MHonArc.