[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request



As I stated in my previous message, this situation of incorrect list address usage was discussed between the chairs and the AD.  Given the fact that this proposal had been languishing for some time, that the request wasn’t an egregious violation of RADIUS, alternatives would require a new attribute, industry was waiting for an answer from RADEXT, the chairs and AD felt that we could proceed forward in counting these non-standard votes of approval.  There are times to be pedantic and times where we should not be, and so we made the call to let this one “slide”.

 

Unless the AD has different guidance, I intend to be stricter in future instances and not let non-standard votes be considered.

 

-MS

 

 

 

From: Dave Nelson [mailto:dnelson@elbrys.com]
Sent: Monday, July 11, 2011 6:45 AM
To: Romascanu, Dan (Dan)
Cc: Alan DeKok; Klaas Wierenga; Sanchez, Mauricio (HP Networking); radiusext@ops.ietf.org
Subject: Re: APPEAL: Re: Conclusion of RADEXT WG call for consensus poll for IANA #409959 NAS-Port-Type value request

 

On Mon, Jul 11, 2011 at 5:55 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:


>    All appeals must include a detailed and specific description of the
>    facts of the dispute.

 

It appears to me that the only thing that is in dispute is the process issue of accepting comments not properly received on the RADEXT WG email list, and forwarded to the list as part of the decision announcement.

 

Now, it's true that old-time IETF'ers tend to disdain "flash mob voting", meaning a flurry of postings from individuals outside the WG core membership, at the behest of the proponent of a particular proposal.  That appears to have been the case here, and explains why postings were sent to the "request" address, rather that the list itself.  However, I don't believe that this form of input is officially distinguished from any other form input under the IETF process.

 

What's been demonstrated is that there are numerically more supporters of this particular proposal outside the core RADEXT WG (or IETF) than opponents to it inside the core RADEXT WG.  Given that this proposal have been languishing for quite some time, perhaps we need to let it slide.  While I agree that the usage in this proposal not good RADIUS "form", the suggested alternatives all require the specification of a new RADIUS attribute.  That would have been a good path to follow when the reuest was initially presented.

 

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636