All of which is why we should limit our attempts to do numerical analysis for
this topic, and worry far more about the basics,
including such things as interaction (in)sensitivities, group tone and style,
and observable misbehaviors, all of which are likely to produce biasing
results.
On 29/04/2013 01:53, Margaret Wasserman wrote:
Hi Tom,
On Apr 19, 2013, at 6:03 AM, t.p. daedu...@btconnect.com wrote:
If we required the IETF to reflect the diversity of people who are,
e.g., IT network professionals, then the IETF would fall apart for lack
of ability.
[…]
If the ADs of the
On 29/04/2013 05:05, Michael StJohns wrote:
At 08:53 PM 4/28/2013, Margaret Wasserman wrote:
The question that people are asking is why the diversity of the IETF leadership
doesn't reflect the diversity of _the IETF_.
Let's consider for a moment that this may not actually be the correct
On 29/04/2013 06:57, Dave Crocker wrote:
On 4/28/2013 10:52 PM, Christian Huitema wrote:
Except that the IESG members select the wg chairs, which makes your
baseline stastistic suspect; it's too easy for all sorts of biasing
factors to sway the allocation of wg chair positions.
Mike actually
Hi,
This new text is OK.
Thanks
Roni
-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com]
Sent: 29 April, 2013 11:26 AM
To: ron.even@gmail.com
Cc: draft-ietf-netmod-interfaces-cfg@tools.ietf.org; ietf@ietf.org;
gen-...@ietf.org
Subject: Re: Gen-ART LC review of
On 4/29/13 12:59 AM, mohamed.boucad...@orange.com wrote:
Robert,
Ted suggested a wording which is better than the one I proposed. I made the
following changes my local copy:
(1)
OLD:
When retransmission is required, the relay may decide to correct the
content of RECONFIGURE-REQUEST
Document: draft-ietf-karp-crypto-key-table-07
Reviewer: David L. Black
Review Date: April 25, 2013
IETF LC End Date: April 29, 2013
Summary: This draft is on the right track, but has open issues
described in the review.
This draft describes a conceptual key database for use by protocols.
It's
Dear Robert,
Thank you for the review.
Please see inline.
Cheers,
Med
De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert
Sparks [rjspa...@nostrum.com]
Date d'envoi : vendredi 26 avril 2013 17:42
À : dh...@ietf.org; ietf@ietf.org;
Robert:
The reason to allow this is that otherwise client A will be unnecessarily
reconfigured many times. (It is also possible that a client might Renew on its
own just as this is happening and thus it can also be removed from the
Reconfigure.)
I think the text should be cleaned up to
Hi,
Thank you for your review. Comments inline.
Roni Even ron.even@gmail.com wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any
Hi,
Roni Even ron.even@gmail.com wrote:
Martin,
Thanks for the response. I am OK with your responses to the nits.
As for the comment on location I think I understand but what got me thinking
was the examples.
In E.1
An operator can configure a new interface by sending an
Here are some quick initial responses to your comments.
Thanks much for the review and I'll follow up with more detail in a
while.
Black, == Black, David david.bl...@emc.com writes:
Black, Major issues:
Black, (Section 2)
Black, [1] LocalKeyName and PeerKeyName are strings.
Thanks for the quick response - most of your message looks reasonable to me.
I have a few additional comments.
[1] Character set for key names, etc.
They are strings that can be compared using binary comparison.
I agree we need to state that in the draft.
That's certainly a reasonable goal,
Robert,
Ted suggested a wording which is better than the one I proposed. I made the
following changes my local copy:
(1)
OLD:
When retransmission is required, the relay may decide to correct the
content of RECONFIGURE-REQUEST message it issues (e.g., update the
Client Identifier
On 4/29/2013 2:15 AM, Stewart Bryant wrote:
On 29/04/2013 06:57, Dave Crocker wrote:
Exactly. Complicated processes, needing high quality data that gets
complicated analysis, that we aren't well-enough trained to do well
and aren't going to be doing.
Dave
Of all the social mixes you would
On Apr 25, 2013, at 2:49 PM, Black, David david.bl...@emc.com wrote:
I have no problem with the field being a binary identifier, but I think
implementers should be put on notice that binary comparison of human input
Unicode strings doesn't work as expected unless some things are done to
make
FYI - Stable storage or some kind of redundancy solution may be another way to
recover state. So, I don't think there is a hard requirement for RFC 5460.
I don't think there is a strong reason to avoid e.g., it is for example so it
is only one of many possible. And such as is basically saying
On Apr 29, 2013, at 10:18 AM, Bernie Volz (volz) v...@cisco.com wrote:
But I don't really see this as a big issue and the must is the lower-case
variant anyway.
There's a big debate about whether this makes any difference. It's generally
thought to be better not to say must if you don't
--On Monday, April 29, 2013 09:55 +0100 Stewart Bryant
stbry...@cisco.com wrote:
The question that people are asking is why the diversity of
the IETF leadership doesn't reflect the diversity of _the
IETF_.
The evidence seems to be that human's are terrible at
guessing
statistics, and
On 4/29/2013 9:38 AM, John C Klensin wrote:
First, our having these
discussions have, I believe, already increased sensitivities to
the issues and maybe even how the community thinks about it.
Actually, it probably hasn't.
It has raised awareness that there are people who are sensitive to
On 4/29/13 1:11 AM, Stewart Bryant wrote:
The other thing to remember is that whilst your proportional estimates
are likely to be correct, in a random process you will get long runs of
bias that only average out in the long run.
Right, although if normal statistical fluctuation gives us
a
Hi Dave,
Thanks for your response. We discussed it within the privacy program and the
full IAB. I've added the following sentence to the end of the intro in section
3 in the pre-publication -09 version:
Examples of several different brief definitions are provided in RFC 4949.
I realize this
--On Monday, April 29, 2013 09:46 -0700 Dave Crocker
d...@dcrocker.net wrote:
On 4/29/2013 9:38 AM, John C Klensin wrote:
First, our having these
discussions have, I believe, already increased sensitivities
to the issues and maybe even how the community thinks about
it.
Actually, it
What a concept.
Irrespectively Yours,
John
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Melinda Shore
Sent: Monday, April 29, 2013 9:52 AM
To: ietf@ietf.org
Subject: Re: IETF Diversity Question on Berlin Registration?
On 4/29/13
On Apr 29, 2013, at 1:08 PM, John C Klensin john-i...@jck.com wrote:
If raising awareness and sensitivity
isn't enough to get people to think about and make decisions
differently
Statistical analysis shows that even when peoples' awareness is raised, biases
continue to exist, not because the
Did anyone notice the NPR piece this AM?
http://www.npr.org/blogs/alltechconsidered/2013/04/29/178810467/blazing-the-trail-for-female-programmers
Perhaps it's time for an IETF equivalent/chapter of
http://railsbridge.org/, http://blackfounders.com/,
http://wisecampaign.org.uk/, etc. ...
Lou
On
At 01:38 PM 4/29/2013, Ted Lemon wrote:
On Apr 29, 2013, at 1:08 PM, John C Klensin john-i...@jck.com wrote:
If raising awareness and sensitivity
isn't enough to get people to think about and make decisions
differently
Statistical analysis shows that even when peoples' awareness is raised,
At 01:34 AM 4/29/2013, Dave Crocker wrote:
On 4/28/2013 9:05 PM, Michael StJohns wrote:
Let's consider for a moment that this may not actually be the correct
question. Instead, consider Why the diversity of the IETF leadership
doesn't reflect the diversity of the set of the IETF WG chairs? I
At 01:57 AM 4/29/2013, Dave Crocker wrote:
including such things as interaction (in)sensitivities, group tone and style,
and observable misbehaviors, all of which are likely to produce biasing
results.
But in which direction?
The same thing could be said of pushing personal or cultural biases
At 12:51 PM 4/29/2013, Melinda Shore wrote:
On 4/29/13 1:11 AM, Stewart Bryant wrote:
The other thing to remember is that whilst your proportional estimates
are likely to be correct, in a random process you will get long runs of
bias that only average out in the long run.
Right, although if
Hi Mike,
On Apr 29, 2013, at 3:15 PM, Michael StJohns mstjo...@comcast.net wrote:
We have an IETF culture - like it or not. It changes over time, as the
population changes. We can't and shouldn't expect to be able to change it by
fiat, or to adopt as whole cloth a bias free culture (for
For what it's worth, I'm not finding the current discussion is providing
me useful information for making decisions. It doesn't really matter to
me whether the problem is selection of WG chairs or selection of
IAB/IESG/IAOC after WG chairs are selected. I think it is valuable to
attempt to
On 29/04/2013 20:39, Sam Hartman wrote:
For what it's worth, I'm not finding the current discussion is providing
me useful information for making decisions. It doesn't really matter to
me whether the problem is selection of WG chairs or selection of
IAB/IESG/IAOC after WG chairs are selected.
At 03:30 PM 4/29/2013, Margaret Wasserman wrote:
Hi Mike,
On Apr 29, 2013, at 3:15 PM, Michael StJohns mstjo...@comcast.net wrote:
We have an IETF culture - like it or not. It changes over time, as the
population changes. We can't and shouldn't expect to be able to change it
by fiat, or
On 4/29/2013 12:04 PM, Michael StJohns wrote:
At 01:34 AM 4/29/2013, Dave Crocker wrote:
Actually, I don't think this is even a mostly correct statement -
that AD select chairs.
It is a long-standing, simple, objective, unvarying management fact of
IETF procedure: ADs hire and fire wg
On Mon, April 29, 2013 12:39 pm, Sam Hartman wrote:
For what it's worth, I'm not finding the current discussion is providing
me useful information for making decisions. It doesn't really matter to
me whether the problem is selection of WG chairs or selection of
IAB/IESG/IAOC after WG chairs
Stewart == Stewart Bryant stbry...@cisco.com writes:
Stewart Why would you disregard a statistical analysis? That seems
Stewart akin to disregarding the fundamentals of science and
Statistical analysis is only useful if it's going to tell you something
that matters for your decision
On 2013-04-29, at 16:49, Sam Hartman hartmans-i...@mit.edu wrote:
Stewart == Stewart Bryant stbry...@cisco.com writes:
Stewart Why would you disregard a statistical analysis? That seems
Stewart akin to disregarding the fundamentals of science and
Statistical analysis is only
On Apr 29, 2013, at 4:55 PM, Joe Abley jab...@hopcount.ca wrote:
On 2013-04-29, at 16:49, Sam Hartman hartmans-i...@mit.edu wrote:
Stewart == Stewart Bryant stbry...@cisco.com writes:
Stewart Why would you disregard a statistical analysis? That seems
Stewart akin to disregarding
If anyone wishes to see one aspect of what is wrong with IETF Diversity,
then see whats going on in SPF BIS WG where a key IETF cog essentially
attempts to shutdown discussions and communications, attacks posters
which by my estimate were making progress.
Progress is a status quo - DON'T
On 4/29/2013 2:20 PM, Michael StJohns wrote:
At 04:40 PM 4/29/2013, Dave Crocker wrote:
Actually, I don't think this is even a mostly correct statement -
that AD select chairs.
It is a long-standing, simple, objective, unvarying management fact of IETF
procedure: ADs hire and fire wg
From: m...@sap.com (Martin Rex)
DRM system are evil in any way you look at it.
Originally, copyright was a conceived as a temporary (50yrs) monopoly.
The protection period has in recent years been prolonged in many years
to at least 70 years.
[...]
I read an analysis somewhere that
On Mon, April 29, 2013 2:28 pm, Dave Crocker wrote:
On 4/29/2013 2:20 PM, Michael StJohns wrote:
At 04:40 PM 4/29/2013, Dave Crocker wrote:
Actually, I don't think this is even a mostly correct statement -
that AD select chairs.
It is a long-standing, simple, objective, unvarying management
The really annoying thing is that SPF is techically superior
to TXT is lots of ways.
1. It uniquely identifies the roll of the record.
2. As SPF records are singletons you don't need to identify
and remove the old record when updating. You can just
So, this page: http://www.ietf.org/iesg/members.html still has TBD listed
for one of the transport ADs. Is there a projected date for appointment at
this point?
Forgive the broad distribution of the question, but it's not clear whether
this question is solely directed at the nomcom, the IESG,
Mike:
Actually, I don't think this is even a mostly correct statement -
that AD select chairs.
Dave:
It is a long-standing, simple, objective, unvarying management fact of
IETF procedure: ADs hire and fire wg chairs.
Mike:
The AD's do have the final say. No question. But select implies
Hi Hector,
At 14:15 29-04-2013, Hector Santos wrote:
If anyone wishes to see one aspect of what is wrong with IETF
Diversity, then see whats going on in SPF BIS WG where a key IETF
cog essentially attempts to shutdown discussions and communications,
attacks posters which by my estimate were
On 30/04/2013 08:49, Sam Hartman wrote:
...
Statistical analysis is only useful if it's going to tell you something
that matters for your decision criteria.
Yes. And I would like to know, in statistical terms, whether
there are significant differences between (for example) the
M/F ratios among
Brian == Brian E Carpenter brian.e.carpen...@gmail.com writes:
Brian The null hypothesis would be that no significant differences
Brian exist. If that turns out to be true, we know that our
Brian problem is only lack of diversity among registrants. If it
Brian turns out to be
retransmited (not received at IETF or published)
On 4/29/13, Abdussalam Baryun abdussalambar...@gmail.com wrote:
Hi Mike,
(sorry for my long message, will try to improve)
I like the concept and reasoning of your message, and would like to
add, is there other reasons for the results and
The IESG has received a request from the Forwarding and Control Element
Separation WG (forces) to consider the following document:
- 'Interoperability Report for Forwarding and Control Element Separation
(ForCES)'
draft-ietf-forces-interop-07.txt as Informational RFC
The IESG plans to make
A new IETF working group has been formed in the Applications Area. For
additional information please contact the Area Directors or the WG
Chairs.
IMAP QRESYNC Extension (qresync)
Current Status: Proposed Working Group
Chairs:
Dave Cridland
A new Request for Comments is now available in online RFC libraries.
RFC 6909
Title: IPv4 Traffic Offload Selector Option
for Proxy Mobile IPv6
Author: S. Gundavelli, Ed.,
X. Zhou, J. Korhonen,
A new Request for Comments is now available in online RFC libraries.
RFC 6911
Title: RADIUS Attributes for IPv6 Access
Networks
Author: W. Dec, Ed.,
B. Sarikaya,
G. Zorn, Ed.,
A new Request for Comments is now available in online RFC libraries.
RFC 6925
Title: The DHCPv4 Relay Agent Identifier
Sub-Option
Author: B. Joshi,
R. Desetti,
M. Stapp
Status:
A new Request for Comments is now available in online RFC libraries.
RFC 6926
Title: DHCPv4 Bulk Leasequery
Author: K. Kinnear, M. Stapp,
R. Desetti, B. Joshi,
N. Russell, P. Kurapati,
B. Volz
A new Request for Comments is now available in online RFC libraries.
RFC 6928
Title: Increasing TCP's Initial Window
Author: J. Chu, N. Dukkipati,
Y. Cheng, M. Mathis
Status: Experimental
Stream: IETF
The IESG has approved the following document:
- 'FCAST: Object Delivery for the ALC and NORM Protocols'
(draft-ietf-rmt-fcast-08.txt) as Experimental RFC
This document is the product of the Reliable Multicast Transport Working
Group.
The IESG contact person is Martin Stiemerling.
A URL of
A new Request for Comments is now available in online RFC libraries.
RFC 6886
Title: NAT Port Mapping Protocol (NAT-PMP)
Author: S. Cheshire, M. Krochmal
Status: Informational
Stream: Independent
Date: April 2013
A new Request for Comments is now available in online RFC libraries.
RFC 6887
Title: Port Control Protocol (PCP)
Author: D. Wing, Ed.,
S. Cheshire, M. Boucadair,
R. Penno, P. Selkirk
Status: Standards
A new Request for Comments is now available in online RFC libraries.
BCP 127
RFC 6888
Title: Common Requirements for Carrier-Grade NATs
(CGNs)
Author: S. Perreault, Ed.,
I. Yamagata, S. Miyakawa,
A new Request for Comments is now available in online RFC libraries.
RFC 6889
Title: Analysis of Stateful 64 Translation
Author: R. Penno, T. Saxena,
M. Boucadair, S. Sivakumar
Status: Informational
Stream:
62 matches
Mail list logo
