Subject: [Capwap] New Issue 138: Inconsistent values for enable/disable in section 4.6.34

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 1 Jul 2008 13:05:14 -0700

All,

Yong has raised another issue, but I'm not sure that this one will have
the required
consensus as it will break compatibility with existing implementations
that conform to
-10.

Section 4.6.34 uses 1 for disable and 2 for enable, while the rest of
the spec uses the
inverse. This inconsistency could be confusing for people using
#DEFINEs. Is there
agreement to inversing these values, with the understanding that it
would create a
backward compatibility issue with -10?

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 6 Jul 2008 09:33:58 -0400

Personally, I am a bit queasy about the idea of swapping these values  
in a new version of the draft.  However, I agree that the current  
situation is far from ideal...

So, I do support this change, but I wish we could come up with a  
better answer.

Margaret

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 6 Jul 2008 17:57:12 +0200

I missed this. I agree with Yong's comment. I support the change with
all inconvenience caused to existing implementations. 

Dan

> -----Original Message-----
> From: Margaret Wasserman [mailto:[email-masked]] 
> Sent: Sunday, July 06, 2008 4:34 PM
> To: Pat Calhoun
> Cc: [email-masked]
> Subject: Re: [Capwap] New Issue 138: Inconsistent values for 
> enable/disablein section 4.6.34
> 
> Personally, I am a bit queasy about the idea of swapping 
> these values in a new version of the draft.  However, I agree 
> that the current situation is far from ideal...
> 
> So, I do support this change, but I wish we could come up 
> with a better answer.
> 
> Margaret
> 
> 
> > Yong has raised another issue, but I'm not sure that this one will 
> > have the required consensus as it will break compatibility with 
> > existing implementations that conform to -10.
> >
> > the spec uses the inverse. This inconsistency could be 
> confusing for 
> > people using #DEFINEs. Is there agreement to inversing 
> these values, 
> > with the understanding that it would create a backward 
> compatibility 
> > issue with -10?
> >
> > PatC

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 7 Jul 2008 04:07:48 -0700

Ok, I've gone ahead with the change, which is now consistent with other
uses of enable/disable and looks like:

<text>
4.6.34.  Radio Operational State
[...]
   State:   An 8-bit boolean value representing the state of the radio.
      The following enumerated values are supported:

      0 -  Reserved

      1 -  Enabled

      2 -  Disabled
</text>

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Sunday, July 06, 2008 6:34 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] New Issue 138: Inconsistent values for
enable/disable in section 4.6.34

Personally, I am a bit queasy about the idea of swapping these values in
a new version of the draft.  However, I agree that the current situation
is far from ideal...

So, I do support this change, but I wish we could come up with a better
answer.

Margaret

On Jul 1, 2008, at 4:05 PM, Pat Calhoun (pacalhou) wrote:

> the spec uses the inverse. This inconsistency could be confusing for 
> people using #DEFINEs. Is there agreement to inversing these values, 
> with the understanding that it would create a backward compatibility 
> issue with -10?
>
> PatC