On Wed, Mar 19, 2008 at 10:11:09AM -0700, Dave Crocker wrote:
... the conduct of Nomcom processes tends
towards pretty classic personnel assessment, but with people
typically lacking classic personnel training or experience.
This would be different from a normal election...
Noel Chiappa wrote:
On Wed, Mar 19, 2008 at 10:11:09AM -0700, Dave Crocker wrote:
... the conduct of Nomcom processes tends
towards pretty classic personnel assessment, but with people
typically lacking classic personnel training or experience.
This would be different
On Thu, Mar 20, 2008 at 02:06:12AM -0400, Noel Chiappa wrote:
On Wed, Mar 19, 2008 at 10:11:09AM -0700, Dave Crocker wrote:
... the conduct of Nomcom processes tends
towards pretty classic personnel assessment, but with people
typically lacking classic personnel training
Dave,
As a clarification, the NomCom is a small crucible of
specially-empowered volunteers. The fact that one has to be
a volunteer explicitly makes it the case that self-selection
is a factor in at least the initial phase.
Hence it is very much the case that people who feel
Lakshminath,
Let me be prefectly frank: if feedback were completely unverifiable
as a result of rigid confidentiality requirements, there would be
nothing to stop someone from making things up. Note that this is -
absolutely - not the same thing as saying anyone in the IETF would
actually take
The random selection process coupled with the relatively small number
of volunteers is an interesting factor in all of this. I have been
selected 3 times (albeit the second time it all fell apart in The
Giant Reset of 2006 :-) and volunteered probably 10 or 15 times.
It's either hard to get on
I think there is a minor ambiguity in the naming draft:
Consequently, unless otherwise
specified, a well-known Kerberos realm name MUST NOT be present in
transited encoding
Who enforces this requirement? That's an important question because
it controls who needs to support the specific
FYI. In WiMAX we derive keys directly from EMSK. We don't use the MOARKs ;-)
It maybe a good idea or a bad idea -- we haven't had a chance to look at it
because we did our stuff before the MOARK was conceived. We did align at one
point with Joe's draft.
I am not sure whether defining a MOARK
Alexey == Alexey Melnikov [EMAIL PROTECTED] writes:
Alexey Hi Sam,
Alexey Sam Hartman wrote:
I find the string MUA meaning anything that happens after
delivery confusing. I'd suggest another string--possibly
POST-MDA and reserve MUA for sieve scripts actually
The random selection process coupled with the relatively small number
of volunteers is an interesting factor in all of this
Nomcom is a group of people randomly selected from among a set of folks
whose only qualifications are that they want to be on nomcom and they like
traveling to
Brian E Carpenter mailto:[EMAIL PROTECTED] scribbled on
Tuesday, March 18, 2008 11:02 PM:
Glen,
On 2008-03-19 04:31, Glen Zorn wrote:
...
Some of us don't subscribe to the IETF list (due to the extremely
poor S/N ratio). Someone did forward me Bernard's original message
to me it
Eric,
Thank you for such a wonderful positive description of the process. I
am sure it will lead to much more participation and volunteer
activity, after all, who doesn't want to travel?
I am particularly pleased to see that you have so many creative
suggestions for alternative ways for
Hi Avi,
I agree that simply removing the MOARK (aka the DSRK) will not prevent
EMSK misuse but it will remove a large temptation to misuse. The sole
purpose I can see in the DSRK is to get around the fact that we do not
export the EMSK. If there are valid reasons to not export the EMSK then
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
While this response may be a bit late, the change in section 5.1
indicating SMTP server discovery now explicitly supports IPv6 address
records represents a significant change from RFC2821.
While a desire to retain current practices has some justification,
extending an already dubious and
Doug,
I'm sorry, but I can't understand what you are talking about.
That is at least in part because you are using vocabulary that
does not appear in 2821bis or other common IETF standardized
email technology. You also seem to be making assumptions that
aren't part of the 2821 model (whether
With one minor concern, I do believe this draft is ready for
publication as a proposed standard. However I think this draft is
fairly rough as proposed standards go; I expect that we will end up
needing a new revision of this spec at some future point that refines
some of the details based on
If in doubt, expand acronyms.
But see also http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
Thanks,
Adrian
Abstract:
Please expand OSPF on first use.
Section 1.3, first paragraph:
Please expand OSPF on first use.
___
IETF
Hi Dan,
I am not a MOARK expert nor a HOAKEY expert. But they way I see it is that
HOAKEY may need to export a root key around yet other applications may not.
Those it is a good idea the the real mother of root keys -- EMSK -- remain in
the EAP layer so it can be used to derive other keys
Of relevance to pleanary/working group/hallway discussions of late.
pdf available here (link to orginal .doc format below)..
http://kingsmountain.com/doc/NEC2007-OHMartin.pdf
(note that due to intra-document references in the original, the .pdf has
spurious numbers interspersed in some of the
[EMAIL PROTECTED] said:
With an opening sentence of:
...
The document does not set a very helpful stage.
Well, .. nevermind.
=JeffH
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Jeff,
With an opening sentence of:
While there appears to be a wide consensus about the fact that the Internet
has stalled or ossified, some would even say that it is in a rapid state of
degeneracy, there is no agreement on a plan of action to rescue the Internet.
The document does not set a
At 10:11 19-03-2008, Dave Crocker wrote:
The current discussion about Nomcom activities has been sufficiently
professional and constructive in tone to prompt me to raise a particularly
delicate point:
Just how realistic is our belief in confidentiality for the process?
Restricting what
On 2008-03-21 08:12, Dave Crocker wrote:
Jeff,
With an opening sentence of:
While there appears to be a wide consensus about the fact that the Internet
has stalled or ossified, some would even say that it is in a rapid state of
degeneracy, there is no agreement on a plan of action to
On Fri, Mar 21, 2008 at 09:45:53AM +1300, Brian E Carpenter wrote:
Well, try reading it before you rush to judgement. I've always
found Olivier's opinions well worth listening too.
I tried reading it, but it is much more descriptive than perscriptive,
and in many places I didn't find a
Doug,
I'm sorry, but I can't understand what you are talking about.
That is at least in part because you are using vocabulary that
does not appear in 2821bis or other common IETF standardized
email technology. You also seem to be making assumptions that
aren't part of the 2821 model
--On Friday, 21 March, 2008 09:03 +1100 Mark Andrews
[EMAIL PROTECTED] wrote:
I think Doug is saying don't let domains with just
records be treated as valid RHS of email. Today we
have to add records to domains with A records to say that
these are not valid RHS
Dear Sir,
Like other members of the multilinguistic working list to which I
belong, since 2002 I received a copy of the mails exchanged between
JFC Morfin and your organization, on IDNs then langtags. And we have
often discussed them. I do not thus ignore big matter of this subject
As JFC Morfin
Ted,
On 2008-03-21 10:32, Theodore Tso wrote:
On Fri, Mar 21, 2008 at 09:45:53AM +1300, Brian E Carpenter wrote:
Well, try reading it before you rush to judgement. I've always
found Olivier's opinions well worth listening too.
I tried reading it,
Thanks...
but it is much more
Total of 180 messages in the last 7 days.
script run at: Fri Mar 21 00:53:01 EDT 2008
Messages | Bytes| Who
+--++--+
9.44% | 17 | 8.34% | 109198 | [EMAIL PROTECTED]
6.67% | 12 | 9.34% | 122392 | [EMAIL
30 matches
Mail list logo
