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

[Klaas Wierenga <klaas@wierenga.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dave,

> 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.

true, and the unwillingness of the chair to respond to critique and
questions...

> 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.

ehm, I am not so sure about that. The request address is *not* a public
address, and as such is different from the radext mailing list or a
statement at the IETF meeting. If the chair can at his discretion pull
out extra votes (why was my objection for example not noted, after all
it is in the minutes of the IETF meeting?)

> 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

I don't mind letting it slide, if you read my earlier message, I just
asked Mauricio to in the future refrain from these practises and at the
very least forward the messages prior to the close of the call (hey, I
might want to organize my own "flash mob" if that is the new style ;-)
I was willing to put this on the chairs inexperience, and a simple
apology and promise not to use these shady tactics in the future would
have made me perfectly happy. Our chair however decided to completely
ignore any voices of concern. I find that rather insulting to those that
do show up at the meetings and discuss on the mailing list.

> 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.

Indeed

Klaas

> 
> Regards,
> 
> Dave
> 
> David B. Nelson Sr. Software Architect Elbrys Networks, Inc. 
> www.elbrys.com <http://www.elbrys.com> +1.603.570.2636

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4bB3kACgkQH2Wy/p4XeFK4zgCgjAQfRf1q9EOPRRZouXrUhBQk
9zUAoMFJbQuKDvcbVwbBdsOtuZbw8lNi
=Zvi3
-----END PGP SIGNATURE-----

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>