date:20130429

> "Brian" == Brian E Carpenter  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 false, we know that we have an internal
Brian> problem of some kind as well.

Yes.
I'll admit that that particular question--which is far more involved
than the numbers I've seen thrown around to date--is somewhat
interesting.

Although while it influences how I'd think about deciding on proposals,
there's no answer to that question that has a clear set of decisions for
me, even ignoring questions about methodology, definitions of
participants, etc, etc.

1) I may believe that increasing diversity among leadership so that the
leadership is more diverse than the population as a whole will help
increase diversity of the population.

2) I may believe that the diversity of the leadership  is more of a
problem in terms of either quality of spec or credibility of
organization than diversity of the participants/registrants.

But you've definitely started to get into a realm where the statistics
are more interesting to me.
And i'll drop this now, because I realize I'm only one participant and I
discussion that doesn't provide helpful information for me may well
provide useful information for others.

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Brian E Carpenter

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 (a) IETF registrants, (b) active participants,
(c) WG chairs & secretaries and (d) I* members.

[Discussion on the objective definition of active participation
is deferred for now.]

The null hypothesis would be that no significant differences exist.
If that turns out to be true, we know that our problem is only lack of
diversity among registrants. If it turns out to be false, we know
that we have an internal problem of some kind as well.

   Brian

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

2013-04-29 Thread S Moonesamy


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


Progress is a status quo - DON'T CHANGE THE RFC4408 SPECIFICATION in SPFBIS.

Many in DNS community do not agree with the change of removing a 
long term migration path to a SPF RRTYPE.  In fact, not changing the 
existing specification would end the issue and hopefully satisfy all 
principles.


The following messages were posted to the SPFBIS mailing list:

http://www.ietf.org/mail-archive/web/spfbis/current/msg03593.html
http://www.ietf.org/mail-archive/web/spfbis/current/msg03598.html

It has also been mentioned that there are two long threads at:

http://www.ietf.org/mail-archive/web/spfbis/current/msg03412.html
http://www.ietf.org/mail-archive/web/dnsext/current/msg13025.html

Regards,
S. Moonesamy

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Barry Leiba

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
>>> that the own the entire process of creating and staffing a WG. Nope.

Dave:
>> They do "own" it; that's a formal truth.
>>
>> That they often delegate details and concur with self-organizing choices
>> means nothing, in terms of their authority.

Dan:
> But it might mean something in terms of the discussion at hand. If the
> ADs are concurring with self-organizing choices as opposed to selecting
> WG chairs, then they aren't really imposing a "looks like me" bias into
> the selection process.

OK, here: I have to step in now.
Let me look at the new working group chairs and BoF chairs in the App
Area (as that's my area) since I've been an AD (one year, so far).

Chair changes:
APPSAWG: added Murray Kucherawy and Salvatore Loreto
CORE: added Andrew McGregor
IRI: added Peter Saint-Andre

New working groups
WEIRDS: Olaf Kolkman and Murray Kucherawy
SCIM: Morteza Ansari and Leif Johansson
SPFBIS: SM and Andrew Sullivan
IMAPMOVE: Ned Freed and Alexey Melnikov
JCARDCAL: Bert Greevenbosch and Peter Saint-Andre
QRESYNC: Dave Cridland and Eliot Lear

BoFs at IETF 83:
SCIM: Eliot Lear and Steve Bellovin
WEIRDS: Andrew Sullivan

BoFs at IETF 84:
DSII: Beth Pale and Ted Hardie

BoFs at IETF 86:
AGGSRV: Peter Saint-Andre
JSON: Joe Hildebrand

In all but one of these cases, we (the ADs) contacted people and
*asked* them to chair.  The exception was DSII and Beth Pale, but this
was not a working-group-forming BoF (and Ted was the one we
solicited).  For the SCIM working group, Morteza was one of the
proponents of the IETF 83 BoF, but he did not ask to be chair, and *I
asked him* only after consulting with folks and getting opinions that
suggested that he would be a good choice.  That has generally been my
approach and Pete's to finding chairs: getting opinions other than our
own.

We have a couple of other new chartering efforts in process, and we'll
be handling those similarly: selecting people we think will be
appropriate to chair those working groups.

Of course, if someone comes to us and says that they'd like to chair a
working group, we will take that into consideration.  But we most
certainly do NOT simply appoint people because they're technology
proponents, nor because they ask us to.  My sense of the rest of the
IESG is that they behave similarly.

I can tell you unequivocally that the ADs appoint the chairs, and "own
the entire process of [...] staffing a WG".  We are not just taking
the people who come to us and saying, "Yeah, sure, you'll do."  We
also want to find new chairs -- in the working-group chairs list
above, Andrew, Morteza, SM, Bert, and Dave are all first-time chairs.

Pete and I are also actively looking to increase the diversity in App
Area chairs -- perhaps you'll notice that we have *no* female chairs
in the App Area, at least partly because we have no women who are
active in the App Area just now.  We're working on that (and on other
diversity aspects) -- see, for example, the first item here:
http://www.ietf.org/proceedings/85/slides/slides-85-apparea-0.pdf

We're always eager for suggestions for people to be on our list of
potential chairs; please send such to .  And,
yes, we *do* own the staffing process.

Barry, Applications AD

Do we have an estimated date for completing the IESG selection process for this year?

2013-04-29 Thread Ted Hardie

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, the IAB or the
community at large.

regards,

Ted Hardie

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

2013-04-29 Thread Mark Andrews


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
   remove all SPF record and add the replacement.

   For TXT you need to lookup the existing RRset, extract
   the v=spf1 record from it.  You then need to create a
   UPDATE message to delete just that record as well as add
   the new TXT record.   You then have to hope that no one
   else is performing a simultanious update as you may get
   two TXT v=spf1 records in the RRset.

The complains about using SPF is that there are broken
firewalls and some servers drop queries for it, some registars
don't support it.

For firewalls, fix/replace the firewall if you intend to
deploy SPF and it doesn't support it.  It is total !@##@#
that firewall are incapable of handling new DNS record
types.  New records we exected to occur from the very
beginning and have been coming out regularly ever since the
DNS was invented.  Firewall vendors that are incapable of
handling new DNS types are incompetent and do not deserve
repeat business.

For servers than drop SPF queries they really are at the
noise level.  When you identify one you complain to the
owners of it.  Yes, that does work.  We needed to do that
for  records.

For registrars, change registrar to one that does.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Dan Harkins


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 fact of
>>> IETF procedure:  ADs hire and fire wg chairs.
>>
>> The AD's do have the final say.  No question.  But  "select" implies
>> that the own the entire process of creating and staffing a WG. Nope.
>
> They do "own" it; that's a formal truth.
>
> That they often delegate details and concur with self-organizing choices
> means nothing, in terms of their authority.

  But it might mean something in terms of the discussion at hand. If the
ADs are concurring with self-organizing choices as opposed to selecting
WG chairs, then they aren't really imposing a "looks like me" bias into
the selection process.

  Dan.

Re: W3C standards and the Hollyweb

2013-04-29 Thread Dale R. Worley

> 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 pointed out that DRM is evil in
considerably different ways than one naively thinks.  You tend to
think of DRM as a way of enforcing copyright.  But the real power of
DRM is in effectively eliminating the "right of first sale".

Currently, once you've bought a copy of a copyrighted work, you have
bought a physical object, the "copy", and that ownership gives you a
bundle containing a considerable number of rights, including the right
to sell the copy to someone else.

The real economic purpose of DRM is to be able to subdivide the bundle
of rights traditionally associated with the "copy" so that they can be
sold and priced individually.  Even better, since the "copy" may no
longer be transferrable between customers, different customers can be
charged different prices for the same thing.

The net effect is that the work creators can get larger aggregate
sales for the creation than before.  Which may or may not be a good
thing.  Wikipedia has a long article, "Price discrimination", on this.

Dale

Re: IETF Diversity Question on Berlin Registration?


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


The AD's do have the final say.  No question.  But  "select" implies that the 
own the entire process of creating and staffing a WG. Nope.



They do "own" it; that's a formal truth.

That they often delegate details and concur with self-organizing choices 
means nothing, in terms of their authority.


Don't confuse efficiency hacks with formal authority.


d/

ps. I'm sure this was really quite an important point to debate, 
relative to problems with IETF diversity and culture.


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: IETF Diversity Question on Berlin Registration?

At 04:40 PM 4/29/2013, Dave Crocker wrote:
>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 chairs.

The AD's do have the final say.  No question.  But  "select" implies that the 
own the entire process of creating and staffing a WG. Nope.



>>Second point:
>>
>>You ignored most of the post and went directly to my last question
>
>I went to the meta-point that 

[Dave Crocker believes that]

>the line of discussion isn't methodologically meaningful or educationally 
>useful.  Possibly you noticed one or two additional postings in this 
>sub-thread asserting the same thing.

And one or two actually considering whether or not there was something to be 
gleaned from such data.

I'll take your opinion under advisement.  Thanks.

Mike



>d/
>
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

2013-04-29 Thread Hector Santos

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 CHANGE THE RFC4408 SPECIFICATION in 
SPFBIS.


Many in DNS community do not agree with the change of removing a long 
term migration path to a SPF RRTYPE.  In fact, not changing the existing 
specification would end the issue and hopefully satisfy all principles.


--
HLS

On 4/29/2013 5:03 PM, Dave Crocker wrote:

Folks,

This is one of those threads that will go on for as long as people seem
to think they need to keep posting, but it won't make any "progress" or
resolve any issues.

For that matter, I have no idea what anyone thinks they are
accomplishing by continuing to post on it, which raises the question of
why they keep bothering.

And 'bothering' is what this thread mostly /is/ doing, in reducing the
S/N ratio.

Please shut the thread down.

d/

Re: [IETF] Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Warren Kumari


On Apr 29, 2013, at 4:55 PM, Joe Abley  wrote:

> 
> On 2013-04-29, at 16:49, Sam Hartman  wrote:
> 
>>> "Stewart" == Stewart Bryant  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 criteria.
> 
> http://i.imgur.com/47D7zGq.png

Wow, that *was* useful, and has helped reinforce my belief that I chose the 
right browser -- "Think of the children, don't use IE."

Couldn't resist: http://xkcd.com/552/

W



> 
> 
> Joe
> 

--
There were such things as dwarf gods. Dwarfs were not a naturally religious 
species, but in a world where pit props could crack without warning and pockets 
of fire damp could suddenly explode they'd seen the need for gods as the sort 
of supernatural equivalent of a hard hat. Besides, when you hit your thumb with 
an eight-pound hammer it's nice to be able to blaspheme. It takes a very 
special and straong-minded kind of atheist to jump up and down with their hand 
clasped under their other armpit and shout, "Oh, 
random-fluctuations-in-the-space-time-continuum!" or "Aaargh, 
primitive-and-outmoded-concept on a crutch!"
  -- Terry Pratchett

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Joe Abley


On 2013-04-29, at 16:49, Sam Hartman  wrote:

>> "Stewart" == Stewart Bryant  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 criteria.

http://i.imgur.com/47D7zGq.png


Joe

Re: IETF Diversity Question on Berlin Registration?

> "Stewart" == Stewart Bryant  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 criteria.

Let's take Mike's most recent messages here.  It doesn't actually matter
to me whether the problem in gender diversity is at the nomcom level or
at the wg chair selection level.
So, a statistical discussion of whether there's bias in nomcom choosing
leaders from the wg chairs does not provide input that matters in my
decision criteria, so I disregard that particular analysis.

I certainly did not mean to imply that I disregard statistics, or even
disregard statistics in diversity discussions.  Simply, I don't find the
statistical discussion here pointful, and I think it's a sufficient
distraction that I felt a need to speak out about it.

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Dan Harkins

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 are selected.  I think it is valuable to
> attempt to improve both situations in parallel, and the sorts of
> conclusions being drawn from the statistical discussion we're currently
> having cannot possibly change my opinion on that issue.
>
> I'm not saying that my mind is closed to being changed; simply that I've
> considered all the possible conclusions that I think could be drawn from
> the analysis being considered and from my standpoint they don't affect
> how I'd feel about various proposals that could be brought forward.

  Sounds to me like you have the cart in front of the horse. You already
have in mind various proposals (interestingly left unstated) and are looking
for data that can justify them being brought forward. Apparently, this data
does not help you justify these proposals so you find no use discussing in
it. Maybe we should let the data drive the proposals instead of the other
way around.

  Dan.

Re: IETF Diversity Question on Berlin Registration?


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





Second point:

You ignored most of the post and went directly to my last question


I went to the meta-point that the line of discussion isn't 
methodologically meaningful or educationally useful.  Possibly you 
noticed one or two additional postings in this sub-thread asserting the 
same thing.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

How does the IETF evolve to continue to be an effective, efficient, and relevant source of high quality Internet standards? Was: Re: IETF Diversity Question on Berlin Registration?

At 03:30 PM 4/29/2013, Margaret Wasserman wrote:

>Hi Mike,
>
>On Apr 29, 2013, at 3:15 PM, Michael StJohns  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 some values of 
>> bias).
>
>
>How you do you think a culture evolves to be more inclusive?  Might that start 
>with discussions like these?

I believe your statement implies some preconceptions - that you believe the 
IETF culture is not inclusive enough and that more inclusiveness will benefit 
the IETF.  I'm not sure there's evidence to support the first - hence the 
numerical analysis.   It may be the case that "we're not inclusive enough" is a 
correct evaluation, but see Stewart's note on the human tendency to impute 
patterns into random results.

I would ask this instead - "How does the IETF evolve to continue to be an 
effective, efficient, and relevant source of high quality Internet standards?"

If one of the answers to that question necessarily involves inclusiveness, then 
the conversation should go forward on that topic, but preferably not in 
isolation, not as the "fix this now" knee jerk (my perception) type of activity 
that seems to be going on.

Let me ask a couple of specific questions of you.  

Who have you mentored in the past 5 years?  Have  they ended up as working 
group chairs, or ADs or IAB members?   Do they mostly represent 
under-represented groups?  How many of them were employed by your employer 
(e.g. was this a work related task?)?

During your time as an AD, how many women did you arm twist/recruit 
specifically  (or ask nicely) to take WG positions in your area (as opposed to 
them coming to you or your co-AD)?  

How many non-employee, under-represented population attendees is your current 
employer supporting to go to the IETF?  Have you addressed this with your 
employer?

Why is the inclusiveness question more of an IETF question, as opposed to one 
of personal actions?

I'm asking the above, because I'm trying to get a calibration on what you mean 
by inclusiveness and how important it actually is for you, and possibly for 
your employer.

Mike

>Margaret

Re: IETF Diversity Question on Berlin Registration?


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.  I think it is valuable to
attempt to improve both situations in parallel, and the sorts of
conclusions being drawn from the statistical discussion we're currently
having cannot possibly change my opinion on that issue.

I'm not saying that my mind is closed to being changed; simply that I've
considered all the possible conclusions that I think could be drawn from
the analysis being considered and from my standpoint they don't affect
how I'd feel about various proposals that could be brought forward.

Which I guess speaks to John's point that I at least am a member of the
community who doesn't think the hard statistical analysis is useful
here.


Sam,

Why would you disregard a statistical analysis? That seems akin to
disregarding the fundamentals of science and engineering.

Stewart

Re: IETF Diversity Question on Berlin Registration?

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 improve both situations in parallel, and the sorts of
conclusions being drawn from the statistical discussion we're currently
having cannot possibly change my opinion on that issue.

I'm not saying that my mind is closed to being changed; simply that I've
considered all the possible conclusions that I think could be drawn from
the analysis being considered and from my standpoint they don't affect
how I'd feel about various proposals that could be brought forward.

Which I guess speaks to John's point that I at least am a member of the
community who doesn't think the hard statistical analysis is useful
here.

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Margaret Wasserman


Hi Mike,

On Apr 29, 2013, at 3:15 PM, Michael StJohns  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 some values of 
> bias).


How you do you think a culture evolves to be more inclusive?  Might that start 
with discussions like these?

Margaret

Re: IETF Diversity Question on Berlin Registration?

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 "normal" statistical fluctuation gives us
>a long period of woman-free leadership, somewhere in your long
>run we might expect the same statistical fluctuation
>to deliver unto us a stretch in which women are overrepresented
>in the leadership.

Hi Melinda - 

Actually, look at the time frame around 2004-5.  Multiple women on the IAB and 
multiple women on the IESG.  Almost double the expected value of "2" given the 
WG proportions.  

One of the things I saw, but didn't comment on elsewhere, was that I had noted 
that a number of the women who had participated as IESG or IAB members have 
since stopped participating (attending actually) IETF meetings.  I didn't 
comment on it because I didn't have a good feel for whether that proportion was 
higher or lower than the men who have been IESG/IAB members and are now not 
participating.  Analysis of this might yield some data on whether or not we're 
losing long term female participants at a higher rate than long term male 
participants - if so, it may be worthwhile to ask former members the "why" 
question to see if there's anything we can do to mitigate.  Long term 
participants appear (my opinion) to be more attractive candidates for IAB/IESG 
positions.

Mike

>Melinda

Re: IETF Diversity Question on Berlin Registration?

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 into the 
interpretation of group tone, style, and taking offense at behaviors which one 
culture might construe as offensive but for 50 other cultures is just the way 
things work.  

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 some values of bias).

Mike

Re: IETF Diversity Question on Berlin Registration?

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 believe 
>>this is a more representative candidate population for the IAB and IESG.
>
>
>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.

A couple of points: 

Actually, I don't think this is even a mostly correct statement - that AD 
select chairs.  I believe that most chairs are self-selected [e.g. hey AD, I 
want to run a BOF on this topic with the idea of forming a working group - 
here's the other person who might chair, what do you think?  Sure - go ahead, 
we may twiddle with things a bit at charter formation, but you look like you 
know what you're doing].  With one exception (where I was asked to chair an 
evaluation panel), that's been my experience.

Would you have evidence to the contrary? 

Second point: 

You ignored most of the post and went directly to my last question - 'If there 
is no statistical difference between the IAB/IESG and the WG chair set, should 
we then consider the relationship between the IETF attending constituency and 
the WG chair set?"Say the average meeting had 1500 attendees.  7.4% would 
suggest that there are 111 female attendees.  If the actual number is higher or 
lower it MAY represent a  statistically significant difference in the 
composition of the two groups.  Or it may not.   And even then, may only have a 
very indirect impact in the composition of the IAB/IESG.  Care to do the 
analysis?

Later, Mike

>d/
>
>-- 
>Dave Crocker
>Brandenburg InternetWorking
>bbiw.net

Re: IETF Diversity Question on Berlin Registration?

At 01:38 PM 4/29/2013, Ted Lemon wrote:
>On Apr 29, 2013, at 1:08 PM, John C Klensin  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 people are bad people, but because 
>cognitive biases are simply not affected by "consciousness raising" alone.   
>So IMHO at least, what we are looking for here is not consciousness-raising, 
>but some method of determining if we are indeed suffering from cognitive 
>biases here, and if so, some method for actually addressing the problem.

Yup.  The problem here is that the sample set of "leadership" positions is so 
small its difficult to get any reasonable measure one way or the other.   When 
you start mixing and matching gender, race, citizenship etc into the pot as 
possible determiners it just gets worse.

The normal measure for determining whether one population is distinct from 
another appears to be the Chi Squared test.  

Throwing in a matrix of 

WG Chairs IAB/IESG Members
Male 187 25
Female15 1

And running the calculation (http://www.quantpsy.org/chisq/chisq.htm) using the 
Yates' values (because the sample size is so small), there is a 79.13% chance 
that any observed differences in the composition of the two groups is solely 
due to statistical variations.

And playing off of John's message, if you look around 2005 when there were 4 
female members of the IAB and IESG (and assuming the same composition of WG 
chairs), that calculation yields  something 31.4% - or 2 chances in 3 that the 
differences were due to something other than statistical variations.

When I look at this as a pure numbers problem, I'm unable to say there is a 
cognitive bias in the selection process and in fact the numbers would argue 
against being able to say that without a much larger set of IAB/IESG members.

Mike

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Lou Berger

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 4/29/2013 12:46 PM, Dave Crocker wrote:
> Let's not confuse activity with progress.
>

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Ted Lemon

On Apr 29, 2013, at 1:08 PM, John C Klensin  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 people are bad people, but because cognitive 
biases are simply not affected by "consciousness raising" alone.   So IMHO at 
least, what we are looking for here is not consciousness-raising, but some 
method of determining if we are indeed suffering from cognitive biases here, 
and if so, some method for actually addressing the problem.

RE: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread John E Drake

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 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 long
> period of woman-free leadership, somewhere in your long run we might
> expect the same statistical fluctuation to deliver unto us a stretch in
> which women are overrepresented in the leadership.
> 
> Melinda
> 
>

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread John C Klensin

--On Monday, April 29, 2013 09:46 -0700 Dave Crocker
 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 probably hasn't.
> 
> It has raised awareness that there are people who are
> sensitive to the topic.  It probably has raised some people's
> awareness that there are serious issues here and that the IETF
> ought to pay attention to them (better).
> 
> I seriously doubt it has afforded many folk a sense of how to
> behave differently, and how to evaluate community and
> management choices in terms of diversity concerns.

I am trying (temporarily) to be more optimistic than that, but I
fear that you may be correct.  

If so, we may be in big trouble and/or wasting our time by even
having this discussion.  If raising awareness and sensitivity
isn't enough to get people to think about and make decisions
differently and the only criteria the community will accept for
either the existence of a problem or evidence that progress is
being made is hard, frequency-based, statistical (or statistical
analyses of experimental) data then,

 -- we can quibble endlessly about what should be
measured and what the measurements mean and probably
will, and

 -- we will never agree on quantitative criteria for
progress or adequate diversity because such criteria
will have the odor of preferential treatment and quotas
(whether they are or not).

And that applies not just to selections by the Nomcom but to all
of the selections that are affected by the "select people whom
you know and know can do the job" behavior that has been
discussed at length in another thread.

> Let's not confuse activity with progress.

Indeed.  Let's also try to avoid defining progress in a way that
makes even useful activity impossible.   But, again, I fear you
are correct about all of this.

   john

Re: [IAB] Call for Comment: 'Privacy Considerations for Internet Protocols'

2013-04-29 Thread Alissa Cooper

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 may not fully assuage your concerns, but we thought it might 
help to point out the brief(er) definitions in 4949. Notably, even that 
document gives three different definitions of "privacy" and none of them are a 
single sentence long, reflecting the difficulty of trying to boil down the 
multiple facets of the concept.

To your point about privacy versus security, I'm not sure there is more we can 
say beyond what is in sections 4 and 7.

Thanks for your thorough review. Although we have a few differences of opinion, 
I'm glad that you seem to think the document has value.

Best,
Alissa


On Apr 17, 2013, at 8:15 PM, Dave Crocker  wrote:

> Alissa,
> 
> 
> On 4/17/2013 10:23 AM, Alissa Cooper wrote:
>> Hi Dave,
>> 
>> Just wanted to make sure you saw this. I plan to submit the document
>> to the IAB for publication approval next week.
> 
> 
> hmmm.  I did see it, but now I can't find your original response, which
> is probably why I didn't followup.  So thanks for the re-probe.
> 
> I've left a few snippets from your reply at the end, as basic context,
> but I'll just comment in summary, rather than in-line.
> 
> The summary of the summary is pretty simple:  I do understand the
> history, complexities and even controversy that make it difficult to
> document specific choices, such as defining privacy.  But I submit that
> due diligence for a document like this obligates the IAB to take some
> basic, solid positions, in the service of making its guidance useful.
> 
> 
> 1. Audience
> 
>   We often wind up writing documents that work best for people who are
> already relatively familiar with a topic.  As you know better than most,
> writing for those new to a topic is a significantly different task.  I
> certainly agree that it's challenging but I see it as the essence of
> this draft.
> 
>   That is, I believe you intend this document primarily for those who
> are less familiar with discussion and practice of "privacy"
> considerations.  But this must begin with an understanding that they
> don't really have a reliable, workable definition of the term.
> 
>   There are many different definitions and you note that even on the
> IAB, for this draft, it has been challenging to settle on a definition.
> I'll submit that that should alert you to the increased need for this
> document to offer a single, useful definition, rather than to cause you
> to shy away from it.
> 
> 
> 2. Definition.
> 
>   The alternative that you've left the reader with is to have a basic
> lack of comfort with the topic and a certainty of inconsistent
> definition.  All the good guidance later in the document will depend
> upon an inconsistent sense of when to apply it.
> 
>   In addition, the directive that they derive their version of the
> definition from the detail later in the document is -- forgive me --
> simply unreasonable extra work. It's the sort of thing done for an
> academic texbook, not a guidance document.  This draft is an operational
> tutorial, as well as a set of guidelines.  Tutoring for application
> starts with explaining terms and "privacy" is the most essential term to
> define.
> 
>   The exemplar definition I provided should be modified to cover
> 'organization' data as well as personal, but I think it's viable as a
> working form.  That said, I don't care whether you use it, as long as
> the document provides a meaningful definition that gives the /average/,
> uninformed reader a pragmatic sense of what is inside the scope of
> privacy and what is outside.
> 
> 
> 3. Privacy vs. Security
> 
>   The fact that the two topics overlap or that one can be viewed as a
> subset of the other or that...  The fact that there is so much confusion
> here again requires that the document give concrete guidance that
> distinguishes what is security, as we use it for RFCs, and what is
> privacy, as you intend to scope it for this draft and for future Privacy
> Considerations work.
> 
>   My own view is that Security is largely a technical and mechanical
> topic, while Privacy is primarily a human and social topic.  Within the
> IETF, we deal with security issues primarily in terms of algorithms and
> component technology.  I believe you intend Privacy to take a larger
> view and think that's entirely appropriate, but also quite different.
> 
>   That privacy often plays heavily on the techniques of security does
> present challenges.  But, for example, I think that 'confidentiality' is
> not 'privacy'.  I'll state it differently:  If the IAB cannot agree on a
> meaningful and simple statement that distinguishes between privacy and
> confidentiality, then it ought to reconsider giving expert advice about
> the handling of privacy

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread Melinda Shore

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 long period of woman-free leadership, somewhere in your long
run we might expect the same statistical fluctuation
to deliver unto us a stretch in which women are overrepresented
in the leadership.

Melinda

Re: IETF Diversity Question on Berlin Registration?


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 the 
topic.  It probably has raised some people's awareness that there are 
serious issues here and that the IETF ought to pay attention to them 
(better).


I seriously doubt it has afforded many folk a sense of how to behave 
differently, and how to evaluate community and management choices in 
terms of diversity concerns.


Let's not confuse activity with progress.

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: IETF Diversity Question on Berlin Registration?

2013-04-29 Thread John C Klensin

--On Monday, April 29, 2013 09:55 +0100 Stewart Bryant
 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 the only statistics that are reliable as those
> objectively gathered and subjected to rigorous statistical
> analysis.

I mostly agree with this, but it means that attempts at
statistical measurement of populations we can't really
characterize are irrelevant.  In particular, as soon as one
talks about the "diversity of _the IETF_", one is talking about
the participant population.  There is no evidence at all, and
some evidences to the contrary, that the attendee population is
a good surrogate (approximation to a random sample, if you
prefer) for the participant population.   Making that assumption
by polling or measuring the attendee function and assuming it is
representative of the IETF may introduce far more biases than
most of what we are talking about.

> You can often see this in human assessments of risk. It is
> also in the nature of statistics that you get long runs of
> outliers, and
> that only when you take a long view to you see the averages you
> would expect. Again Humans are terrible with this, assuming
> for example that a coin that comes up heads 10 times in a row
> the assumption is that this is bias, and not a normal
> statistical
> variation that you would expect in an infinite number of
> throws.

On the other hand, as a loyal empirical Bayesian, I suggest
that, if I observe a run of 10 heads and, as a result, bet on
the next toss being heads, I am somewhat more likely to carry
home my winnings at the end of the day that you are if you
continue to bet on a 50-50 chance no matter how long the run
gets... _even_ if the rules are normal statistical variation.
Now, after an infinite number of coin tosses occur, you may be
proven correct, but part of the reason for that Bayesian
judgment (or a judgment based on moving average properties of
the time series) is that few of us are going to be able to wait
for that infinite number of tosses. 

> It would be useful to the discussion if we could see data on
> diversity
> that was the output of a rigorous  statistical analysis. i.e.
> one that
> included a confidence analysis and not a simple average in a
> few spot years.

I agree.  But I also suggest that humans are pretty good at
binary comparisons and some longitudinal relationships that do
not involve population samples.  For example, with no effort to
compare the population statistics of the IESG with the
population statistics of the IETF (the precise comparison that
is most susceptible to the statistical problems both of us are
concerned about), it is easy to look at IESG membership
longitudinally and observe that, between the early 1990s and
2010, there were always at least one, and often two or three,
women on the IESG.  Since then, zero.Now, based on around 17
years of moving average, I feel somewhat justified statistically
in believing that something odd is happening.  

I would feel much more justified if we went a couple years more
with no change in our procedures and how we think about things
and the "zero women" trend continued, but that illustrates the
other problems with this sort of analysis and an attempt to base
it on population statistics, especially the population
statistics of experimental design.  First, our having these
discussions have, I believe, already increased sensitivities to
the issues and maybe even how the community thinks about it.  If
we end up with a woman or three on the IESG a year from now, it
will basically be impossible to know whether that was 

-- simply a return to normal behavior after a period of
deviation that could be attributed to statistical
variation or 

-- whether it was because this discussion was
effectively a consciousness-raising exercise that
changed how decisions are made.

The second issue is that, as in a clinical trial in which it
becomes obvious (with all of those subjective human judgments as
well as strict statistical ones) that one of the treatment
groups is doing much better than others, it may be socially and
morally unacceptable to continue the experiment in order to get
cleaner statistical results.

--On Monday, April 29, 2013 06:14 + Christian Huitema
 wrote:

> Certainly useful, but it is easy to inject one's own bias into
> such processes, and to overlook other factors. I may be
> biased, but I have the impression that the largest source of
> bias in IESG selection is the need to secure funding for the
> job, which effectively self-select people working for large
> companies making networking products.

Or at least large companies and mostly those with a significant
stake in the Internet.  I agree with this impression.   In
principle, we could separate gender (or other) bia

Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

2013-04-29 Thread Ted Lemon

On Apr 29, 2013, at 10:18 AM, "Bernie Volz (volz)"  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 mean MUST.

I think the idea of just saying e.g. is the right thing, and stable storage and 
bulk leasequery would be two really great examples to use.

RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

2013-04-29 Thread Bernie Volz (volz)

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 the same thing.

---

But then we come to why this is even important ... The original text was:

   This setup assumes the relay has a record of the client, so that it
   has enough information to send the Reconfigure-Request message to the
   server.  How the state is recorded in the relay is out of scope.
   Furthermore, means to recover state in failure events must be
   supported, but are not discussed in this document.

I'm a bit skeptical why this draft even brings the 'recover state' up. Yes, the 
relay does need to record the client in order to initiate a 
Reconfigure-Request. But I think the sentence "Furthermore, means to recover 
state in failure events must be supported, but are not discussed in this 
document." is not needed. Sure, if the relay has no way of recovering this 
state, traffic to/from clients will likely not work and certainly if the relay 
is reconfigured, it will be unable to generate a Reconfigure-Request. But I 
don't really see this draft needing this requirement. Reconfigure-request could 
still work until the state is lost. And if the state is lost, there is a lot 
more than is potentially broken.

But I don't really see this as a big issue and the "must" is the lower-case 
variant anyway.

- Bernie

-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com] 
Sent: Monday, April 29, 2013 9:45 AM
To: mohamed.boucad...@orange.com
Cc: Bernie Volz (volz); dh...@ietf.org; General Area Review Team; 
ietf@ietf.org; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Subject: Re: [dhcwg] RE : Gen-art review: 
draft-ietf-dhc-triggered-reconfigure-05

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 message it issues (e.g., update the
> Client Identifier list).
>
> NEW:
> The relay MAY remove clients from the client identifier list in
> subsequent retransmissions, but MUST NOT add clients to the client
> identifier list.
>
> (2)
>
> OLD:
> Furthermore, means to recover state in failure events must be
> supported, but are not discussed in this document.
>
> NEW:
> Furthermore, means to recover state in failure events (e.g.,
> [RFC5460]) must be supported, but are not discussed in this document.
>
> Is this better?
1 is better.

2 is an improvement, I might say "such as" instead of e.g. to even more 
strongly avoid someone thinking you are _requiring_ implementation of RFC5460.  
Even then, it's still not clear whether you're trying to say

"Something that doesn't do this is does not conform to this specification"

or

"Something that doesn't do this isn't as good a tool as it can be and may 
create a condition that operators and users will not like much."

You chose not to use MUST in that sentence. Can you make it less likely that 
someone will assume you meant to?
>
> Cheers,
> Med
>
>
>> -Message d'origine-
>> De : Bernie Volz (volz) [mailto:v...@cisco.com] Envoyé : samedi 27 
>> avril 2013 06:24 À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN Cc : 
>> dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- 
>> dhc-triggered-reconfig...@tools.ietf.org
>> Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
>> reconfigure-05
>>
>> 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 indicate that allowing 
>> removal of already reconfigured clients is recommended (to prevent 
>> unnecessary
>> reconfigures) when retransmitting the Reconfigure-Request.
>>
>> Note that if clients are added, that is not a retransmission but 
>> requires a "new" message (new XID).
>>
>> - Bernie
>>
>> -Original Message-
>> From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On 
>> Behalf Of Robert Sparks
>> Sent: Friday, April 26, 2013 12:19 PM
>> To: mohamed.boucad...@orange.com
>> Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; 
>> draft-ietf- dhc-triggered-reconfig...@tools.ietf.org
>> Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
>> reconfigure-05
>>
>> On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:
>>> Dear Robert,
>>>
>>> Thank you for the review.
>>> Please see inline.
>>>
>>> Cheers,
>>> Med
>>> 
>>> De :

Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07

2013-04-29 Thread Ted Lemon

On Apr 25, 2013, at 2:49 PM, "Black, David"  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 it work (this used to be known as string preparation).

+1.

Re: IETF Diversity Question on Berlin Registration?


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 anticipate the IETF to be in the
likely to do it, likely to do it correctly quadrant.



If by 'it', you mean statistical analysis of human behavior, no.  I'd 
expect our group methodology to be exactly as poor at it as we are...


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

2013-04-29 Thread mohamed.boucadair

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

NEW:
   The relay MAY remove clients from the client identifier list in
   subsequent retransmissions, but MUST NOT add clients to the client
   identifier list.

(2)

OLD:
   Furthermore, means to recover state in failure events must be
   supported, but are not discussed in this document.

NEW:
   Furthermore, means to recover state in failure events (e.g.,
   [RFC5460]) must be supported, but are not discussed in this document.

Is this better?

Cheers,
Med


>-Message d'origine-
>De : Bernie Volz (volz) [mailto:v...@cisco.com]
>Envoyé : samedi 27 avril 2013 06:24
>À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN
>Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
>dhc-triggered-reconfig...@tools.ietf.org
>Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
>reconfigure-05
>
>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 indicate that allowing removal of
>already reconfigured clients is recommended (to prevent unnecessary
>reconfigures) when retransmitting the Reconfigure-Request.
>
>Note that if clients are added, that is not a retransmission but requires a
>"new" message (new XID).
>
>- Bernie
>
>-Original Message-
>From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of
>Robert Sparks
>Sent: Friday, April 26, 2013 12:19 PM
>To: mohamed.boucad...@orange.com
>Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
>dhc-triggered-reconfig...@tools.ietf.org
>Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
>reconfigure-05
>
>On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:
>> 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; General Area Review
>> Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
>> Objet : [dhcwg] Gen-art review:
>> draft-ietf-dhc-triggered-reconfigure-05
>>
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>>
>>
>.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-dhc-triggered-reconfigure-05
>> Reviewer:  Robert Sparks
>> Review Date: April 26, 2013
>> IETF LC End Date: May 6, 2013
>> IESG Telechat date: May 16, 2013
>>
>> Summary: This draft is on the right track but has open issues, described
>in
>>the review.
>>
>> Major issues:
>>
>> Overall, this document is solid, but I think there is a bug in section
>6.3.
>> I could be wrong, but If I'm right, this paragraph:
>>
>> When retransmission is required, the relay may decide to correct the
>content of RECONFIGURE-REQUEST message it issues (e.g., update the Client
>Identifier list).  This decision is local to the relay (e.g., it may be
>based on observed events such as one or more clients were reconfigured on
>their own).
>>
>> introduces a race-condition that could lead to an erroneous state. If a
>relay's first message included client A, then the retransmission included
>clients A and B, but that retransmission crosses with a success
>RECONFIGURE-REPLY to the request that only included client A, the relay
>will think it succeeded in asking A and B to be reconfigured.
>>
>> Med: This example does not apply for that text.
>Really? What text constrains how you change what's in the retransmission?
>>   In fact, the example should be the other way around. Perhaps, this can
>be made clearer if we change "(e.g., update the Client Identifier list)" to
>"(e.g., remove a client from the Client Identifier list)".
>If I understand you correctly, you need more than just changing a
>parenthetical e.g.. I think you're saying that you are constraining the
>message changes to be such that if anything earlier in the retransmission
>sequence succeeded, the request in the retransmission would also have
>succeeded. But why do you need that much complexity? Do you have it already
>with any other request?
>>
>> Minor issues:
>>
>> This sentence:
>>
>> Furthermore, means to recover state in failure events must be supported,
>but are not discussed in this document.
>> places a requ

RE: Gen-ART review of draft-ietf-karp-crypto-key-table-07

2013-04-29 Thread Black, David

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, and there are plenty of examples of
protocols that do that.  OTOH, when the character set is Unicode, generating
strings for which that binary comparison for equality works as expected has
a number of subtleties when the strings are input by humans.  Pete Resnick
and yours truly are among the people familiar with the "dragons" that lurk
here (and the precis WG is grappling with).

> We needed to add the entire complexity of making these fields be strings
> not integers because of some non-IETF protocols that use key names.
> 
> I'm reasonably confident I can sell Pete on the concept of a binary
> identifier for this field from an i18n standpoint.

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 it work (this used to be known as string preparation).  A warning
to that effect, perhaps citing a reference for details on what can go awry,
accompanied by making the protocol spec responsible for getting this right
ought to suffice.

[3] Protocol responsibility to specify interface format

> We
> mandate that you must be able to tie things to interface. However the
> format of an interface is quite specific to the routing platform in
> question.

Ok, I suggest explaining that as part of a statement that a protocol cannot
in general be expected to specify interface formats that apply across all
implementations due to implementation diversity.

[7] Additional format information in registry

> Black,> [7] Should some sort of formats for Peers and Interfaces be
> Black,> included in registering a Protocol?  If not, the lookups in
> Black,> section 3 may be implementation-dependent (strings that work
> Black,> w/one implementation may not work w/other implementations of
> Black,> the same protocol).  The specification reference may suffice
> Black,> based on the requirements in section 4 for what has to be in
> Black,> each referenced specification.
> 
> When you register a protocol you need to point to a specification that
> gives details on this sort of thing.

That makes sense, and section 4's requirements on the specifications 
cover this area, but I thought I'd ask.

[9] Registry policy

> As an individual, I support FCFS, because I think getting expert
> approval for some of the uses that have been proposed for these
> registries will be challenging.

The two registries involved are for KDFs and cryptographic algorithm 
identifiers.

This feels like something that the security area ought to weigh in on, as it
looks like it includes the "vanity crypto" discussion tarpit ;-).  At a minimum,
I would think that there ought to be some means of prohibiting registration
of a crypto algorithm like ROT13 (http://en.wikipedia.org/wiki/ROT13).

Thanks,
--David

> -Original Message-
> From: Sam Hartman [mailto:hartmans-i...@mit.edu]
> Sent: Thursday, April 25, 2013 12:47 PM
> To: Black, David
> Cc: Russ Housley; tim.p...@nist.gov; zhangdach...@huawei.com; gen-
> a...@ietf.org; k...@ietf.org; ietf@ietf.org; 
> Subject: Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07
> 
> 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  writes:
> 
> 
> Black,> Major issues:
> 
> Black,> (Section 2)
> 
> Black,> [1] LocalKeyName and PeerKeyName are strings.  What
> Black,> character set?  If Unicode (e.g., UTF-8?), add text on
> Black,> Unicode considerations (e.g., normalization).  Finding a
> Black,> Unicode expert will help in getting this done quickly.  I
> Black,> have similar concerns for other strings, and in particular,
> Black,> IANA should be told what a "string" is for any registry
> Black,> field that contains one.
> 
> They are strings that can be compared using binary comparison.
> I agree we need to state that in the draft.
> Character set, to the extent it is specified will be specified by the
> individual protocol.
> In practice the protocol will say  that it's an integer represented as
> an ASCII string.
> 
> We needed to add the entire complexity of making these fields be strings
> not integers because of some non-IETF protocols that use key names.
> 
> I'm reasonably confident I can sell Pete on the concept of a binary
> identifier for this field from an i18n standpoint.
> 
> But issues, of length, format, etc are all specified by the protocol
> spec.
> 
> Black,> [2] I'm not sure that I understand what a KDF really is fro

Re: Gen-ART review of draft-ietf-karp-crypto-key-table-07

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  writes:


Black,> Major issues:

Black,> (Section 2)

Black,> [1] LocalKeyName and PeerKeyName are strings.  What
Black,> character set?  If Unicode (e.g., UTF-8?), add text on
Black,> Unicode considerations (e.g., normalization).  Finding a
Black,> Unicode expert will help in getting this done quickly.  I
Black,> have similar concerns for other strings, and in particular,
Black,> IANA should be told what a "string" is for any registry
Black,> field that contains one.

They are strings that can be compared using binary comparison.
I agree we need to state that in the draft.
Character set, to the extent it is specified will be specified by the
individual protocol.
In practice the protocol will say  that it's an integer represented as
an ASCII string.

We needed to add the entire complexity of making these fields be strings
not integers because of some non-IETF protocols that use key names.

I'm reasonably confident I can sell Pete on the concept of a binary
identifier for this field from an i18n standpoint.

But issues, of length, format, etc are all specified by the protocol
spec.

Black,> [2] I'm not sure that I understand what a KDF really is from
Black,> its high level description in this draft.  At the least, I'm
Black,> surprised that the importance of non-invertibility of a KDF
Black,> is not mentioned - beyond that, a functional description of
Black,> inputs and outputs would help, including a strong
Black,> recommendation to inject unpredictable nonce material.  This
Black,> could be handled by referencing material on what a KDF is
Black,> that exists elsewhere.

I'm open to text either proposed on the IETF list from one of the other
authors.
Some protocols have a KDF input some do not.
If they do, it will be drawn from a set of allowable valuable for that
protocol.

Black,> (Section 4)

Black,> [3] It's important that this section cover all the fields
Black,> involved in the database lookups in Section 3 whose format
Black,> may be protocol-specific (the Direction and various time
Black,> fields aren't).  Protocol should be covered by the IANA
Black,> registry, peers and key names are covered here, but
Black,> interface appears to be missing - item (9) covers presence
Black,> vs.  absence of interface information, but not its format.

The interface is implementation-specific not protocol specific.  We
mandate that you must be able to tie things to interface. However the
format of an interface is quite specific to the routing platform in
questino.  I don't think there's a way that an IETF document can go into
useful detail on that.  SNMP and Netconf have models of how interfaces
are represented.  If we ever put together a Netconf schema for this
database, we'd specify the interface there.

Black,> --- Lots of issues with the IANA Considerations (Section 8)

Black,> (Section 8.1.1)

Black,> [5] No field format information for the fields in a registry
Black,> entry.  IANA should be told what formats to expect/use.

Thanks, agreed.


Black,> [6] "Protocol Specific Values" is not the same as
Black,> "ProtocolSpecificInfo" in section 2; the same name should be
Black,> used, but whitespace differences are ok.
Good catch.

Black,> [7] Should some sort of formats for Peers and Interfaces be
Black,> included in registering a Protocol?  If not, the lookups in
Black,> section 3 may be implementation-dependent (strings that work
Black,> w/one implementation may not work w/other implementations of
Black,> the same protocol).  The specification reference may suffice
Black,> based on the requirements in section 4 for what has to be in
Black,> each referenced specification.

When you register a protocol you need to point to a specification that
gives details on this sort of thing.

Black,> (Sections 8.2 and 8.3)

Black,> [8] No registry entry content descriptions.  Need to supply
Black,> information on what to register and the formats of the
Black,> elements of a registry entry.

Thanks.

Black,> [9] I suggest Expert Review for these registries, not just
Black,> First Come First Served, so that someone with a security
Black,> "clue" can check that the proposed registrations are
Black,> reasonable.

As an individual, I support FCFS, because I think getting expert
approval for some of the uses that have been proposed for these
registries will be challenging.

Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10

2013-04-29 Thread Martin Bjorklund

Hi,

"Roni Even"  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 
>containing:
> 
>  
>fastethernet-1/0
>  
> 
>When the server processes this request, it will set the leaf "type"
>to "ethernetCsmacd" and "location" to "1/0".  Thus, if the client
>performs a  right after the  above, it will
>get:
> 
>  
>fastethernet-1/0
>ethernetCsmacd
>1/0
>  "
> 
> I can see how the linkage between the location and name is done. I am not
> sure how the operator knows from the response what is the physical location
> without knowing the device type and manufacturer but at least the linkage is
> there and this is why I thought of it more as a logical device and not
> physical one.

Ok.  Since this is an example of a configuration of a physical
interface, it is assumed that the operator somehow knows which
physical port is being reconfigured -- somehow the operator must be
able to know what the port where the new cable was inserted is called
in the config.

But it makes sense to be more clear about this.  How about this
change:


OLD:

  The implementation restricts the names of the interfaces to one of
  "fastethernet-N/M" or "gigabitethernet-N/M".  The "location" of an
  interface is a string on the form "N/M".  The implementation
  auto-initializes the values for "type" and "location" based on the
  interface name.

NEW:

  The implementation restricts the names of the interfaces to one of
  "fastethernet-N/M" or "gigabitethernet-N/M".  The "location" of an
  interface is a string on the form "N/M".  It is assumed that the
  operator is aware of this naming scheme.  The implementation
  auto-initializes the values for "type" and "location" based on the
  interface name.

> When looking at E2.2 example

(ditto for this example.)


/martin



>   " An operator can configure a new interface by sending an 
>containing:
> 
>  
>acme-interface
>ethernetCsmacd
>1/0
>  "
> 
> Here the operator need to know the device to configure a specific interface
> and know how many interface exist and how they are named. So you assume that
> for this case this is known to the configuration.
> 
> Roni
> 
> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com] 
> Sent: 28 April, 2013 12:50 PM
> 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 draft-ietf-netmod-interfaces-cfg-10
> 
> Hi,
> 
> Thank you for your review.  Comments inline.
> 
> "Roni Even"  wrote:
> > I am the assigned Gen-ART reviewer for this draft. For background on 
> > Gen-ART, please see the FAQ at 
> > .
> > 
> > Please resolve these comments along with any other Last Call comments 
> > you may receive.
> > 
> > Document: draft-ietf-netmod-interfaces-cfg-10
> > 
> > Reviewer: Roni Even
> > 
> > Review Date:2013-4-28
> > 
> > IETF LC End Date: 2013-5-3
> > 
> > IESG Telechat date: 2013-5-16
> > 
> >  
> > 
> > Summary: This draft is almost ready for publication as Standard track RFC.
> > 
> >  
> > 
> >  
> > 
> > Major issues:
> > 
> >  
> > 
> > Minor issues:
> > 
> >  
> > 
> > 1.   I had some problem understanding the "location" leaf. Section 3.2
> > has it as a string and says that "The device uses the location string 
> > to identify the physical or logical entity that the configuration applies
> to".
> > I am not sure how you identify physical location having no definition 
> > of the mapping.
> 
> The sentence just before the quoted one above says:
> 
>   "The format of this string is device- and type-dependent."
> 
> and then the text says:
> 
>   "How a client can learn which types and locations are present on a
>   certain device is outside the scope of this document."
> 
> So the exact procedure is currently left to the vendors, but may be
> standardized in a future document (if possible...)
> 
> > I saw the examples in Appendix E and it looked more to me as logical 
> > mapping but not physical since it attaches a name to something in the 
> > device but I am not clear how you know what it is physically in the 
> > device. If the name 0-n or n/m are real physical entities, I think 
> > that it should be specified some place.
> > 
> >  
> > 
> >  
> > 
> > Nits/editorial comments:
> > 
> > 1.  In the introduction section maybe add to the first sentence a
> > reference to RFC6244 with some text.
> 
> Ok, this probably makes sense.  I will check w/ the WG and other documents.
> 
> 
> 
> > 2.  In section 2 are the" must" and "should"  used as described in
> > RFC2119, if yes need capital letters
> 
> Seciton 2 is more of a background, non-normative section.

Re: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10

2013-04-29 Thread Martin Bjorklund

Hi,

Thank you for your review.  Comments inline.

"Roni Even"  wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> .
> 
> Please resolve these comments along with any other Last Call comments you
> may receive.
> 
> Document: draft-ietf-netmod-interfaces-cfg-10
> 
> Reviewer: Roni Even
> 
> Review Date:2013-4-28
> 
> IETF LC End Date: 2013-5-3
> 
> IESG Telechat date: 2013-5-16
> 
>  
> 
> Summary: This draft is almost ready for publication as Standard track RFC.
> 
>  
> 
>  
> 
> Major issues:
> 
>  
> 
> Minor issues:
> 
>  
> 
> 1.   I had some problem understanding the "location" leaf. Section 3.2
> has it as a string and says that "The device uses the location string to
> identify the physical or logical entity that the configuration applies to".
> I am not sure how you identify physical location having no definition of the
> mapping.

The sentence just before the quoted one above says:

  "The format of this string is device- and type-dependent."

and then the text says:

  "How a client can learn which types and locations are present on a
  certain device is outside the scope of this document."

So the exact procedure is currently left to the vendors, but may be
standardized in a future document (if possible...)

> I saw the examples in Appendix E and it looked more to me as
> logical mapping but not physical since it attaches a name to something in
> the device but I am not clear how you know what it is physically in the
> device. If the name 0-n or n/m are real physical entities, I think that it
> should be specified some place. 
> 
>  
> 
>  
> 
> Nits/editorial comments:
> 
> 1.In the introduction section maybe add to the first sentence a
> reference to RFC6244 with some text.

Ok, this probably makes sense.  I will check w/ the WG and other
documents.

> 2.In section 2 are the" must" and "should"  used as described in
> RFC2119, if yes need capital letters

Seciton 2 is more of a background, non-normative section.  It lists
some of the design objectives.

> 3.In section 3.1 "It is optional in the data model,  but if the type
> represents a physical interface, it is mandatory", suggest having RFC2119
> language "It is OPTIONAL in the data model,  but if the type represents a
> physical interface, it is MUST be specified"

I think the first one should not be OPTIONAL, but the second one is
correct.  So I suggest this:

  It is defined as being optional in the data model, but if the type
  represents a physical interface, it MUST be specified.


/martin

RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

2013-04-29 Thread Bernie Volz (volz)

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 indicate that allowing removal of 
already reconfigured clients is recommended (to prevent unnecessary 
reconfigures) when retransmitting the Reconfigure-Request.

Note that if clients are added, that is not a retransmission but requires a 
"new" message (new XID).

- Bernie

-Original Message-
From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of 
Robert Sparks
Sent: Friday, April 26, 2013 12:19 PM
To: mohamed.boucad...@orange.com
Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Subject: Re: [dhcwg] RE : Gen-art review: 
draft-ietf-dhc-triggered-reconfigure-05

On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:
> 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; General Area Review 
> Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
> Objet : [dhcwg] Gen-art review: 
> draft-ietf-dhc-triggered-reconfigure-05
>
> I am the assigned Gen-ART reviewer for this draft. For background on 
> Gen-ART, please see the FAQ at
>
> .
>
> Please resolve these comments along with any other Last Call comments 
> you may receive.
>
> Document: draft-ietf-dhc-triggered-reconfigure-05
> Reviewer:  Robert Sparks
> Review Date: April 26, 2013
> IETF LC End Date: May 6, 2013
> IESG Telechat date: May 16, 2013
>
> Summary: This draft is on the right track but has open issues, described in
>the review.
>
> Major issues:
>
> Overall, this document is solid, but I think there is a bug in section 6.3.
> I could be wrong, but If I'm right, this paragraph:
>
> When retransmission is required, the relay may decide to correct the content 
> of RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier 
> list).  This decision is local to the relay (e.g., it may be based on 
> observed events such as one or more clients were reconfigured on their own).
>
> introduces a race-condition that could lead to an erroneous state. If a 
> relay's first message included client A, then the retransmission included 
> clients A and B, but that retransmission crosses with a success 
> RECONFIGURE-REPLY to the request that only included client A, the relay will 
> think it succeeded in asking A and B to be reconfigured.
>
> Med: This example does not apply for that text.
Really? What text constrains how you change what's in the retransmission?
>   In fact, the example should be the other way around. Perhaps, this can be 
> made clearer if we change "(e.g., update the Client Identifier list)" to 
> "(e.g., remove a client from the Client Identifier list)".
If I understand you correctly, you need more than just changing a parenthetical 
e.g.. I think you're saying that you are constraining the message changes to be 
such that if anything earlier in the retransmission sequence succeeded, the 
request in the retransmission would also have succeeded. But why do you need 
that much complexity? Do you have it already with any other request?
>
> Minor issues:
>
> This sentence:
>
> Furthermore, means to recover state in failure events must be supported, but 
> are not discussed in this document.
> places a requirement on a relay (even though it's not using a 2119 MUST). Is 
> there some other document that defines this requirement that you can 
> reference?
>
> Med: I'm not aware of any; but if there is one we can cite it.
>
>   If not, the requirement should be discussed in this document. 
> Alternatively, you could change the sentence to talk about the consequences 
> of not having a proprietary means for recovering state.
>
> Med: Will consider that option if you think this is really needed.
>
> Nits/editorial comments:

___
dhcwg mailing list
dh...@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

2013-04-29 Thread mohamed.boucadair

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; General Area Review Team; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
  the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the content of 
RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier 
list).  This decision is local to the relay (e.g., it may be based on observed 
events such as one or more clients were reconfigured on their own).

introduces a race-condition that could lead to an erroneous state. If a relay's 
first message included client A, then the retransmission included clients A and 
B, but that retransmission crosses with a success RECONFIGURE-REPLY to the 
request that only included client A, the relay will think it succeeded in 
asking A and B to be reconfigured.

Med: This example does not apply for that text. In fact, the example should be 
the other way around. Perhaps, this can be made clearer if we change "(e.g., 
update the Client Identifier list)" to "(e.g., remove a client from the Client 
Identifier list)".

Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be supported, but 
are not discussed in this document.
places a requirement on a relay (even though it's not using a 2119 MUST). Is 
there some other document that defines this requirement that you can reference?

Med: I'm not aware of any; but if there is one we can cite it.

 If not, the requirement should be discussed in this document. Alternatively, 
you could change the sentence to talk about the consequences of not having a 
proprietary means for recovering state.

Med: Will consider that option if you think this is really needed.

Nits/editorial comments:

Gen-ART review of draft-ietf-karp-crypto-key-table-07

2013-04-29 Thread Black, David

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 definitely useful and valuable work, as key management is often
an afterthought in protocol design, even when security functionality
is actively worked on in the design process.

The draft text is in good shape and reads cleanly, but the draft is
short on precision in specifying a number of the fields for the database,
and the IANA registries; most of the open issues are requests for the
level of precision needed for interoperability and reuse of database
implementation across different protocol implementations.

Major issues: 

(Section 2)

[1] LocalKeyName and PeerKeyName are strings.  What character set?
If Unicode (e.g., UTF-8?), add text on Unicode considerations (e.g.,
normalization).  Finding a Unicode expert will help in getting this
done quickly.  I have similar concerns for other strings, and in
particular, IANA should be told what a "string" is for any registry
field that contains one.

[2] I'm not sure that I understand what a KDF really is from its high
level description in this draft.  At the least, I'm surprised that the
importance of non-invertibility of a KDF is not mentioned - beyond that,
a functional description of inputs and outputs would help, including
a strong recommendation to inject unpredictable nonce material.  This
could be handled by referencing material on what a KDF is that exists
elsewhere.

(Section 4)

[3] It's important that this section cover all the fields involved in
the database lookups in Section 3 whose format may be protocol-specific
(the Direction and various time fields aren't).  Protocol should be
covered by the IANA registry, peers and key names are covered here,
but interface appears to be missing - item (9) covers presence vs.
absence of interface information, but not its format.

--- Lots of issues with the IANA Considerations (Section 8)

(Section 8.1.1)

[5] No field format information for the fields in a registry entry.
IANA should be told what formats to expect/use.

[6] "Protocol Specific Values" is not the same as "ProtocolSpecificInfo"
in section 2; the same name should be used, but whitespace differences
are ok.

[7] Should some sort of formats for Peers and Interfaces be included in
registering a Protocol?  If not, the lookups in section 3 may be
implementation-dependent (strings that work w/one implementation may
not work w/other implementations of the same protocol).  The specification
reference may suffice based on the requirements in section 4
for what has to be in each referenced specification.

(Sections 8.2 and 8.3)

[8] No registry entry content descriptions.  Need to supply information
on what to register and the formats of the elements of a registry entry.

[9] I suggest Expert Review for these registries, not just 
First Come First Served, so that someone with a security "clue" can
check that the proposed registrations are reasonable.

Minor issues:

[A] Overall - I would like to see a paragraph added on how this database
conceptually relates to the IPsec Peer Authorization Database (PAD) -
see RFC 4301, section 4.4.3.

[B] (Section 2) Where is key size recorded?  Is that an implicit attribute
of Key?

[C] (Section 3) Where does key selection occur?  I would suggest that the
database return all possible keys and let the protocol figure out what to
use.  This is particularly important for inbound traffic for obvious reasons.

Nits/editorial comments:

I suggest dividing section 3 into
- 3.1 Outgoing Traffic
- 3.2 Incoming Traffic

idnits 2.12.16 found a truly trivial nit -
  == Line 76 has weird spacing: '...strains  where...'

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.com    Mobile: +1 (978) 394-7754

Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

2013-04-29 Thread Robert Sparks


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 message it issues (e.g., update the
Client Identifier list).

NEW:
The relay MAY remove clients from the client identifier list in
subsequent retransmissions, but MUST NOT add clients to the client
identifier list.

(2)

OLD:
Furthermore, means to recover state in failure events must be
supported, but are not discussed in this document.

NEW:
Furthermore, means to recover state in failure events (e.g.,
[RFC5460]) must be supported, but are not discussed in this document.

Is this better?

1 is better.

2 is an improvement, I might say "such as" instead of e.g. to even more
strongly avoid someone thinking you are _requiring_ implementation of
RFC5460.  Even then, it's still not clear whether you're trying to say

"Something that doesn't do this is does not conform to this specification"

or

"Something that doesn't do this isn't as good a tool as it can be and 
may create a condition that operators and users will not like much."


You chose not to use MUST in that sentence. Can you make it less likely 
that someone will assume you meant to?


Cheers,
Med



-Message d'origine-
De : Bernie Volz (volz) [mailto:v...@cisco.com]
Envoyé : samedi 27 avril 2013 06:24
À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN
Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
dhc-triggered-reconfig...@tools.ietf.org
Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

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 indicate that allowing removal of
already reconfigured clients is recommended (to prevent unnecessary
reconfigures) when retransmitting the Reconfigure-Request.

Note that if clients are added, that is not a retransmission but requires a
"new" message (new XID).

- Bernie

-Original Message-
From: dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] On Behalf Of
Robert Sparks
Sent: Friday, April 26, 2013 12:19 PM
To: mohamed.boucad...@orange.com
Cc: dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf-
dhc-triggered-reconfig...@tools.ietf.org
Subject: Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-
reconfigure-05

On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote:

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; General Area Review
Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Objet : [dhcwg] Gen-art review:
draft-ietf-dhc-triggered-reconfigure-05

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at



.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described

in

the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section

6.3.

I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the

content of RECONFIGURE-REQUEST message it issues (e.g., update the Client
Identifier list).  This decision is local to the relay (e.g., it may be
based on observed events such as one or more clients were reconfigured on
their own).

introduces a race-condition that could lead to an erroneous state. If a

relay's first message included client A, then the retransmission included
clients A and B, but that retransmission crosses with a success
RECONFIGURE-REPLY to the request that only included client A, the relay
will think it succeeded in asking A and B to be reconfigured.

Med: This example does not apply for that text.

Really? What text constrains how you change what's in the retransmission?

   In fact, the example should be the other way around. Perhaps, this can

be made clearer if we change "(e.g., update the Client Identifier list)" to
"(e.g., remove a client from the Client Identifier list)".
If I understand you correctly, you need more than just changing a
parenthetical e.g..

RE: Gen-ART LC review of draft-ietf-netmod-interfaces-cfg-10

2013-04-29 Thread Roni Even

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 draft-ietf-netmod-interfaces-cfg-10

Hi,

"Roni Even"  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 
>containing:
> 
>  
>fastethernet-1/0
>  
> 
>When the server processes this request, it will set the leaf "type"
>to "ethernetCsmacd" and "location" to "1/0".  Thus, if the client
>performs a  right after the  above, it will
>get:
> 
>  
>fastethernet-1/0
>ethernetCsmacd
>1/0
>  "
> 
> I can see how the linkage between the location and name is done. I am 
> not sure how the operator knows from the response what is the physical 
> location without knowing the device type and manufacturer but at least 
> the linkage is there and this is why I thought of it more as a logical 
> device and not physical one.

Ok.  Since this is an example of a configuration of a physical interface, it
is assumed that the operator somehow knows which physical port is being
reconfigured -- somehow the operator must be able to know what the port
where the new cable was inserted is called in the config.

But it makes sense to be more clear about this.  How about this
change:


OLD:

  The implementation restricts the names of the interfaces to one of
  "fastethernet-N/M" or "gigabitethernet-N/M".  The "location" of an
  interface is a string on the form "N/M".  The implementation
  auto-initializes the values for "type" and "location" based on the
  interface name.

NEW:

  The implementation restricts the names of the interfaces to one of
  "fastethernet-N/M" or "gigabitethernet-N/M".  The "location" of an
  interface is a string on the form "N/M".  It is assumed that the
  operator is aware of this naming scheme.  The implementation
  auto-initializes the values for "type" and "location" based on the
  interface name.

> When looking at E2.2 example

(ditto for this example.)


/martin



>   " An operator can configure a new interface by sending an 
>containing:
> 
>  
>acme-interface
>ethernetCsmacd
>1/0
>  "
> 
> Here the operator need to know the device to configure a specific 
> interface and know how many interface exist and how they are named. So 
> you assume that for this case this is known to the configuration.
> 
> Roni
> 
> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 28 April, 2013 12:50 PM
> 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 draft-ietf-netmod-interfaces-cfg-10
> 
> Hi,
> 
> Thank you for your review.  Comments inline.
> 
> "Roni Even"  wrote:
> > I am the assigned Gen-ART reviewer for this draft. For background on 
> > Gen-ART, please see the FAQ at 
> > .
> > 
> > Please resolve these comments along with any other Last Call 
> > comments you may receive.
> > 
> > Document: draft-ietf-netmod-interfaces-cfg-10
> > 
> > Reviewer: Roni Even
> > 
> > Review Date:2013-4-28
> > 
> > IETF LC End Date: 2013-5-3
> > 
> > IESG Telechat date: 2013-5-16
> > 
> >  
> > 
> > Summary: This draft is almost ready for publication as Standard track
RFC.
> > 
> >  
> > 
> >  
> > 
> > Major issues:
> > 
> >  
> > 
> > Minor issues:
> > 
> >  
> > 
> > 1.   I had some problem understanding the "location" leaf. Section
3.2
> > has it as a string and says that "The device uses the location 
> > string to identify the physical or logical entity that the 
> > configuration applies
> to".
> > I am not sure how you identify physical location having no 
> > definition of the mapping.
> 
> The sentence just before the quoted one above says:
> 
>   "The format of this string is device- and type-dependent."
> 
> and then the text says:
> 
>   "How a client can learn which types and locations are present on a
>   certain device is outside the scope of this document."
> 
> So the exact procedure is currently left to the vendors, but may be 
> standardized in a future document (if possible...)
> 
> > I saw the examples in Appendix E and it looked more to me as logical 
> > mapping but not physical since it attaches a name to something in 
> > the device but I am not clear how you know what it is physically in 
> > the device. If the name 0-n or n/m are real physical entities, I 
> > think that it should be specified some place.
> > 
> >  
> > 
> >  
> > 
> > Nits/editorial comments:
> > 
> > 1.  In the introduction secti

Re: IETF Diversity Question on Berlin Registration?


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 mentioned that. Let's assume a simplified curriculum of
participant -> author/editor -> WG chair -> IESG, which more or less
reflects increasing seniority in the IETF. We may suspect that there
is bias that, at each step, privileges some candidates over others.
However, the mechanisms are different at each step.



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 anticipate the IETF to be in the 
likely to do it, likely to do it correctly quadrant.


Stewart

Re: IETF Diversity Question on Berlin Registration?

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 question. Instead,
consider "Why the diversity of the IETF leadership doesn't reflect the diversity of
the set of the IETF WG chairs"? I believe this is a more representative candidate
population for the IAB and IESG.

By my count (using the WG chairs picture page), there are 202 current working
group chairs. Of these 15 are female - or 7.4% of the population [It would be
more reliable to do this for any WG chair in the last 5-10 years, but the above
was readily available and I think provides at least the basis for discussion.
Anticipating the argument, I would assume for the sake of discussion a fairly
similar percentage of ex-working group chairs per gender unless there is
evidence to the contrary]

There are 14 (current area directors plus the chair) members of the IESG, of
which none are currently female.

There are 12 current IAB members of which 1 member is female.

Assuming perfect distribution, that would suggest that 14 * (15/202) or 1.03
IESG members should be female.

Assuming perfect distribution, that would suggest that 12 * (15/202) or .89 IAB
members should be female.

Assuming perfect distribution, that would suggest that 26 * (15/202) or 1.93
IAB + IESG members should be female.

And pretending for a moment that picks for the IAB and IESG are completely
random from the candidate set of Working group chairs, the binomial
distribution for 7.4% for 27 positions is:

0 - 12.5%, 1 - 27.0%, 2 - 28.1%, 3 or more - 32.5%. (e.g. about 40% of the
time, the IAB and IESG combined will have 0 or 1 female members).

for 7.4% for 15 positions (IESG) is:
0 - 31.4%, 1 - 37.8%, 2 - 21.2%, 3 or more - 9.5%

for 7.4% for 12 positions (IAB) is:
0 - 39.6%, 1 - 38.1%, 2 - 16.8%, 3 or more - 5.4%

But the actual one you should consider is 7.4% for 14 positions (annual
replacement):
0 - 34%, 1 - 38.1%, 2 - 19.9%, 3 or more - 8%.

This last one says that for any given nomcom selection, assuming strict random
selection, 72% of the time 0 or 1 females will be selected across both the IAB
and IESG. You should use this one as the actual compositions of the IAB/IESG
are the sum of all the nomcom actions that have happened before.

There are statistical tests to determine whether there is a statistically
significant difference in populations, but my admittedly ancient memories of
statistics suggest that the population size of the IAB/IESG is too small for a
statistically valid comparison with either the WG chair population or the IETF
population.

Of course, the nomcom doesn't select and the confirming bodies do not confirm
based on a roll of the dice.
But looking at this analysis, it's unclear - for this one axis of gender - that the question
"why the diversity of the IETF leadership does not reflect the diversity of the set of IETF WG
chairs" has a more correct answer than "the luck of the draw".

My base premise may be incorrect: That you need to have been a WG chair prior
to service as an IAB or IESG member. I hope it isn't as I think this level of
expertise is useful for success in these bodies.

Assuming it is correct, then the next question is whether or not there is a
significant difference in percentage of female attendees vs percentage of
female working group chairs and is there a root cause for that difference that
the IETF can address in a useful manner.

Mike

This is in line with my own estimate based on an approximation of 1:10
which with random selection gives an error approximation of sqrt(1)=1

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. So you will get long runs
of 0. Very infrequently you will also get long runs of 27. In both cases
it is in human nature to would assume something is wrong, when it is an
artifact of random numbers. Humans have considerable difficulty
discriminating between systematic and statistical problems, and taking
the long view rather than the short view.

For that reason, as I noted in my previous post, we need a rigorous
statistical analysis with proper confidence intervals, rather than
simple averages on spot years.

- Stewart

Re: IETF Diversity Question on Berlin Registration?