[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



Mauricio,

Thanks for the clarification and for the assurance that this is a one off occasion.

Klaas



On Jul 13, 2011, at 8:05 PM, "Sanchez, Mauricio (HP Networking)" <mauricio.sanchez@hp.com> wrote:

> Klaas,
> Apologies for my lack of response as I have been taking some time off these last couple of weeks and I've clearly let RADEXT fall through the cracks.  As I stated in my response to Dave, this situation was discussed between the chairs and AD and we all agreed that we could move forward in this particular instance.  Unless guidance differs from the AD, I've taken note that in future discussions we should not be as tolerant of non-standard comments.  
> 
> As for the flash mob effect, I've been in IETF long enough to see it happen.  They do happen and will continue to happen. It's the nature of our business.  However, I fully agree with you that crystal clear transparency and timeliness is necessary.   You have my commitment moving forward. 
> 
> BTW, the official minutes for IETF 80 RADEXT state that you had no opinion on this IANA request, so at least from the minutes there's no clear indication of your approval or disapproval.  In hindsight, Bernard and I should have done a hum poll or such during the meeting. 
> 
> -MS 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Klaas Wierenga [mailto:klaas@wierenga.net] 
> Sent: Monday, July 11, 2011 7:24 AM
> To: Dave Nelson
> Cc: Romascanu, Dan (Dan); Alan DeKok; 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
> 
> -----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/>