Re: Less Corporate Diversity

[Hector Santos]

On 3/20/2013 3:18 PM, Eric Burger wrote:

> How much is the concentration of corporate participation in
> the IETF a result of market forces, like consolidation and
> bankruptcy, as opposed to nefarious forces, like a company
> hiring all of the I* leadership? We have mechanisms to deal
> with the latter, but there is not much we can do about the
> former.

I am not catching the question.  Are you concern there is an increasing 
potential for a "conflict of interest" loophole the IETF may no longer 
afford to manage and control?


We will always have Cooperative Competition.  The IETF damage can only 
be to sanction the standardization of a problematic method or technology 
and/or the straggle hold of a market direction.  Generally, the market 
will speak for itself.  We need the market and technology leaders for 
the rest to follow, but the IETF role should continue to be the 
gatekeeper and watchdog for open and public domain standards.


--
HLS

Re: Diversity of IETF Leadership

[Toerless Eckert]

On Wed, Mar 20, 2013 at 03:59:34PM -0400, Jeffrey Haas wrote:
> On Wed, Mar 20, 2013 at 03:13:01PM -0400, Sam Hartman wrote:
> > Part of what I meant when I signed the diversity letter was to state a 
> > belief
> > that within a pool of qualified candidates, I believe diversity is
> > important enough that it is valuable to select for diversity even if
> > this does not maximize the skills that you enumerated (tech skill, admin
> > skill, works with others and something else).
> 
> "Maximize" overstates my position.  My belief is once the base requirements
> are met that diversity is an appropriate tie-breaker.  Maximizing the four I
> mentioned is different.

I think that diversity is already taken into account
much more than just as a tie-breaker. Nomcon does
look at a lot of the factors influenced by the
candidates background / diversity stats already as
actual job qualifications: Knowlege/presence of
geographic regions, collaborative influencing leadership
stle, ability to engage with other cultures, etc. pp.

Cheers
Toerless

Re: Please review draft-housley-rfc2050bis-00.txt

[John Curran]

On Mar 20, 2013, at 8:45 PM, SM  wrote:

> Ok.  I'll defer to the learned individuals of the IETF in respect
> to the intended status.  It is my understanding that the document
> also aims to replace BCP 12.

Excellent question; it's my belief that obsoleting RFC2050 would 
do that, but perhaps it would be best to make that point more 
specific in this document?

> I can only say that in my opinion the omission of the finer details
> does not have any negative consequences for the RIRs.

IN-ADDR maintenance is explicitly in RFC 2050, and has not been
overtaken by events to my knowledge, hence it is included in this 
successor document.

>  "Per the delineation of responsibility for Internet address policy
>   issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions
>   regarding the evolution of the Internet Numbers Registry System
>   structure, policy, and processes are to take place within the ICANN
>   framework and will respect ICANN's core values [ICANNBL]."
> 
> How does the above affect the IETF, e.g. what process changes happened 
> between RFC 2050 and draft-housley-rfc2050bis-00?  Why is it even relevant to 
> the IETF?

The IETF/IAB signed an MOU with ICANN for performance of certain IANA tasks,
including a framework which recognized that ICANN would be dealing with policy 
issues related to the domain name system and the IP address system.  At the 
same 
time, the Regional Internet Registries worked with ICANN to perform the 
community-
based regional and global IP policy development coordinated with ICANN's 
overall 
framework.  This is clearly a different way of establishing IP address policy 
than 
described in the current RFC2050, and hence material to the IETF.

>  "These core values encourage broad, informed participation reflecting
>   the functional, geographic, and cultural diversity of the Internet at
>   all levels of policy development and decision-making, as well as the
>   delegation of coordination functions and recognition of the policy
>   roles of other responsible entities that reflect the interests of
>   affected parties."
> 
> I do not understand what the above means in practice.

There are lots of folks over in the DNS world wondering that same question... 
;-)

Seriously, one could write volumes about ICANN, its structure, processes
oversight role, etc., but at the end of the day you'd be creating a fixed
copy of what is an evolving organization.  The IETF does not decide today
when and which new top-level domains are added to the DNS root, that is an
example of a question which requires "broad, informed participation reflecting
the functional, geographic, and cultural diversity of the Internet at all 
levels of policy development and decision-making."

>  "The discussions regarding Internet Numbers Registry evolution must
>   also continue to consider the overall Internet address architecture
>   and technical goals referenced in this document."
> 
> After reading  draft-housley-rfc2050bis-00 it is my understanding that the 
> Internet Numbers Registry is out of scope for the IETF.  I read the above as 
> meaning that the IETF is telling RIRs and ICANN that they must also follow 
> technical guidance from the IETF in respect to the Internet address 
> archtecture.

The IETF defines the architecture of the Internet Protocol, and this includes
the IP address space.  Regardless of whether policy development has been
delegated to the RIRs under the ICANN framework, the address architecture
is still established by the IETF.

> "The foregoing does not alter the IETF's continued responsibility for
>  the non-policy aspects of Internet addressing such as the architectural
>  definition of IP address and AS number spaces and specification of
>  associated technical goals and constraints in their application, assignment
>  of specialized address blocks, and experimental technical assignments as
>  documented in RFC 2860."
> 
> The above sounds like something from the legal department.  I unfortunately 
> cannot hire a lawyer to tell me whether that text matches the text in RFC 
> 2860.  I don't see how one can expect informed participation when the text to 
> be read might be unclear to the people from the rest of the world.

To my knowledge, it does correctly represent the terms in RFC 2860, 
but I understand that the language is rather dense and may be hard
to parse.  We do not want to repeat the entirety of RFC 2860 here,
but it is useful for readers to know that per that MOU, there is a
has a delineation of responsibilities between the IETF and the 
ICANN/RIR system.

> By the way I read my previous message [1] again and the reply [2] I received 
> and I noticed that there wasn't any response to two of the questions.

Agreed.  I commented on those aspects where my remarks may add value to 
the discussion; there are others on this list with greater experience and
knowledge which may help with other questions you have raised.

Thanks for the feedback - I hope I've hel

Re: Less Corporate Diversity

[John C Klensin]

--On Wednesday, March 20, 2013 23:36 +0100 Jari Arkko
 wrote:

> I think it is mostly market forces and historical reasons, and
> the development of the IETF to focus on more particular core
> aspects of the Internet (like routing) as opposed to what the
> small shops might work on.

I mostly agree.  However, I see lots of activity in Apps and
RAI, very little of which would seem to be "core aspects of the
Internet".  Also, given the cost factor, the length of time it
usually seems to take us to spin up a WG and get anything done
is probably also a significant barrier: a small shop who could
afford to send someone to a meeting or three might have neither
the people-resources nor travel and meeting budget to commit to
a few years of meetings.
 
> But I think we are missing a bit of the point in this
> discussion. I do not feel that we need to prove we are somehow
> "no worse" than industry average. The point is that *if* we
> had more diversity along many of the discussed lines, we'd be
> far better off. For instance, having people from multiple
> organisations provide input to a last would be preferable to
> just a few. Similarly with the other dimensions of diversity.
> When I talked to some of the ISOC fellows last week, I
> realised peering is very different on different continents.

I have run across another example fairly often that was, I
think, mentioned briefly last week.  Most of us are used to
network connections of very high bandwidth and quality.  Our
protocol designs and implementations are developed and tested on
those networks and, usually, on the very latest and most
powerful equipment.  The IETF would almost certainly benefit
from vigorous input from people whose environments are
characterized by longer delays, serious congestion, packet
fragmentation, and so on.  Without them, I fear that
implementations of a lot of our work, and maybe the work itself,
will not be acceptable in lower-end or more congested networks
or from computer systems more typical of that average Internet
user and that they will not have the level of robustness that
ought to be one of the Internet's strengths.

> Even if there may be less economic activity on networking on
> those continents, it would be good for us to understand the
> real situations around the world, as opposed to thinking the
> whole world is like where we live. Diversity = good in most
> cases, and increasing that goodness should be the goal.

Indeed.  And, taking the comment above a step further, one need
only go to a sufficiently rural area in many developed countries
--one that is served exclusively by overloaded high orbit
satellite links (with the delay times that implies) -- to
encounter the problem even though people from "other continents"
are more likely to be articulate about the issues and easier to
get to the IETF then those rural users.

john

Re: Please review draft-housley-rfc2050bis-00.txt

[SM]

Hi John,

This is an individual comment.

At 16:38 20-03-2013, John Curran wrote:

The RFC is not intended to establish anything new, only to recognize
the existing agreements and practices of the IETF in this area.


Ok.  I'll defer to the learned individuals of the IETF in respect to 
the intended status.  It is my understanding that the document also 
aims to replace BCP 12.



The explanation is in Section 5 (Summary of Changes Since RFC 2050);
isn't that usual practice for an RFC which replaces another in entirety?


I can only express an individual opinion and not what is usual 
practice for an RFC.  The few drafts I have read usually had an 
explanation in the Introduction section to help the reader.  I don't 
feel strongly about this.  I am more interested in seeing whether the 
IESG will file a DISCUSS about this.


By the way the summary of changes is very short.


The text in RFC 5855 that you reference is with respect only to the
two top-level reverse domains, i.e. "all nameservers concerned" is
preceded by:

  "1. IN-ADDR-SERVERS.ARPA to the nameservers listed in Section 2;
   2. IP6-SERVERS.ARPA to the nameservers listed in Section 3."


I preferred not to quote RFC 5855 in its entity.  My reading of that 
document and the discussions leading to it is that it is up to the 
IAB to provide technical guidance to ICANN about .arpa (re. reverse 
DNS).  I don't see any mention of "Internet Numbers Registry System" 
in RFC 3172 or RFC 5855.


I can only say that in my opinion the omission of the finer details 
does not have any negative consequences for the RIRs.



It looks to be plain English to me...  can you be more specific
about what part of the text which is problematic?


  "Per the delineation of responsibility for Internet address policy
   issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions
   regarding the evolution of the Internet Numbers Registry System
   structure, policy, and processes are to take place within the ICANN
   framework and will respect ICANN's core values [ICANNBL]."

How does the above affect the IETF, e.g. what process changes 
happened between RFC 2050 and draft-housley-rfc2050bis-00?  Why is it 
even relevant to the IETF?


  "These core values encourage broad, informed participation reflecting
   the functional, geographic, and cultural diversity of the Internet at
   all levels of policy development and decision-making, as well as the
   delegation of coordination functions and recognition of the policy
   roles of other responsible entities that reflect the interests of
   affected parties."

I do not understand what the above means in practice.  The IETF is 
having a lengthy discussion about diversity.  The IETF community 
might learn from ICANN if it shares its experience of how it has 
successfully tackled cultural diversity.


  "The discussions regarding Internet Numbers Registry evolution must
   also continue to consider the overall Internet address architecture
   and technical goals referenced in this document."

After reading  draft-housley-rfc2050bis-00 it is my understanding 
that the Internet Numbers Registry is out of scope for the IETF.  I 
read the above as meaning that the IETF is telling RIRs and ICANN 
that they must also follow technical guidance from the IETF in 
respect to the Internet address archtecture.


 "The foregoing does not alter the IETF's continued responsibility for
  the non-policy aspects of Internet addressing such as the architectural
  definition of IP address and AS number spaces and specification of
  associated technical goals and constraints in their application, assignment
  of specialized address blocks, and experimental technical assignments as
  documented in RFC 2860."

The above sounds like something from the legal department.  I 
unfortunately cannot hire a lawyer to tell me whether that text 
matches the text in RFC 2860.  I don't see how one can expect 
informed participation when the text to be read might be unclear to 
the people from the rest of the world.


As an off-topic comment, it seems like there hasn't been careful 
review of an IANA policy for ASNs.  The wise members of the IESG 
would have caught the bug.


By the way I read my previous message [1] again and the reply [2] I 
received and I noticed that there wasn't any response to two of the questions.


Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg78135.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg78141.html  

RE: [apps-discuss] Last Call: (WebFinger) to Proposed Standard

[Paul E. Jones]

Hannes,
 
> I was hoping that some of the remarks that I provided last year (e.g.,
> http://www.ietf.org/mail-archive/web/oauth/current/msg08965.html) would
> help to clarify the content of the document. That didn't quite happen...

Yeah, I wasn't copied.
 
> In earlier versions of the document I had the impression that the acct:
> URI scheme always had to be used as input to the lookup process but as
> Section 4.5 explains this is not necessary. The resource parameter may
> contain other URIs as well. Section 4.5 does not give a lot of
> description of when certain URIs are utilized. 

Correct, any URI might be used.  That does not mean that the server will 
respond for every URI, but some wanted "acct" and "email" and "tel" URIs, for 
example.  Also, using an HTTP URI could be used to return additional 
information about a URI.
 
> For example, in Section 3.1 the example talks about a user receiving an
> email from b...@examle.com and this email address is then used by
> WebFinger but the request example shows an acct: URI scheme (rather than
> a mailto URI). It seems that there is the unstated assumption (at least
> in that example) that the mailto URI is the same as the acct: URI, which
> of course isn't necessarily the case. I believe it would be good to
> state these assumptions to avoid confusing the reader. 

Fair point.  How about immediately following the example, we add:
'Note the assumption made in above example that there is an "acct" URI for the 
given "mailto" URI.  This is not always the case.'

> Think about it: If you receive a SIP URI (which also has an email alike
> structure with a username @ domain part) that does not mean either that
> you can use this as an email address either. In some rare cases you
> might. 

That's definitely true.  However, this is one reason for encouraging the use of 
the "acct" URI scheme, though.  In general (though not always), there is 
account associated with the user.  The SIP URI, mailto URI, etc., each have a 
user part.  I believe it is a reasonable assumption that there *may be* an 
'acct' URI for the user.  If not, WF will return nothing.

We intended WF to be useful to humans, too, which means that if a user sees 
pau...@packetizer.com, the user will assume that might be a means of reaching 
"paulej" at "packetizer.com" using any number of tools (email, XMPP, H.323, 
etc.).  They would be correct for most.  Thus, there is encouragement for WF 
servers to use the acct URI.
 
> If you believe that everyone would get the difference anyway (because
> the URI scheme determines the semantic of the identifier) then have a
> look at the Google WebFinger page (see
> http://code.google.com/p/webfinger/). At least these guys don't
> understand the difference either. 

There was even a proposal that we use no URI scheme at all and merely have the 
user@domain identifier.  However, there is value in using a proper URI with WF, 
since querying "h323:pau...@packetizer.com" might return the address of my 
Gatekeeper, for example, versus the information that would be returned for my 
account. 

> In general, I am wondering whether there are additional assumptions
> implied about the URI scheme associated with the identifier in the
> lookup mechanism. For example, the text in Section 3.3 talks about email
> client configuration and it seems that the requestor is interested in
> receiving information about the email configuration based on the
> resource=mailto... URI scheme usage. If I use a different URI scheme
> (like a aaa: URI scheme) would my response look different?

Yeah, it might look different.  What a WF server wishes to return for a given 
URI is really up to the administrator.  It might be that the same information 
is returned for any given URI scheme having the same user@domain part, but the 
server could return different responses.
 
> Then, there is a question about the lack of privacy considerations in
> the document. 

We do have quite a bit of text in the security considerations section.  This 
will be called out more clearly with sub-sections, but there are at least three 
full paragraphs on privacy, even going to the point of providing the example 
that sharing location information might put a person in danger from someone who 
wishes to inflict harm on them.  Personally, I thought that went a bit 
overboard, but that text was requested, so it's there.
 
> The usage of the WebFinger mechanism requires the requestor to have
> access to the full username@domain identifier. While this may be OK in
> some cases when the response relates very much to the specific user
> account it may be a problem in other cases. For example, in the OAuth
> case there is the idea that the user identifier may be hidden from the
> relying party but you have just required that identifier to be provided
> to the relying party to start the entire OAuth exchange (in the
> discovery).

WF is not for use with every protocol, so I cannot address OAuth generically.  
However, 

RE: Less Corporate Diversity

[l.wood]

An ad-hominem argument, Melinda?

really?

Lloyd Wood
http://sat-net.com/L.Wood/



From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Melinda Shore 
[melinda.sh...@gmail.com]
Sent: 21 March 2013 01:01
To: m...@sap.com
Cc: ietf@ietf.org
Subject: Re: Less Corporate Diversity

On 3/20/13 4:51 PM, Martin Rex wrote:
> I'm having difficulties to follow (but I'm also new to diversity discussions).
> It is my understanding that work in the IETF is done by individual
> participants within Working Groups or as individuals.  Review seems to
> happen within WGs, and the review work(load) seems to have significantly
> shifted from ADs to Directorates.

With all due respect, I can't find any RFCs you've authored or working
groups you've chaired.  Or, for that matter, any current internet
drafts.  I absolutely could have missed something and I hope that if
I'm wrong you'll correct me.  However, if I'm not wrong, you haven't
been through the process of bringing work into the IETF, socializing
it, and trying to get it published or adopted, in which case you're
missing a lot.

Melinda

RE: [apps-discuss] Last Call: (WebFinger) to Proposed Standard

[Paul E. Jones]

Alissa,

It was suggested that we remove the word "implicit".  I'm OK with removing
it.  If we did that, would you want to add this new sentence or a modified
version of it?

Paul

> -Original Message-
> From: apps-discuss-boun...@ietf.org [mailto:apps-discuss-
> boun...@ietf.org] On Behalf Of Alissa Cooper
> Sent: Monday, March 18, 2013 11:31 AM
> To: ietf@ietf.org
> Cc: apps-disc...@ietf.org
> Subject: Re: [apps-discuss] Last Call:  10.txt> (WebFinger) to Proposed Standard
> 
> Given how little control Internet users already have over which
> information about them appears in which context, I do not have a lot of
> confidence that the claimed discoverability benefits of WebFinger
> outweigh its potential to further degrade users' ability to keep
> particular information about themselves within specific silos. However,
> I'm coming quite late to this document, so perhaps that balancing has
> already been discussed, and it strikes me as unreasonable to try to
> stand in the way of publication at this point.
> 
> Two suggestions in section 8:
> 
> s/personal information/personal data/
> (see http://tools.ietf.org/html/draft-iab-privacy-considerations-
> 06#section-2.2 -- personal data is a more widely accepted term and
> covers a larger range of information about people)
> 
> The normative prohibition against using WebFinger to publish personal
> data without authorization is good, but the notion of implicit
> authorization leaves much uncertainty about what I imagine will be a use
> case of interest: taking information out of a controlled context and
> making it more widely available. To make it obvious that this has been
> considered, I would suggest adding one more sentence to the end of the
> fourth paragraph:
> 
> "Publishing one's personal data within an access-controlled or otherwise
> limited environment on the Internet does not equate to providing
> implicit authorization of further publication of that data via
> WebFinger."
> 
> Alissa
> 
> On Mar 4, 2013, at 3:24 PM, The IESG  wrote:
> 
> >
> > The IESG has received a request from the Applications Area Working
> > Group WG (appsawg) to consider the following document:
> > - 'WebFinger'
> >   as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > ietf@ietf.org mailing lists by 2013-03-18. Exceptionally, comments may
> > be sent to i...@ietf.org instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >   This specification defines the WebFinger protocol, which can be used
> >   to discover information about people or other entities on the
> >   Internet using standard HTTP methods.  WebFinger discovers
> >   information for a URI that might not be usable as a locator
> >   otherwise, such as account or email URIs.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-appsawg-webfinger/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> > ___
> > apps-discuss mailing list
> > apps-disc...@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> 
> 
> ___
> apps-discuss mailing list
> apps-disc...@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

Re: Less Corporate Diversity

[Melinda Shore]

On 3/20/13 4:51 PM, Martin Rex wrote:
> I'm having difficulties to follow (but I'm also new to diversity discussions).
> It is my understanding that work in the IETF is done by individual
> participants within Working Groups or as individuals.  Review seems to
> happen within WGs, and the review work(load) seems to have significantly
> shifted from ADs to Directorates.

With all due respect, I can't find any RFCs you've authored or working
groups you've chaired.  Or, for that matter, any current internet
drafts.  I absolutely could have missed something and I hope that if
I'm wrong you'll correct me.  However, if I'm not wrong, you haven't
been through the process of bringing work into the IETF, socializing
it, and trying to get it published or adopted, in which case you're
missing a lot.

Melinda

Re: Less Corporate Diversity

[Martin Rex]

Melinda Shore wrote:
> Martin Rex wrote:
> >
> > While I agree that it helps avoiding a "few big vendors" bias.
> > is this really a significant problem _today_, adversely affecting a
> > non-marginal amount of the current IETF output, and in a fashion where
> > simply more diversity in the I* leadership would bring a noticable
> > improvement--without that same change adversely affecting the amount
> > and quality of the *other* IETF output?
> 
> I think it would improve the quality of stewardship and review,
> and the understanding of what's going on in the industry and
> where the needs and priorities are.  I also think that the very
> distinct western bias in the leadership means that there's a
> distinct lack of familiarity with deployment and management
> models being used (or assumed) by a growing portion of IETF
> participants.


I'm having difficulties to follow (but I'm also new to diversity discussions).
It is my understanding that work in the IETF is done by individual
participants within Working Groups or as individuals.  Review seems to
happen within WGs, and the review work(load) seems to have significantly
shifted from ADs to Directorates.

The IETF rough consensus model with its (1- or 2-level) Last Calls is
intended to ensure resolution of objections or technical concerns,
even when raised by only one single IETF participant.

My impression of todays IESG role, in particular taking their
balloting rules and their actual balloting results into account,
is more of a "confirming body" of work that happened elsewhere
(primarily in the IETF, typically in IETF WGs, but also individual or
interest groups submissions from elsewhere, though the latter mostly
for (re)publication as informational).

IMHO, the IESG is not (and maybe never was?) a committee where _each_
member reviews _all_ of the work, where _each_ forms his very own opionion,
and where all of them caste a VOTE at the end, so that the diversity
within that committee would be vitally beneficial (to anything).


> 
> But, I do think that given our decision-making structures and
> so on, and given the speed with which people I thought knew
> better zoomed over to the "NO QUOTAS!" place when the issue
> was raised, this situation is basically irreparable.


The "leadership" in the IETF is not limtied to I* positions.

To me, it appears that WG chairs (can) have (if they so desire)at least
as much impact on actual work that happens in WGs as the responsible AD,
and directorate review of documents is at least as relevant as
reviews of individual ADs (if not more), and both of these functions
(WG Chair) and directorate participation seem to require much less
time&monetary investments from IETF participants than I* functions,
and the positions outnumber the I* positions probably by a magnitude.


-Martin

Re: Please review draft-housley-rfc2050bis-00.txt

[John Curran]

On Mar 20, 2013, at 4:04 PM, SM  wrote:
> I might as well comment quickly about draft-housley-rfc2050bis-00.  The draft 
> is a good effort but it might need more work in my humble opinion.
> 
> The intended status is Informational.  Is there a reason for that?

The RFC is not intended to establish anything new, only to recognize
the existing agreements and practices of the IETF in this area.

> Why does the document obsolete RFC 2050?  There is no explanation for that in 
> the Abstract or the Introduction section.

The explanation is in Section 5 (Summary of Changes Since RFC 2050); 
isn't that usual practice for an RFC which replaces another in entirety?

> In Section 3:
> 
>  "Reverse DNS: In situations where reverse DNS was used, the
>   policies and practices of the Internet Numbers Registry System
>   have included consideration of the technical and operational
>   requirements posed by reverse DNS zone delegation [RFC3172]."
> 
> According to RFC 5855:
> 
>  "The choice of operators for all nameservers concerned is beyond the
>   scope of this document and is an IANA function that falls under the
>   scope of Section 4 of the MoU between the IETF and ICANN [RFC2860]."
> 
> Maybe referencing RFC 5855 would be better.  It may be easier not to say 
> anything about reverse DNS.

The text in RFC 5855 that you reference is with respect only to the
two top-level reverse domains, i.e. "all nameservers concerned" is 
preceded by:

  "1. IN-ADDR-SERVERS.ARPA to the nameservers listed in Section 2;
   2. IP6-SERVERS.ARPA to the nameservers listed in Section 3."

>  "Per the delineation of responsibility for Internet address policy
>   issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions
>   regarding the evolution of the Internet Numbers Registry System
>   structure, policy, and processes are to take place within the ICANN
>   framework and will respect ICANN's core values [ICANNBL].  These core
>   values encourage broad, informed participation reflecting the
>   functional, geographic, and cultural diversity of the Internet at all
>   levels of policy development and decision-making, as well as the
>   delegation of coordination functions and recognition of the policy
>   roles of other responsible entities that reflect the interests of
>   affected parties.  The discussions regarding Internet Numbers
>   Registry evolution must also continue to consider the overall
>   Internet address architecture and technical goals referenced in this
>   document."
> 
> Could someone please translate the above in plain English?  What's the IETF 
> angle in all that?

It looks to be plain English to me...  can you be more specific
about what part of the text which is problematic?

> Why should I read RFC 6484 to understand  draft-housley-rfc2050bis-00?

I believe this is a trailing reference that should be deleted at this 
point.

Thanks for the comments!
/John

Disclaimers: My views alone. Use care in opening; contents may have 
 shifted during electronic flight.

Re: Less Corporate Diversity

[Melinda Shore]

On 3/20/13 3:20 PM, Martin Rex wrote:
> While I agree that it helps avoiding a "few big vendors" bias.
> is this really a significant problem _today_, adversely affecting a
> non-marginal amount of the current IETF output, and in a fashion where
> simply more diversity in the I* leadership would bring a noticable
> improvement--without that same change adversely affecting the amount
> and quality of the *other* IETF output?

I think it would improve the quality of stewardship and review,
and the understanding of what's going on in the industry and
where the needs and priorities are.  I also think that the very
distinct western bias in the leadership means that there's a
distinct lack of familiarity with deployment and management
models being used (or assumed) by a growing portion of IETF
participants.

I also expect that I am not the only participant who's a
consultant and at least partly self-funded and regularly coming
to meetings, but there will always be folks saying that we
don't exist, even as people seem to not want to acknowledge
that there were a lot of women who'd accepted IESG nominations
this cycle.

But, I do think that given our decision-making structures and
so on, and given the speed with which people I thought knew
better zoomed over to the "NO QUOTAS!" place when the issue
was raised, this situation is basically irreparable.

Melinda

Re: Less Corporate Diversity

[Martin Rex]

Jari Arkko wrote:
> 
> But I think we are missing a bit of the point in this discussion.
> I do not feel that we need to prove we are somehow "no worse" than
> industry average. The point is that *if* we had more diversity along
> many of the discussed lines, we'd be far better off. For instance,
> having people from multiple organisations provide input to a last
> would be preferable to just a few. Similarly with the other dimensions
> of diversity. When I talked to some of the ISOC fellows last week,
> I realised peering is very different on different continents.

I'm far from convinced that the IETF would be "better off" with strong
diversity (company-wise and cultural-wise).  This probably begs for
clarification how we define "better off" in the first place.

The more diverse the "culture", the higher the probability for
miscommunication (misunderstanding and taking offense).

The more more diverse the (interests) of the affiliations of IETF
participants and IETF leadership, the hotter the dicussions typically
burn on contentious issues (ratholing).  That is at least my very
personal perception (over the past 18 years, but admittedly from
just a few WGs in the security area, that are probably not representative
of the IETF in general).

This does *NOT* mean that that I am opposed to diversity in any way.

But I do not believe that more diversity will unconditionally improve the
situation.

http://4.bp.blogspot.com/_W7qnSgy4xWo/TI_htYJ9pqI/ADM/AdNqCzCBz14/s640/Too+many+cooks+spoil+the+broth.jpg

While I agree that it helps avoiding a "few big vendors" bias.
is this really a significant problem _today_, adversely affecting a
non-marginal amount of the current IETF output, and in a fashion where
simply more diversity in the I* leadership would bring a noticable
improvement--without that same change adversely affecting the amount
and quality of the *other* IETF output?


-Martin

Re: Less Corporate Diversity

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 3/20/13 2:37 PM, Jeffrey Haas wrote:
> On Wed, Mar 20, 2013 at 03:18:24PM -0400, Eric Burger wrote:
>> How much is the concentration of corporate participation in the
>> IETF a result of market forces, like consolidation and
>> bankruptcy, as opposed to nefarious forces, like a company hiring
>> all of the I* leadership? We have mechanisms to deal with the
>> latter, but there is not much we can do about the former.
> 
> Having started in the IETF at a much smaller vendor, it's less a
> nefarious thing than it is a money thing.
> 
> When you're talking about participation at the conferences, the
> cost of flying someone to the venue, paying for the conference fee
> and covering hotel can be a big burden for smaller companies.  They
> then have to pick and choose which groups it makes sense to get a
> human to attend.
> 
> Even on-the-list participation can be a financial burden.  Someone
> has to spend a chunk of their time doing standards work instead of
> other things like code.
> 
> I* leadership is even messier.  IETF is effectively asking for half
> or more of the time of those people.  They are effectively being
> given a form of patronage to do IETF work.

+1

When I worked at a small vendor, I attended IETF meetings only when
there was work happening directly related to what my company care
about. I *might* have been able to be a WG chair, but there is no way
I could have been an area director until after our small company was
acquired by Cisco.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRSkK+AAoJEOoGpJErxa2pKAoP/ibKBeI4RBuP8dGnuFqOqALX
JhgeStw0SMainyQ2YvLXXlFueQzAn3+mMpLa4OsnsvaBSZMhX/hvxDbRD5OA9rFT
Jock8WteQHJwi9pj4GIVA5Ck9JctxHeHXpe33tDVlDcoqYyGafO9Y+r+JZqnwjYo
Ao6iNLz6MMOXnhZwbWcnLjP5AcA72R0oevdB6h01F00gqhi2E90Pao/2Lup6V7q8
6qP6S5ZqCxnio/pSMMorv3tyDl3FvARn03vLhyx1E1BAT0Dyz8aikhr3uG/ajqE0
2b51YxJdfnvnAyEEkAAtpk7RMkgTV3be5ghB0cMQMwAClwKcbQ0VUtlUEEemi0rO
LFEWHQxEuk+phTC93NJN/a5topZAQ2401uTl+prye8niT05H/aSx+7oGXOlLNjXQ
5SCmCExcFzitVDx3O3vUaBbmLKdK0l3Tn7kBGAV4XRhLRXkDaY7lA9+ML19olK7J
x9jvqvJs2CaD3+iJoss2LqNJikIjQ0MOeECwVa8RKZzXCaW35WxP/QQC44teHw3S
lhra+sglrCiiElW7dBp62Jm8o9Qj+wsLBHL881R/rDAm10QmpJ+onbRc2AM0mgVM
JY/S4wpLjtEqDVoj9f80DuuTAEMj4FfhaKAcImLVOMJCQ8oas7fPZ9K/t2abus9j
wWCL8CONclaQ81gZHrEt
=X3gZ
-END PGP SIGNATURE-

Re: Please review draft-housley-rfc2050bis-00.txt

[John Curran]

On Mar 20, 2013, at 3:25 PM, David Farmer  wrote:

> "xxx is obligated to ..." wasn't intended as a suggestions for text, but like 
> I paraphrased the text from the draft above, and I intended it to paraphrase 
> the the text that needs to be added.  The text above quoted from the draft 
> "...such recommendations must be taken into consideration..." and I agree 
> with that.  I'll note the care in how it is worded, but it seems to flow only 
> from IETF to IR System.

The IETF defines the protocols, including the parameter fields.  While
the application of the protocols is up to the community, the IETF does
also on occasional state known technical recommendations or constraints
in usage of its technical standards. The original RFC2050 specified such
technical constraints, the RIR/operator community has generally respected 
them over time, and hence they've been included in the revised text.

> Maybe I'm just being overly sensitive to the "must" in "...such 
> recommendations must be taken into consideration...". But, it seems to me 
> that this says IR System must defer judgements on technical issues to the 
> IETFs technical recommendations, even if they are old, crufty, and been left 
> in dust by the march of technology.

We have existence proof that the Internet Number Registry system is quite
capable of determining when circumstances have changed and while generally
considering important advice, e.g. hierarchical assignment, the registries
have indeed evolved policy as necessary and specified by the community. 

Note also that that the actual text does not at all say "defer judgements 
on technical issues to the IETF's technical recommendations", but instead
that those recommendations must be considered in policy discussions:

 "In addition, in the cases where the IETF sets technical recommendations
  for protocols, practices, or services which are directly related to
  IP address space or AS numbers, such recommendations must be taken
  into consideration in Internet Numbers Registry System policy
  discussions regardless of venue."

I understand that you're seeking assurances that the IETF will dynamically
update any documents that affects the Internet Number Registry System, but
reality is that it takes specific efforts to make that happened (and they
don't always converge with productive output.)  This effort to update RFC2050
is at least a step towards getting better alignment than we have today.

FYI,
/John

Disclaimers: My views alone.   No header fields were harmed in the making
of this email.

Re: Less Corporate Diversity

[Jari Arkko]

I think it is mostly market forces and historical reasons, and the development 
of the IETF to focus on more particular core aspects of the Internet (like 
routing) as opposed to what the small shops might work on.

But I think we are missing a bit of the point in this discussion. I do not feel 
that we need to prove we are somehow "no worse" than industry average. The 
point is that *if* we had more diversity along many of the discussed lines, 
we'd be far better off. For instance, having people from multiple organisations 
provide input to a last would be preferable to just a few. Similarly with the 
other dimensions of diversity. When I talked to some of the ISOC fellows last 
week, I realised peering is very different on different continents. Even if 
there may be less economic activity on networking on those continents, it would 
be good for us to understand the real situations around the world, as opposed 
to thinking the whole world is like where we live. Diversity = good in most 
cases, and increasing that goodness should be the goal.

Jari

Re: Please review draft-housley-rfc2050bis-00.txt

[SM]

At 12:43 20-03-2013, Elwyn Davies wrote:

This contains some woolly hand-waving weasel words at the end:


I looked up the meaning of weasel words and found the following:

  "words and phrases aimed at creating an impression that something specific
   and meaningful has been said, when in fact only a vague or ambiguous claim,
   or even a refutation has been communicated."

I might as well comment quickly about 
draft-housley-rfc2050bis-00.  The draft is a good effort but it might 
need more work in my humble opinion.


The intended status is Informational.  Is there a reason for that?

Why does the document obsolete RFC 2050?  There is no explanation for 
that in the Abstract or the Introduction section.


In Section 2:

   "The Internet Assigned Numbers Authority (IANA) is the traditional
name for the technical team making and publishing the assignments
of Internet protocol technical parameters, including Internet
Protocol (IP) address space."

Is there a reference for that?

   "As a result of a Memorandum of Understanding (MOU)[RFC2860] between
the IETF, IAB, and ICANN, the  technical work of the Internet
Assigned Numbers Authority (IANA) is now performed by ICANN."

According to RFC 2860:

  The memo is "exclusively to define the technical work to be carried
  out by the Internet Assigned Numbers Authority on behalf of the
  Internet Engineering Task Force and the Internet Research Task Force."

That does not match the "as a result" text.

  "Today, IANA administers IP address space and AS numbers according
   to global number resource policies as developed per the agreement
   between ICANN and the Regional Internet Registries [ASOMOU] and
   documented in [ICANNv4], [ICANNv6], and [ICANNASN]."

I don't see what the above has to do with structure (see section title).

In Section 3:

  "Reverse DNS: In situations where reverse DNS was used, the
   policies and practices of the Internet Numbers Registry System
   have included consideration of the technical and operational
   requirements posed by reverse DNS zone delegation [RFC3172]."

According to RFC 5855:

  "The choice of operators for all nameservers concerned is beyond the
   scope of this document and is an IANA function that falls under the
   scope of Section 4 of the MoU between the IETF and ICANN [RFC2860]."

Maybe referencing RFC 5855 would be better.  It may be easier not to 
say anything about reverse DNS.


  "Public WHOIS: The policies and practices of the Internet
   Numbers Registry System have included consideration of the
   technical and operational requirements for supporting WHOIS
   services [RFC3013]."

The specification for Whois is RFC 3912.  I vaguely recall that the 
"policy" text in the previous specification was viewed as problematic 
by the IETF.


  "Per the delineation of responsibility for Internet address policy
   issues specified in the IETF/IAB/ICANN MOU [RFC2860], discussions
   regarding the evolution of the Internet Numbers Registry System
   structure, policy, and processes are to take place within the ICANN
   framework and will respect ICANN's core values [ICANNBL].  These core
   values encourage broad, informed participation reflecting the
   functional, geographic, and cultural diversity of the Internet at all
   levels of policy development and decision-making, as well as the
   delegation of coordination functions and recognition of the policy
   roles of other responsible entities that reflect the interests of
   affected parties.  The discussions regarding Internet Numbers
   Registry evolution must also continue to consider the overall
   Internet address architecture and technical goals referenced in this
   document."

Could someone please translate the above in plain English?  What's 
the IETF angle in all that?


What action is required from IANA in Section 7?

Why should I read RFC 6484 to understand  draft-housley-rfc2050bis-00?

Regards,
-sm 

Re: Less Corporate Diversity

[Jeffrey Haas]

On Wed, Mar 20, 2013 at 03:18:24PM -0400, Eric Burger wrote:
> How much is the concentration of corporate participation in the IETF a
> result of market forces, like consolidation and bankruptcy, as opposed to
> nefarious forces, like a company hiring all of the I* leadership? We have
> mechanisms to deal with the latter, but there is not much we can do about
> the former.

Having started in the IETF at a much smaller vendor, it's less a nefarious
thing than it is a money thing.

When you're talking about participation at the conferences, the cost of
flying someone to the venue, paying for the conference fee and covering
hotel can be a big burden for smaller companies.  They then have to pick and
choose which groups it makes sense to get a human to attend.

Even on-the-list participation can be a financial burden.  Someone has to
spend a chunk of their time doing standards work instead of other things
like code.

I* leadership is even messier.  IETF is effectively asking for half or more
of the time of those people.  They are effectively being given a form of
patronage to do IETF work.

-- Jeff

Re: Please review draft-housley-rfc2050bis-00.txt

[David Farmer]

Whops, that escaped.  Sorry.

Lets start over.

On 3/20/13 15:51 , David Farmer wrote:

On 3/20/13 14:04 , John Curran wrote:

On Mar 19, 2013, at 9:30 PM, David Farmer  wrote:

I wonder if it wouldn't be appropriate to at least provide some
suggestions for how this is to be accomplished.  Maybe request that
future RFCs related to these technical and operational
considerations include an applicability statement as to the
Internet Numbers Registry System, either in a separate section or
maybe as a sub-section of the IANA Considerations.


This evolution is discussed in Section 4.  Maybe a forward pointer
is needed.  Did you not find Section 4 sufficient?


I saw that, it says;

   In addition, in the cases where the IETF sets technical
   recommendations for protocols, practices, or services which are
   directly related to IP address space or AS numbers, such
   recommendations must be taken into consideration in Internet Numbers
   Registry System policy discussions regardless of venue.

This is good, but I read it as saying the IR system, and the RIR's in
particular, are obligated to consider the technical recommendations
of the IETF when making policy.  That is only part of the equation.

I was looking for the other side, "the IETF is obligated to maintain
clear, relevant, and up to date technical recommendations for the IR
system, including how such recommendations are intended to apply to
the IR system."


David -

   Two points:

   1) Language along the lines of "the IETF is obligated to ..." really
  isn't going to work, as the point of the RFC2050 revision is to
  document existing relationships supporting the Internet Numbers
  Registry System, using pointers to existing source documents to
  the greatest extent possible.  Even if there were 100% agreement
  to the concept, it would not be appropriate to establish it via
  this document which is intended for "Informational" publication.


"xxx is obligated to ..." wasn't intended as a suggestions for text, but 
like I paraphrased the text from the draft above, and I intended it to 
paraphrase the the text that needs to be added.  The text above quoted 
from the draft "...such recommendations must be taken into 
consideration..." and I agree with that.  I'll note the care in how it 
is worded, but it seems to flow only from IETF to IR System.


Maybe I'm just being overly sensitive to the "must" in "...such 
recommendations must be taken into consideration...". But, it seems to 
me that this says IR System must defer judgements on technical issues to 
the IETFs technical recommendations, even if they are old, crufty, and 
been left in dust by the march of technology.



   2) More importantly, who is "the IETF" in such a construct?  Would
  such a task (of periodically pondering if these recommendations
  need updating) fall to the IAB or IESG?  (I hadn't realized that
  they needed extra work... ;-)   I believe that when you consider
  that "we" each individually are the IETF (i.e. all of the folks
  who participate in the working groups and writing drafts) then
  it is clear that any "obligation" to update these technical
  recommendations periodically would fall to those with an interest
  in keeping them current.  You might even say that's what Russ,
  David, Geoff, and I are finally getting around to doing via this
  draft, at least for one of the key documents.


This is a common problem of community based, we are them they are us, 
type pseudo-organizations.



FYI,
/John

Disclaimers:  My views alone.  If you are reading this email long
after publication, this email may be out-of-date and I do not commit
to updating its contents. ;-)


All I ask is you admit you changed you mind, you have the right to do 
that.  But, when the IETF changes it's mind by changing its consensus, 
then it needs to deprecate its old technical recommendations, or make 
sure everyone else is free to ignore the recommendations.



--

David Farmer   Email: far...@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952

Thank you to Monique Morrow for her service as ITU-T NGN liaison manager

[Russ Housley]

Next time you see Monique, please thank her for he service the the Internet 
community.


From: IAB Chair [iab-ch...@iab.org]
Sent: Tuesday, March 12, 2013 5:04 PM
To: Monique Morrow
Subject: Thank you for your service as NGN liaison manager

Dear Monique,

The IETF relies on members of the community to volunteer for key roles in our 
organization.  You have provided a great example for this spirit of 
volunteerism through your role as the IETF liaison manager for Next Generation 
Networking (NGN) to the ITU-T.  You provided the ITU-T program valuable 
information about activities in study groups 11 and 13, and provided us the 
opportunity to engage the appropriate people to address early on areas of 
mutual interest to both organizations, in a way that avoided conflict.

The IAB thanks you for this service and we hope that you may be called upon in 
the future for other roles.

On behalf of the IAB,
Bernard Aboba
IAB Chair

Re: Please review draft-housley-rfc2050bis-00.txt

[David Farmer]

On 3/20/13 14:04 , John Curran wrote:

On Mar 19, 2013, at 9:30 PM, David Farmer  wrote:

I wonder if it wouldn't be appropriate to at least provide some suggestions for 
how this is to be accomplished.  Maybe request that future RFCs related to 
these technical and operational considerations include an applicability 
statement as to the Internet Numbers Registry System, either in a separate 
section or maybe as a sub-section of the IANA Considerations.


This evolution is discussed in Section 4.  Maybe a forward pointer is needed.  
Did you not find Section 4 sufficient?


I saw that, it says;

   In addition, in the cases where the IETF sets technical
   recommendations for protocols, practices, or services which are
   directly related to IP address space or AS numbers, such
   recommendations must be taken into consideration in Internet Numbers
   Registry System policy discussions regardless of venue.

This is good, but I read it as saying the IR system, and the RIR's in 
particular, are obligated to consider the technical recommendations of the IETF 
when making policy.  That is only part of the equation.

I was looking for the other side, "the IETF is obligated to maintain clear, 
relevant, and up to date technical recommendations for the IR system, including how such 
recommendations are intended to apply to the IR system."


David -

   Two points:

   1) Language along the lines of "the IETF is obligated to ..." really
  isn't going to work, as the point of the RFC2050 revision is to
  document existing relationships supporting the Internet Numbers
  Registry System, using pointers to existing source documents to
  the greatest extent possible.  Even if there were 100% agreement
  to the concept, it would not be appropriate to establish it via
  this document which is intended for "Informational" publication.


"xxx is obligated to ..." wasn't intended as a suggestions for text, but 
like I paraphrased the text from the draft above, and I intended it to 
paraphrase the the text that needs to be added.  The text above quoted 
from the draft "such recommendations must be taken into 
consideration..." and I agree with that.  I'll note the care in how it 
is worded, but it seems to flow only IETF to IR Sys



   2) More importantly, who is "the IETF" in such a construct?  Would
  such a task (of periodically pondering if these recommendations
  need updating) fall to the IAB or IESG?  (I hadn't realized that
  they needed extra work... ;-)   I believe that when you consider
  that "we" each individually are the IETF (i.e. all of the folks
  who participate in the working groups and writing drafts) then
  it is clear that any "obligation" to update these technical
  recommendations periodically would fall to those with an interest
  in keeping them current.  You might even say that's what Russ,
  David, Geoff, and I are finally getting around to doing via this
  draft, at least for one of the key documents.





FYI,
/John

Disclaimers:  My views alone.  If you are reading this email long
after publication, this email may be out-of-date and I do not commit
to updating its contents. ;-)







--

David Farmer   Email: far...@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952

Re: Is there a Git repository of RFCs? Or of Internet-Drafts?

[Dale R. Worley]

Rob Evans mentions that there is documentation on using rsync to get
RFCs and internet drafts:

http://www.rfc-editor.org/rsync-help.html

After some testing, rsync works well for me.  I use

rsync --stats -az --delete --exclude=ien \
ftp.rfc-editor.org::rfcs \
~/in-notes

# Use --ignore-existing to prevent I-Ds from being deleted or replaced with
# tombstones.
rsync --stats -az --ignore-existing \
ftp.rfc-editor.org::internet-drafts \
~/internet-drafts

Dale

Re: Diversity of IETF Leadership

[Jeffrey Haas]

On Wed, Mar 20, 2013 at 03:13:01PM -0400, Sam Hartman wrote:
> Part of what I meant when I signed the diversity letter was to state a belief
> that within a pool of qualified candidates, I believe diversity is
> important enough that it is valuable to select for diversity even if
> this does not maximize the skills that you enumerated (tech skill, admin
> skill, works with others and something else).

"Maximize" overstates my position.  My belief is once the base requirements
are met that diversity is an appropriate tie-breaker.  Maximizing the four I
mentioned is different.

-- Jeff

Re: Diversity of IETF Leadership

[Arturo Servin]

On 3/20/13 12:17 PM, Scott Brim wrote:
> On 03/20/13 15:16, Jorge Contreras allegedly wrote:
>> I would strongly recommend that legal counsel be consulted before any
>> such "list" is produced or used by IETF/IESG/Nomcom.
> 
> Or don't generate it at all.  Trying to have a complete list of human
> attributes to diversify to looks like an engineer's reflex.  We know
> what we want to do in principle.
> 

+1

Please, do not go to bureaucracy and legal side of this. Let's keep it
simple and based on our principles and not in legalities.

as

Re: Please review draft-housley-rfc2050bis-00.txt

[Arturo Servin]

I interpret it as anybody.

ISPs, cctlds, governments, gtlds, IETF, RIRs, ICANN, ISOC, you, me.

/as

On 3/20/13 4:43 PM, Elwyn Davies wrote:
> This contains some woolly hand-waving weasel words at the end:
> 
>> > Over the years, the Internet Numbers Registry System has developed
>> >mechanisms by which the structures, policies, and processes of the
>> >Internet Numbers Registry System itself can evolve to meet the
>> >changing demands of the global Internet community.  Further evolution
>> >of the Internet Numbers Registry System is expected to occur in an
>> >open, transparent, and broad multi-stakeholder manner.
> ^^^
> Who are these stakeholders?  Is this (just) the organisations named in
> the document (I think that would be ICANN/IANA, IETF, *IRs - a large
> number!) or is the community to be consulted? and governments?  So do we
> have a view as to how all these people are to be informed that some
> evolution is needed?

Re: Please review draft-housley-rfc2050bis-00.txt

[Elwyn Davies]

Hi, Russ.
Two points:

On Tue, 2013-03-19 at 22:30 -0500, David Farmer wrote:

> 
> Rereading things again, I have another suggestion;
> 
> 4) Split the Goals of the Internet registry system out of the 
> Introduction.  The Intro starts out talking about the document, its 
> goals, and what is in scope and out of scope of the document.  Then 
> transitions to talking about the goals of the Internet registry system. 
>   I think the goals of the Internet registry system should be a separate 
> section from the Introduction. And, the Introduction should be expanded 
> to better describe the purpose of the document.

I agree fully with this comment.  The first para of s1 needs a rewrite
and a little expansion to match up with the abstract to form a proper
intro.  The goals do belong in a separate section
> 

Also regarding the first para of s4:

This contains some woolly hand-waving weasel words at the end:

> Over the years, the Internet Numbers Registry System has developed
>mechanisms by which the structures, policies, and processes of the
>Internet Numbers Registry System itself can evolve to meet the
>changing demands of the global Internet community.  Further evolution
>of the Internet Numbers Registry System is expected to occur in an
>open, transparent, and broad multi-stakeholder manner.
^^^
Who are these stakeholders?  Is this (just) the organisations named in
the document (I think that would be ICANN/IANA, IETF, *IRs - a large
number!) or is the community to be consulted? and governments?  So do we
have a view as to how all these people are to be informed that some
evolution is needed?

Regards,
Elwyn

Re: Diversity of IETF Leadership

[Jeffrey Haas]

On Wed, Mar 20, 2013 at 12:01:41PM -0700, Dan Harkins wrote:
> > For candidates wherein the above things are roughly equal - or have
> > exceeded
> > the requirements - diversity is a possible tie-breaker.  If the intent is
> > to
> > emphasize diversity (for some metric) over one of the core skills, that's
> > certainly possible.
> 
>   By "that", I take it you mean it's certainly possible to discriminate in
> favor
> some metric of diversity and against a core skill. So? Is that the intent?
> 
>   There is quite a bit of dancing around this subject and it would be nice
> to say what we all mean here. If you're proposing that IETF start the
> practice of discriminating against certain people then say so.

Have care, you're close to putting words in my mouth. :-)

If what you mean is that emphasizing diversity over a core skill with
respect to selection of people for positions of responsibility is a form of
discrimination, that's how some people have presented it.  I.e. "affirmative
action".

If you're asking for my personal opinion, I think we should stick to meeting
core criteria minimums and that among candidates that meet those
requirements consider diversity as one of the criteria.

>   You snipped my other question. So let me ask again. What do we do
> if, after ensuring that there's a diverse candidate pool that satisfies the
> minimum core skills needed for positions, 

Good start for a presumption.

> the end result is more white men?

I believe you, and many others, are inferring over much with regard to
diversity from the black box that is NomCom.

Unfortunately that is a big ugly part of this whole discussion.  Part
of the perception here is the the NomCom is fed a candidate pool and the
output mostly matches beliefs that diversity is not an input.  It's like any
other job interview - you only know you don't get the job.  You may know who
did.  Without getting someone on the hiring committe to talk about why the
person in question is selected, you can only speculate as to why you weren't
selected.  

If instead you (or someone else) is going to argue that given an input of a
set of candidates that match some crtieria of diversity that it is a
requirement that the output include something that meets that diversity
criteria, then pick your word for that result.

>   Do we stop with the pretense of ensuring diversity of opportunity
> and just proceed to diversity of result? Do we enshrine the "soft bigotry
> of low expectations"?

Or we define our requirements for the outputs of the process and stop
speculating about the black box.  C.f. the tsvarea discussion on what they
want out of an AD.

-- Jeff

Re: Less Corporate Diversity

[tsg]

On 03/20/2013 12:18 PM, Eric Burger wrote:

How much is the concentration of corporate participation in the IETF a result 
of market forces, like consolidation and bankruptcy, as opposed to nefarious 
forces, like a company hiring all of the I* leadership? We have mechanisms to 
deal with the latter, but there is not much we can do about the former.
Sure you can - you can put in place formal requirements for disclosure 
and actually make licenses which are recallable for frauds or other bad 
acts in the process.


The issue isnt whether the goal of the IETF is a laudable one or not - 
it clearly is, the issue is whether the IETF itself is responsible for 
actions which its infrastructure is used to control are allowed or not 
and what the issues for threshold of damages are.


Bluntly this IETF has no statistical idea on any of these things because 
it has intentionally put in place controls which are either too complex 
to implement or are glad-handed and ignored like the BCP78/79 rules 
which say "All parties speak regularly with their sponsors legal 
departments to keep them abreast on changes or things of interest in the 
standards process"... (yeah right...).


No really - its about time everything here got locked down so everything 
is open and a little-guy really can submit and promulgate a technology 
through standardization.


Todd

Less Corporate Diversity

[Eric Burger]

How much is the concentration of corporate participation in the IETF a result 
of market forces, like consolidation and bankruptcy, as opposed to nefarious 
forces, like a company hiring all of the I* leadership? We have mechanisms to 
deal with the latter, but there is not much we can do about the former.

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Diversity of IETF Leadership

[Sam Hartman]

Part of what I meant when I signed the diversity letter was to state a belief
that within a pool of qualified candidates, I believe diversity is
important enough that it is valuable to select for diversity even if
this does not maximize the skills that you enumerated (tech skill, admin
skill, works with others and something else).

Re: [IETF] Getting rid of the dot (was: Mentoring)

[Warren Kumari]

On Mar 19, 2013, at 11:19 AM, Carsten Bormann  wrote:

> On Mar 19, 2013, at 13:22, Michael Richardson  wrote:
> 
>> Instead of getting a new badge every meeting, maybe we should just get
>> an IETF86 dot on a badge we keep from meeting to meeting.
> 
> I want my badge on a shiny embossed metal plate with the words "protocol 
> police" on it.
> Where do I have to apply?

Will increase your meeting fee by ~$45, but here you go…

http://www.visualbadge.com/BuildBadge_ViewPic2.aspx?badge=FB46&base=silver&textfont=block&textcolor=black&text1=I.E.T.F&text2=PROTOCOL&text3=&text4=POLICE&text5=BCP38&text6=&seal=C998M&textsep=NONE&aff=A128&back=&finish=NICKEL+ELECTROPLATE&qtyb=1&etype=SOFT+(REGULAR)&att=BADGE+ONLY+(PIN+BACK)&sh=CURVED&specins=&price=39.50&l=&pricel=&qtyl=0&textsep=NONE&bsize=Dimensions+(w+x+h)%3a+1.25''+X+1.75''&limpr=-LEAVE+BLANK-¢ertype=MULTI+COLOR

W


> 
> Grüße, Carsten
> 

--
"Go on, prove me wrong. Destroy the fabric of the universe. See if I care."  -- 
Terry Prachett 

Re: Please review draft-housley-rfc2050bis-00.txt

[John Curran]

On Mar 19, 2013, at 9:30 PM, David Farmer  wrote:
>>> I wonder if it wouldn't be appropriate to at least provide some suggestions 
>>> for how this is to be accomplished.  Maybe request that future RFCs related 
>>> to these technical and operational considerations include an applicability 
>>> statement as to the Internet Numbers Registry System, either in a separate 
>>> section or maybe as a sub-section of the IANA Considerations.
>> 
>> This evolution is discussed in Section 4.  Maybe a forward pointer is 
>> needed.  Did you not find Section 4 sufficient?
> 
> I saw that, it says;
> 
>   In addition, in the cases where the IETF sets technical
>   recommendations for protocols, practices, or services which are
>   directly related to IP address space or AS numbers, such
>   recommendations must be taken into consideration in Internet Numbers
>   Registry System policy discussions regardless of venue.
> 
> This is good, but I read it as saying the IR system, and the RIR's in 
> particular, are obligated to consider the technical recommendations of the 
> IETF when making policy.  That is only part of the equation.
> 
> I was looking for the other side, "the IETF is obligated to maintain clear, 
> relevant, and up to date technical recommendations for the IR system, 
> including how such recommendations are intended to apply to the IR system."

David - 

  Two points:

  1) Language along the lines of "the IETF is obligated to ..." really 
 isn't going to work, as the point of the RFC2050 revision is to 
 document existing relationships supporting the Internet Numbers
 Registry System, using pointers to existing source documents to
 the greatest extent possible.  Even if there were 100% agreement
 to the concept, it would not be appropriate to establish it via
 this document which is intended for "Informational" publication.

  2) More importantly, who is "the IETF" in such a construct?  Would 
 such a task (of periodically pondering if these recommendations
 need updating) fall to the IAB or IESG?  (I hadn't realized that 
 they needed extra work... ;-)   I believe that when you consider 
 that "we" each individually are the IETF (i.e. all of the folks 
 who participate in the working groups and writing drafts) then 
 it is clear that any "obligation" to update these technical 
 recommendations periodically would fall to those with an interest 
 in keeping them current.  You might even say that's what Russ,
 David, Geoff, and I are finally getting around to doing via this
 draft, at least for one of the key documents.

FYI,
/John

Disclaimers:  My views alone.  If you are reading this email long 
after publication, this email may be out-of-date and I do not commit
to updating its contents. ;-)

Re: Diversity of IETF Leadership

[Dan Harkins]

On Wed, March 20, 2013 10:01 am, Jeffrey Haas wrote:
> On Wed, Mar 20, 2013 at 09:01:01AM -0700, Dan Harkins wrote:
>> On Wed, March 20, 2013 8:35 am, Dave Crocker wrote:
>> > ps.  A small point to watch for, if there is a focus on a defined list
>> > of groups, is the difference between discriminating /against/, versus
>> > ensuring representation /from/.  Active prohibition vs. active
>> > solicitation.  The exchange between Margaret and Stuart seemed to mix
>> > these.  We need to be careful about the distinction.
>>
>>   I have been viewing this as the difference between discriminating
>> against versus discriminating for. And I am against discrimination,
>> even that done for the best of intentions.
>
> This is certainly the biggest challenge of any intent to include diversity
> (of any form) in the mix.
>
> In general, we want the best people in the job in question.  What is
> "best"
> depends on the position (chair, I*, etc.) but as a technical organization
> that runs on documents, several things will bubble to the top:
> - Technical clue in the matter at hand.
> - Reasonable administrative skills.
> - Ability to work with others.
> - Solid communication skills.
>
> For candidates wherein the above things are roughly equal - or have
> exceeded
> the requirements - diversity is a possible tie-breaker.  If the intent is
> to
> emphasize diversity (for some metric) over one of the core skills, that's
> certainly possible.

  By "that", I take it you mean it's certainly possible to discriminate in
favor
some metric of diversity and against a core skill. So? Is that the intent?

  There is quite a bit of dancing around this subject and it would be nice
to say what we all mean here. If you're proposing that IETF start the
practice of discriminating against certain people then say so.

> The primary challenge then is making sure there is a diverse candidate
> pool
> that satisfies the minimum core skills needed for the positions.  See
> prior
> discussion on mentoring.

  You snipped my other question. So let me ask again. What do we do
if, after ensuring that there's a diverse candidate pool that satisfies the
minimum core skills needed for positions, the end result is more white
men?  Do we stop with the pretense of ensuring diversity of opportunity
and just proceed to diversity of result? Do we enshrine the "soft bigotry
of low expectations"?

  Dan.

Re: Diversity of IETF Leadership

[Dave Crocker]

On 3/20/2013 10:53 AM, Jeffrey Haas wrote:

On Wed, Mar 20, 2013 at 10:09:41AM -0700, Dave Crocker wrote:

Also note that your list is missing something that was raised
earlier in the thread, namely the difference between local
optimization versus 'global'.  There are benefits in having a group
mixture that can be far more important than the attributes of the
group members taken individually.


Probably because I don't buy wholly into that argument - or at least the
argument it makes us "smarter".



Then I encourage you to do more reading.  It's not a marginal or 
controversial point, among folk who do research in the relevant fields.


d/

--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: Diversity of IETF Leadership

[Keith Moore]

On 03/20/2013 12:21 PM, Mary Barnes wrote:

On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore
 wrote:

On 03/20/2013 11:41 AM, Mary Barnes wrote:

Given that folks are still debating whether this years nominees
reflected a reasonable diversity (there were 9 women out of 37
nominees),

I actually don't think that the number of female nominees is relevant.
What is relevant is the number of qualified female nominees who had the
willingness, the availability, the required expertise, and the support
necessary to fill the position.

[MB] Sure. But, I know of at least two that I don't think or would
hope anyone would debate were qualified in all the areas you suggest. Both have 
contributed
significantly to IETF in a variety
of leadership positions.
Sure, but that doesn't mean that they have sufficient time or employer 
support to do the job now.   And there's no way that someone like you or 
me can reliably know whether that's the case. That has to be something 
that's kept confidential between the nominee and the nomcom.




One concept that is not very well understood, however, is the basic
fact that women
work differently than men and thus expecting us to fit the cookie
cutter of IETF leaders isn't quite
appropriate.


To be clear: I wasn't arguing about that aspect at all, just about 
whether it's reasonable to look at a slate of nominees and compare that 
to the slate of people selected and make inferences about the role of 
gender in the nomcom's decision process.


I'm also not presuming that just because there were no women in the 
latest set of appointees to IESG, that it's because the current nomcom 
didn't think that women could "fit the cookie cutter".   I don't have 
and don't pretend to have the ability to read their minds.   In general 
I think that presumptions that require the ability to read specific 
people's minds should be dismissed out-of-hand as irrelevant and perhaps 
insulting.   People can imagine or project what they like, but what 
people imagine or project should never be confused with reality.



   To be told by a nomcom voting member, when I mention
this fact, that this just isn't so because IETF is a meritocracy is
insulting and shows a sheer lack of respect for the value that
diversity brings to an organization.


Respectfully disagree.

We expect the nomcom to balance lots of different considerations when 
choosing IESG and other appointees, AND we expect them to keep their 
deliberations confidential.   Gender is definitely a valid 
consideration, but it's only one consideration, and at least a dozen 
others have been mentioned.   To look at the nomcom result through the 
aperture of only one or two of those considerations, and then make a 
statement about the nature of their imagined gender bias strikes me as 
pure speculation.


I certainly hope that the nomcom doesn't believe that women can't do the 
jobs.  Our community has ample evidence and decades of experience that 
they can.  I served with several women when I was on IESG and found all 
of them to be capable and professional in every respect.


Note also that the process for selecting the nomcom is inherently 
gender-neutral, at least to the extent that the requirement for nomcom 
attendance at prior IETF meetings doesn't impose a gender barrier.


[MB] You have to keep in mind in the past that the there were
"dummies" in the nominee pool before open list.  I was explicitly told
by this year's nomcom chair that they were not doing that. Thus, I
would anticipate that the majority of those in the pool this year were
willing and able.[/MB]


That helps a bit, but I still don't think it supports an assertion of 
gender bias in the nomcom's process.


Keith

Re: Diversity of IETF Leadership

[Jeffrey Haas]

On Wed, Mar 20, 2013 at 10:09:41AM -0700, Dave Crocker wrote:
> On 3/20/2013 10:01 AM, Jeffrey Haas wrote:
> >In general, we want the best people in the job in question.  What is "best"
> >depends on the position (chair, I*, etc.) but as a technical organization
> >that runs on documents, several things will bubble to the top:
> >- Technical clue in the matter at hand.
> >- Reasonable administrative skills.
> >- Ability to work with others.
> >- Solid communication skills.
> 
> 
> Note the 3 of the 4 items on your list are not a matter of technical
> skill.

Agreed, although it is probably understood that technical clue tends to be
pretty high on the list in terms of weight.  

The overlap of those (IMO) core skills and diversity (for some metric
thereof) is present.  Regardless of the reason someone has a given skill,
the skill itself is the functional requirement.

> Also note that your list is missing something that was raised
> earlier in the thread, namely the difference between local
> optimization versus 'global'.  There are benefits in having a group
> mixture that can be far more important than the attributes of the
> group members taken individually.

Probably because I don't buy wholly into that argument - or at least the
argument it makes us "smarter".  A broader source of opinions is always a
good thing and I believe that is one of the things that diversity brings us.

To draw a very geekish analogy, I tend to find that diversity helps only a
little on the "intelligence" of a group.  It does wonders for the "wisdom"
of the group. :-)

-- Jeff

Re: Diversity of IETF Leadership

[Dave Crocker]

On 3/20/2013 10:01 AM, Jeffrey Haas wrote:

In general, we want the best people in the job in question.  What is "best"
depends on the position (chair, I*, etc.) but as a technical organization
that runs on documents, several things will bubble to the top:
- Technical clue in the matter at hand.
- Reasonable administrative skills.
- Ability to work with others.
- Solid communication skills.



Note the 3 of the 4 items on your list are not a matter of technical 
skill.


Also note that your list is missing something that was raised earlier in 
the thread, namely the difference between local optimization versus 
'global'.  There are benefits in having a group mixture that can be far 
more important than the attributes of the group members taken individually.


d/
--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: Diversity of IETF Leadership

[Jeffrey Haas]

On Wed, Mar 20, 2013 at 09:01:01AM -0700, Dan Harkins wrote:
> On Wed, March 20, 2013 8:35 am, Dave Crocker wrote:
> > ps.  A small point to watch for, if there is a focus on a defined list
> > of groups, is the difference between discriminating /against/, versus
> > ensuring representation /from/.  Active prohibition vs. active
> > solicitation.  The exchange between Margaret and Stuart seemed to mix
> > these.  We need to be careful about the distinction.
> 
>   I have been viewing this as the difference between discriminating
> against versus discriminating for. And I am against discrimination,
> even that done for the best of intentions.

This is certainly the biggest challenge of any intent to include diversity
(of any form) in the mix.

In general, we want the best people in the job in question.  What is "best"
depends on the position (chair, I*, etc.) but as a technical organization
that runs on documents, several things will bubble to the top:
- Technical clue in the matter at hand.
- Reasonable administrative skills.
- Ability to work with others.
- Solid communication skills.

For candidates wherein the above things are roughly equal - or have exceeded
the requirements - diversity is a possible tie-breaker.  If the intent is to
emphasize diversity (for some metric) over one of the core skills, that's
certainly possible.  

The primary challenge then is making sure there is a diverse candidate pool
that satisfies the minimum core skills needed for the positions.  See prior
discussion on mentoring.

(Note that the above observations were things I had intended to say at the
administrative plenary, but I appeared to be standing at the invisible mic.)

-- Jeff

Re: Diversity of IETF Leadership

[Spencer Dawkins]

On 3/20/2013 11:21 AM, Mary Barnes wrote:

On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore
 wrote:



So I guess I've formed the impression that merely being nominated for a
position doesn't really mean that a person is available.

[MB] You have to keep in mind in the past that the there were
"dummies" in the nominee pool before open list.  I was explicitly told
by this year's nomcom chair that they were not doing that. Thus, I
would anticipate that the majority of those in the pool this year were
willing and able.[/MB]


Both of you are right, of course.

Before OpenList, the list of nominees willing to be considered was 
treated as confidential. Nomcoms that wanted to ask for input on 
specific people sent out lists of nominees that were padded, as Keith 
says, so that there were "dummies" (usually described as "ringers"), and 
theoretically no one outside Nomcom knew precisely who was being considered.


When we approved http://www.rfc-editor.org/rfc/rfc5680.txt in 2009, it 
added this text to RFC 3777:


  The list of nominees willing to be considered for positions under
  review in the current NomCom cycle is not confidential.  The
  NomCom may disclose a list of names of nominees who are willing to
  be considered for positions under review to the community, in
  order to obtain feedback from the community on these nominees.

> The list of nominees disclosed for a specific position should
> contain only the names of nominees who are willing to be
> considered for the position under review.

  The NomCom may choose not to include some names in the disclosed
  list, at their discretion.

  The NomCom may disclose an updated list, at their discretion.  For
  example, the NomCom might disclose an updated list if the NomCom
  identifies errors/omissions in a previously disclosed version of
  the disclosed list, or if the NomCom finds it necessary to call
  for additional nominees, and these nominees indicate a willingness
  to be considered before the NomCom has completed its
  deliberations.

  Nominees may choose to ask people to provide feedback to the
  NomCom, but should not encourage any public statements of support.
  NomComs should consider nominee-encouraged lobbying and
  campaigning to be unacceptable behavior.

  IETF community members are encouraged to provide feedback on
  nominees to the NomCom, but should not post statements of support/
  non-support for nominees in any public forum.

So, the assumption before 2009 was that lists were padded, and the 
assumption after 2009 is that lists aren't padded. The Nomcom can do 
what seems right, of course.


Spencer

Re: Diversity of IETF Leadership

[Mary Barnes]

On Wed, Mar 20, 2013 at 11:10 AM, Keith Moore
 wrote:
> On 03/20/2013 11:41 AM, Mary Barnes wrote:
>>
>> Given that folks are still debating whether this years nominees
>> reflected a reasonable diversity (there were 9 women out of 37
>> nominees),
>
> I actually don't think that the number of female nominees is relevant.
> What is relevant is the number of qualified female nominees who had the
> willingness, the availability, the required expertise, and the support
> necessary to fill the position.
[MB] Sure. But, I know of at least two that I don't think or would
hope anyone would debate
were qualified in all the areas you suggest. Both have contributed
significantly to IETF in a variety
of leadership positions.   I do not believe at least one of the
choices would have
stood up against scrutiny by my own HR dept.  Certainly, you have
opinions, as does the IETF population that is in the  majority, as to
what makes one qualified.
One concept that is not very well understood, however, is the basic
fact that women
work differently than men and thus expecting us to fit the cookie
cutter of IETF leaders isn't quite
appropriate.   To be told by a nomcom voting member, when I mention
this fact, that this just isn't so because IETF is a meritocracy is
insulting and shows a sheer lack of respect for the value that
diversity brings to an organization.
[/MB]
>
> On several occasions in the past decade I've been asked if I were willing to
> be nominated to serve on IESG again, even though I didn't have either
> sufficient time or support to devote to the task, just so that nomcom would
> have a slate of candidates to compare.   I thought on those occasions, and
> still think, that it's a bit silly to ask nomcom to investigate candidates
> who don't have the time or support to do the job.   But I still agreed to be
> nominated because I could also see some value in having nomcom compare
> several candidates.  (Just like when shopping for a new car, it doesn't hurt
> to look at models that you know that you're probably not going to buy, just
> to get a sense of whether you really want what you think you want).
>
> So I guess I've formed the impression that merely being nominated for a
> position doesn't really mean that a person is available.
[MB] You have to keep in mind in the past that the there were
"dummies" in the nominee pool before open list.  I was explicitly told
by this year's nomcom chair that they were not doing that. Thus, I
would anticipate that the majority of those in the pool this year were
willing and able.[/MB]
>
> Keith
>

Re: Diversity of IETF Leadership

[Keith Moore]

On 03/20/2013 11:41 AM, Mary Barnes wrote:

Given that folks are still debating whether this years nominees
reflected a reasonable diversity (there were 9 women out of 37
nominees),
I actually don't think that the number of female nominees is 
relevant.What is relevant is the number of qualified female nominees 
who had the willingness, the availability, the required expertise, and 
the support necessary to fill the position.


On several occasions in the past decade I've been asked if I were 
willing to be nominated to serve on IESG again, even though I didn't 
have either sufficient time or support to devote to the task, just so 
that nomcom would have a slate of candidates to compare.   I thought on 
those occasions, and still think, that it's a bit silly to ask nomcom to 
investigate candidates who don't have the time or support to do the 
job.   But I still agreed to be nominated because I could also see some 
value in having nomcom compare several candidates.  (Just like when 
shopping for a new car, it doesn't hurt to look at models that you know 
that you're probably not going to buy, just to get a sense of whether 
you really want what you think you want).


So I guess I've formed the impression that merely being nominated for a 
position doesn't really mean that a person is available.


Keith

Re: Diversity of IETF Leadership

[Spencer Dawkins]

I'm somewhat worried at the lurch this thread has taken into the land of 
protected classes, legal advice, etc. I hope we do not go there.


Having said that ... since Eric asked ...

On 3/20/2013 9:57 AM, Eric Burger wrote:
> Going a bit over-the-top: is there an interaction between sex and 
sexual orientation? Can one count as the other?


I'm not answering as an IAB member, but as co-president of PFLAG Dallas 
("Parents, Families and Friends of Lesbians, Gays, Bisexuals and 
Transgenders") ...


PFLAG includes "sexual orientation" under "sexual orientation, gender 
identity and expression". Each of these terms means something different, 
and all of these can be distinct from birth gender.


So, PFLAG would suggest that we treat gender and "sexual orientation, 
gender identity and expression" interchangeably.


Spencer

(www.pflag.org)

Re: Diversity of IETF Leadership

[Dan Harkins]

  Hi Dave,

On Wed, March 20, 2013 8:35 am, Dave Crocker wrote:
> ps.  A small point to watch for, if there is a focus on a defined list
> of groups, is the difference between discriminating /against/, versus
> ensuring representation /from/.  Active prohibition vs. active
> solicitation.  The exchange between Margaret and Stuart seemed to mix
> these.  We need to be careful about the distinction.

  I have been viewing this as the difference between discriminating
against versus discriminating for. And I am against discrimination,
even that done for the best of intentions.

  Active solicitation is all well and good but how do you _ensure_
representation of members from a defined list of groups if your
active solicitation does not result in the favored mix?

  Dan.

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

Re: Diversity of IETF Leadership

[Mary Barnes]

I don't think anyone is asking for strict compliance to a particular
country's laws, although, one could debate that since ISOC is the
mother organization for IETF that it might be reasonable to look at
the laws in the regions where ISOC is incorporated. My understanding,
however, is that since IETF is a non-profit, there is no requirement
for them to comply with any of these laws (at least in the US),
although one could debate the fact that the US DoD provides funds to
ISOC such might be required.

Given that folks are still debating whether this years nominees
reflected a reasonable diversity (there were 9 women out of 37
nominees), it does seem that finding a description of diversity
criteria that is considered by other professional organizations is not
a bad idea.However, given the direction of most of these threads,
I'm beginning to be of the same mindset as John:
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=68058&tid=1363793904

Regards,
Mary.

On Wed, Mar 20, 2013 at 9:34 AM, Richard Barnes  wrote:
> I do not really think the legal angle is helpful in resolving this problem.
> (Which country's laws do we need to comply with?)  Let's treat these legal
> ideas as considerations that we should be thinking about, not something
> where we should be striving for strict compliance.
>
> --Richard
>
>
>
> On Wed, Mar 20, 2013 at 10:27 AM, Mary Barnes 
> wrote:
>>
>> On Wed, Mar 20, 2013 at 9:16 AM, Jorge Contreras 
>> wrote:
>> > On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman 
>> > wrote:
>> >>
>> >>
>> >> Hi Stewart,
>> >>
>> >> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
>> >> > Age
>> >> > Disability
>> >> > Gender reassignment
>> >> > Marriage and civil partnership
>> >> > Pregnancy and maternity
>> >> > Race
>> >> > Religion and belief
>> >> > Sex
>> >> > Sexual orientation
>> >>
>> >> The U.S. has a similar (although not identical) list, and it may vary a
>> >> bit state-by-state.
>> >> >
>> >> > If we are going to have an itemized list of diversity
>> >> > characteristics,
>> >> > we should not pick and choose, we should include the full list.
>> >
>> >
>> > I would strongly recommend that legal counsel be consulted before any
>> > such
>> > "list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is totally
>> > outside my own area of legal expertise, so IAOC would need to incur some
>> > expense to hire competent counsel in this area)
>> [MB] I agree 100%.  IETF is not at all qualified to define hiring
>> criteria or practices. Unfortunately, they do it all the time.  The
>> model in place IMHO would not stand up to the scrutiny of any major US
>> company's HR dept.  And, of course, the HR departments are the ones
>> responsible for ensuring the laws in a specific area are met.   [/MB]
>> >
>> >>
>> >>
>> >> While I certainly wouldn't suggest we start discriminating based on
>> >> _any_
>> >> of these factors, it is very difficult to measure our results in some
>> >> of
>> >> these areas, as we do not collect this information from IETF attendees,
>> >> nor
>> >> do we publish the age, disability status, gender status, marital
>> >> status,
>> >> religion or sexual orientation of our I* members.
>> >
>> >
>> > What records *do* exist regarding the identify of IETF leadership?  Is
>> > there
>> > a central repository of at least names/companies of IESG members and/or
>> > WG
>> > leaders?
>
>

Re: Diversity of IETF Leadership

[Dave Crocker]

On 3/20/2013 4:33 AM, Eliot Lear wrote:

Let's not play Internet lawyers about this.  How Jari's design team
bring in real lawyers at the appropriate time?



Or not.

There's an important choice between focusing on the sufficiency of 
representation from a defined set of population groups, versus focusing 
on the need for true diversity and the means of achieving it.


The former is a numbers game and produces soulless mechanics that can't 
possibly be constructive, in a group as small and specialized as ours.


The latter is a culture game and actively seeks as a rich range of 
perspectives as practical, knowing that it can't get /all/ perspectives.



d/

ps.  A small point to watch for, if there is a focus on a defined list 
of groups, is the difference between discriminating /against/, versus 
ensuring representation /from/.  Active prohibition vs. active 
solicitation.  The exchange between Margaret and Stuart seemed to mix 
these.  We need to be careful about the distinction.


--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: Diversity of IETF Leadership

[Mary Barnes]

As I understand it, Jorge is highlighting that he is not an expert in
employment and Equal opportunity law.  That is a specific expertise.

On Wed, Mar 20, 2013 at 10:20 AM, tsg  wrote:
> On 03/20/2013 07:16 AM, Jorge Contreras wrote:
>
> On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman 
> wrote:
>>
>>
>
> Jorge - did I miss something here - isnt this your job? If not why are you
> here?
>
> Let me respond that further -  I believe that there are any number of both
> privacy and transparency counsel's in the movement so to speak who would
> love to work with such a body to create a transparent set of participation
> rules UNDER THE CURRENT PARTICIPATION MODELS AS BROKEN AS THEY ARE...
>
> Didnt you file an ID yourself not to long ago?  In fact I am betting
> Professor you know any number of Grad Students who would love such a job if
> you catch my drift.
>
> Todd
>
>
>> Hi Stewart,
>>
>> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
>> > Age
>> > Disability
>> > Gender reassignment
>> > Marriage and civil partnership
>> > Pregnancy and maternity
>> > Race
>> > Religion and belief
>> > Sex
>> > Sexual orientation
>>
>> The U.S. has a similar (although not identical) list, and it may vary a
>> bit state-by-state.
>> >
>> > If we are going to have an itemized list of diversity characteristics,
>> > we should not pick and choose, we should include the full list.
>
>
> I would strongly recommend that legal counsel be consulted before any such
> "list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is totally
> outside my own area of legal expertise, so IAOC would need to incur some
> expense to hire competent counsel in this area)
>
>>
>>
>> While I certainly wouldn't suggest we start discriminating based on _any_
>> of these factors, it is very difficult to measure our results in some of
>> these areas, as we do not collect this information from IETF attendees, nor
>> do we publish the age, disability status, gender status, marital status,
>> religion or sexual orientation of our I* members.
>
>
> What records *do* exist regarding the identify of IETF leadership?  Is there
> a central repository of at least names/companies of IESG members and/or WG
> leaders?
>
>

Re: Diversity of IETF Leadership

[Dan Harkins]

On Wed, March 20, 2013 7:16 am, Jorge Contreras wrote:
> On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman
> wrote:
>
>>
>> Hi Stewart,
>>
>> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
>> > Age
>> > Disability
>> > Gender reassignment
>> > Marriage and civil partnership
>> > Pregnancy and maternity
>> > Race
>> > Religion and belief
>> > Sex
>> > Sexual orientation
>>
>> The U.S. has a similar (although not identical) list, and it may vary a
>> bit state-by-state.
>> >
>> > If we are going to have an itemized list of diversity characteristics,
>> we should not pick and choose, we should include the full list.
>>
>
> I would strongly recommend that legal counsel be consulted before any such
> "list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is totally
> outside my own area of legal expertise, so IAOC would need to incur some
> expense to hire competent counsel in this area)

  Great, now the lawyers are getting involved. A sure sign this has gone
way too far.

  The factors listed above are those that an employer cannot discriminate
on. It says nothing about diversity or the alleged benefits that diversity
brings to a group. For example, a company is prohibited from not hiring
someone because he or she is Catholic but it does not mean that the
company must work to have some arbitrary percentage of Catholics in
leadership positions or among the general workforce.

  Absent any evidence  of discrimination there is Disparate Impact
Theory which says that the mere fact that a process produces a result
that does not satisfy an arbitrary goal with respect to a protected
group is justification for actively discriminating in favor of that
protected group to "balance" it all out. I really, really hope that is
not where we are going in the IETF. It would wreck this organization
if we had a committee that performed such a blatantly political activity.

  If that is not where the IETF is going, then the categories listed above
should not have anything to do with selection of candidates for leadership
positions. It doesn't matter to the IETF if the candidate is a disabled,
pregnant, lesbian, Wiccan. What matters to the IETF is whether the
candidate is qualified.

  Dan.

Re: Diversity of IETF Leadership

[tsg]

On 03/20/2013 07:16 AM, Jorge Contreras wrote:
On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman 
mailto:m...@lilacglade.org>> wrote:





Jorge - did I miss something here - isnt this your job? If not why are 
you here?


Let me respond that further -  I believe that there are any number of 
both privacy and transparency counsel's in the movement so to speak who 
would love to work with such a body to create a transparent set of 
participation rules UNDER THE CURRENT PARTICIPATION MODELS AS BROKEN AS 
THEY ARE...


Didnt you file an ID yourself not to long ago?  In fact I am betting 
Professor you know any number of Grad Students who would love such a job 
if you catch my drift.


Todd


Hi Stewart,

On Mar 20, 2013, at 2:04 AM, Stewart Bryant mailto:stbry...@cisco.com>> wrote:
> Age
> Disability
> Gender reassignment
> Marriage and civil partnership
> Pregnancy and maternity
> Race
> Religion and belief
> Sex
> Sexual orientation

The U.S. has a similar (although not identical) list, and it may
vary a bit state-by-state.
>
> If we are going to have an itemized list of diversity
characteristics, we should not pick and choose, we should include
the full list.


I would strongly recommend that legal counsel be consulted before any 
such "list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is 
totally outside my own area of legal expertise, so IAOC would need to 
incur some expense to hire competent counsel in this area)



While I certainly wouldn't suggest we start discriminating based
on _any_ of these factors, it is very difficult to measure our
results in some of these areas, as we do not collect this
information from IETF attendees, nor do we publish the age,
disability status, gender status, marital status, religion or
sexual orientation of our I* members.


What records *do* exist regarding the identify of IETF leadership?  Is 
there a central repository of at least names/companies of IESG members 
and/or WG leaders?

Re: Diversity of IETF Leadership

[Scott Brim]

On 03/20/13 15:16, Jorge Contreras allegedly wrote:
> I would strongly recommend that legal counsel be consulted before any
> such "list" is produced or used by IETF/IESG/Nomcom.

Or don't generate it at all.  Trying to have a complete list of human
attributes to diversify to looks like an engineer's reflex.  We know
what we want to do in principle.

R: [IPFIX] Last Call: (Flow Selection Techniques) to Proposed Standard

[Salvatore D'Antonio]

Dear Benoit,

 

Will do.

 

Kind regards,

 

Salvatore

 

 

 

Da: Benoit Claise [mailto:bcla...@cisco.com] 
Inviato: mercoledì 20 marzo 2013 09:36
A: draft-ietf-ipfix-flow-selection-t...@tools.ietf.org
Cc: IETF-Discussion list; Rahul Patel; ip...@ietf.org
Oggetto: Re: [IPFIX] Last Call:
 (Flow Selection Techniques) to
Proposed Standard

 

Dear authors,

While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some feedback
that actually concerns draft-ietf-ipfix-flow-selection-tech.
Can you please take this into account.

 

Regards, Benoit





 

 

Few comments.

 

1.  Page 8:  

1.  The difference between "Intermediate Selection Process" and
"Intermediate Flow Selection Process" is not clear. Is the first one
selecting record purely on matching content (value of the fields) in the
record and the second one selecting on matching attributes of the fields
that are not part of the record in *addition* to matching content in the
record? An example would help here.

BC> Granted, this is difficult to understand from the definitions only.
There is some history behind these two separate definitions. Anyway, you get
it right from your message above.
I was thinking to add to a section 2.1 "Differences between Intermediate
Selection Process and Intermediate Flow Selection Process" in the
draft-ietf-ipfix-mediation-protocol draft. However, thinking about it some
more, this section should really be done in
draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow Selection
Process and Packet Selection". Some more text should be added on the
difference between Intermediate Selection Process and Intermediate Flow
Selection Process

When created, draft-ietf-ipfix-mediation-protocol will refer to that new
section.




1.   

1.  Also in the example " e.g., Filtering only records from a given
network to a given Collector" - Does "given network" means
"source-ip/source-prefix of the exporter"?.

BC> It means matching the flow records to a certain prefix/AS/you-name-it,
and exporting those matched flow records to an exporter.
See for example, section 6.1 in RFC 6183
This could be explained better in the new section in
draft-ietf-ipfix-flow-selection-tech (See previous point)

 

 
The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Flow Selection Techniques'
   as Proposed Standard
 
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
 
Abstract
 
 
   Intermediate Flow Selection Process is the process of selecting a
   subset of Flows from all observed Flows.  The Intermediate Flow
   Selection Process may be located at an IPFIX Exporter, Collector, or
   within an IPFIX Mediator.  It reduces the effort of post-processing
   Flow data and transferring Flow Records.  This document describes
   motivations for using the Intermediate Flow Selection process and
   presents Intermediate Flow Selection techniques.  It provides an
   information model for configuring Intermediate Flow Selection Process
   techniques and discusses what information about an Intermediate Flow
   Selection Process should be exported.
 
 
 
 
 
The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
 
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/
 
 
The following IPR Declarations may be related to this I-D:
 
   http://datatracker.ietf.org/ipr/1540/
 
 
 
___
IPFIX mailing list
ip...@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix
 
 

 

  _  

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.2904 / Database dei virus: 2641/6186 - Data di rilascio:
18/03/2013

Re: Diversity of IETF Leadership

[Keith Moore]

On 03/20/2013 08:13 AM, Martin Rex wrote:

The monetary and time resources necessary to fill an I* position adequately
appear quite significant to me, and I believe it would be hard to fill
them without strong support from an employer which covers the monetary
investment.


Agreed.  But this is a huge problem for IETF.   Far too often, our 
standards aren't serving the Internet community so much as serving the 
interests of a few large companies.   I'd actually guess that this is 
IETF's biggest problem.


Keith

Re: IETF 86 Admin Plenary Minutes

[Dave Crocker]

On 3/19/2013 1:20 PM, S Moonesamy wrote:

Merely to offer an example notation:

   Sean Turner mentioned that a year ago someone asked him how to become
a WG chair. Asking is the first step! He thinks that if people want to
actively participate, they need to volunteer to write drafts etc.
{guidance/leadership}


The above lists asking as the first step.  Most people would not ask as
it is awkward to do so.



From the 20 seconds that I used to look for examples, it was 
immediately clear that there are at least two kinds of items to note. 
One, of course, is direct questions and requests.  One other is 'topics' 
that are raised, unresolved, and seem worthy of follow-up.  They might 
or might not turn into questions/requests, but at least they are 
noteworthy (literally).


The larger issue goes beyond annotation methodology.  Namely an open-mic 
environment that seeks to produce an exchange that is actionable, rather 
than a tone that is primarily for venting.


A tone that encourages constructive action tends to be common in working 
group discussion.  So we know it's possible and we are all experienced 
with it.  So the change we need for open-mic sessions is (simply to) 
move more towards developing specific questions and suggestions; this is 
a change on the dais, as well as at the microphone...



d/

ps. I've skipped the substantive issue you pursue, concerning the 
problematic selection processes, only because here I want to focus on 
making open-mic sessions more productive.


--
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

Re: Mentoring

[Brian E Carpenter]

On 20/03/2013 13:42, Ben Campbell wrote:
> On Mar 20, 2013, at 3:09 AM, Brian E Carpenter  
> wrote:
> 
>> However, I think an important part of that is ensuring that people
>> do *not* focus exclusively on a specific target, even if they are
>> busy people as Ben said.
> 
> Change the sense of "ensuring" to "encouraging", and I agree. But as worded, 
> that sounds a lot like making it harder for someone to focus on the work they 
> are interested in. I think that's more likely to make people stop coming than 
> making them generalize their work.

Yes, my phrasing was careless. But we really do need to encourage
cross-currents. For me personally, that's one of the main benefits
of the IETF format and it would be sad to be too inward looking.

  Brian

Re: Diversity of IETF Leadership

[Eric Burger]

Going a bit over-the-top: is there an interaction between sex and sexual 
orientation? Can one count as the other?

On Mar 20, 2013, at 8:10 AM, Riccardo Bernardini  wrote:

> 
> 
> On Wed, Mar 20, 2013 at 11:53 AM, Margaret Wasserman  
> wrote:
> 
> Hi Stewart,
> 
> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
> > Age
> > Disability
> > Gender reassignment
> > Marriage and civil partnership
> > Pregnancy and maternity
> > Race
> > Religion and belief
> > Sex
> > Sexual orientation
> 
> The U.S. has a similar (although not identical) list, and it may vary a bit 
> state-by-state.
> >
> > If we are going to have an itemized list of diversity characteristics, we 
> > should not pick and choose, we should include the full list.
> 
> While I certainly wouldn't suggest we start discriminating based on _any_ of 
> these factors, it is very difficult to measure our results in some of these 
> areas, as we do not collect this information from IETF attendees, nor do we 
> publish the age, disability status, gender status, marital status, religion 
> or sexual orientation of our I* members. 
> 
> I am not suggesting that we start collecting or publishing this information, 
> just saying that it makes it hard to tell whether our leadership is 
> reasonably representative of the community in some of these areas.
> 
> 
> I would say that in this case we are almost surely automatically fair:  while 
> one can suspect that gender or geographical origin could add a bias (even an 
> unwanted one), if I do not know the, say, sexual orientation of a candidate, 
> I cannot discriminate (even on a subconscious level) using that information.
>  
> Also, I think there are some area where diversity is important to the IETF 
> that are not on this list, like geographic location, corporate affiliation 
> and industry segment (vendor, operator, researcher, etc.).
> 
> Margaret
> 
> 

Re: Diversity of IETF Leadership

[Richard Barnes]

I do not really think the legal angle is helpful in resolving this problem.
 (Which country's laws do we need to comply with?)  Let's treat these legal
ideas as considerations that we should be thinking about, not something
where we should be striving for strict compliance.

--Richard



On Wed, Mar 20, 2013 at 10:27 AM, Mary Barnes wrote:

> On Wed, Mar 20, 2013 at 9:16 AM, Jorge Contreras 
> wrote:
> > On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman 
> > wrote:
> >>
> >>
> >> Hi Stewart,
> >>
> >> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
> >> > Age
> >> > Disability
> >> > Gender reassignment
> >> > Marriage and civil partnership
> >> > Pregnancy and maternity
> >> > Race
> >> > Religion and belief
> >> > Sex
> >> > Sexual orientation
> >>
> >> The U.S. has a similar (although not identical) list, and it may vary a
> >> bit state-by-state.
> >> >
> >> > If we are going to have an itemized list of diversity characteristics,
> >> > we should not pick and choose, we should include the full list.
> >
> >
> > I would strongly recommend that legal counsel be consulted before any
> such
> > "list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is totally
> > outside my own area of legal expertise, so IAOC would need to incur some
> > expense to hire competent counsel in this area)
> [MB] I agree 100%.  IETF is not at all qualified to define hiring
> criteria or practices. Unfortunately, they do it all the time.  The
> model in place IMHO would not stand up to the scrutiny of any major US
> company's HR dept.  And, of course, the HR departments are the ones
> responsible for ensuring the laws in a specific area are met.   [/MB]
> >
> >>
> >>
> >> While I certainly wouldn't suggest we start discriminating based on
> _any_
> >> of these factors, it is very difficult to measure our results in some of
> >> these areas, as we do not collect this information from IETF attendees,
> nor
> >> do we publish the age, disability status, gender status, marital status,
> >> religion or sexual orientation of our I* members.
> >
> >
> > What records *do* exist regarding the identify of IETF leadership?  Is
> there
> > a central repository of at least names/companies of IESG members and/or
> WG
> > leaders?
>

Re: Diversity of IETF Leadership

[Mary Barnes]

On Wed, Mar 20, 2013 at 9:16 AM, Jorge Contreras  wrote:
> On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman 
> wrote:
>>
>>
>> Hi Stewart,
>>
>> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
>> > Age
>> > Disability
>> > Gender reassignment
>> > Marriage and civil partnership
>> > Pregnancy and maternity
>> > Race
>> > Religion and belief
>> > Sex
>> > Sexual orientation
>>
>> The U.S. has a similar (although not identical) list, and it may vary a
>> bit state-by-state.
>> >
>> > If we are going to have an itemized list of diversity characteristics,
>> > we should not pick and choose, we should include the full list.
>
>
> I would strongly recommend that legal counsel be consulted before any such
> "list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is totally
> outside my own area of legal expertise, so IAOC would need to incur some
> expense to hire competent counsel in this area)
[MB] I agree 100%.  IETF is not at all qualified to define hiring
criteria or practices. Unfortunately, they do it all the time.  The
model in place IMHO would not stand up to the scrutiny of any major US
company's HR dept.  And, of course, the HR departments are the ones
responsible for ensuring the laws in a specific area are met.   [/MB]
>
>>
>>
>> While I certainly wouldn't suggest we start discriminating based on _any_
>> of these factors, it is very difficult to measure our results in some of
>> these areas, as we do not collect this information from IETF attendees, nor
>> do we publish the age, disability status, gender status, marital status,
>> religion or sexual orientation of our I* members.
>
>
> What records *do* exist regarding the identify of IETF leadership?  Is there
> a central repository of at least names/companies of IESG members and/or WG
> leaders?

Re: Diversity of IETF Leadership

[Richard Barnes]

IESG, with name/area: 
IAB, with name/affiliation: 


On Wed, Mar 20, 2013 at 10:16 AM, Jorge Contreras wrote:

> On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman 
> wrote:
>
>>
>> Hi Stewart,
>>
>> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
>> > Age
>> > Disability
>> > Gender reassignment
>> > Marriage and civil partnership
>> > Pregnancy and maternity
>> > Race
>> > Religion and belief
>> > Sex
>> > Sexual orientation
>>
>> The U.S. has a similar (although not identical) list, and it may vary a
>> bit state-by-state.
>> >
>> > If we are going to have an itemized list of diversity characteristics,
>> we should not pick and choose, we should include the full list.
>>
>
> I would strongly recommend that legal counsel be consulted before any such
> "list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is totally
> outside my own area of legal expertise, so IAOC would need to incur some
> expense to hire competent counsel in this area)
>
>
>>
>> While I certainly wouldn't suggest we start discriminating based on _any_
>> of these factors, it is very difficult to measure our results in some of
>> these areas, as we do not collect this information from IETF attendees, nor
>> do we publish the age, disability status, gender status, marital status,
>> religion or sexual orientation of our I* members.
>>
>
> What records *do* exist regarding the identify of IETF leadership?  Is
> there a central repository of at least names/companies of IESG members
> and/or WG leaders?
>

Re: Diversity of IETF Leadership

[Jorge Contreras]

On Wed, Mar 20, 2013 at 6:53 AM, Margaret Wasserman wrote:

>
> Hi Stewart,
>
> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
> > Age
> > Disability
> > Gender reassignment
> > Marriage and civil partnership
> > Pregnancy and maternity
> > Race
> > Religion and belief
> > Sex
> > Sexual orientation
>
> The U.S. has a similar (although not identical) list, and it may vary a
> bit state-by-state.
> >
> > If we are going to have an itemized list of diversity characteristics,
> we should not pick and choose, we should include the full list.
>

I would strongly recommend that legal counsel be consulted before any such
"list" is produced or used by IETF/IESG/Nomcom.  (FYI, this is totally
outside my own area of legal expertise, so IAOC would need to incur some
expense to hire competent counsel in this area)


>
> While I certainly wouldn't suggest we start discriminating based on _any_
> of these factors, it is very difficult to measure our results in some of
> these areas, as we do not collect this information from IETF attendees, nor
> do we publish the age, disability status, gender status, marital status,
> religion or sexual orientation of our I* members.
>

What records *do* exist regarding the identify of IETF leadership?  Is
there a central repository of at least names/companies of IESG members
and/or WG leaders?

Re: Diversity of IETF Leadership

[tsg]

I would suggest John that the real diversity the IETF needs is 
transparency in its process and a competent IPR rule set which meets the 
same set of legal hurdles people do in the commercial world so to speak.


I would also suggest that the idea of splitting all of these 
contractually binding practices into a set of technical publications is 
inherently insane and has lead to the fiasco that we have today. What 
the IETF needs is a simple set of documents that do not require a free 
wall to post the various components on to develop a proper reliance map.


Just my own two cents though.

Todd



On 03/20/2013 06:30 AM, John C Klensin wrote:


--On Wednesday, March 20, 2013 06:53 -0400 Margaret Wasserman
 wrote:


...
I am not suggesting that we start collecting or publishing
this information, just saying that it makes it hard to tell
whether our leadership is reasonably representative of the
community in some of these areas.

Also, I think there are some area where diversity is important
to the IETF that are not on this list, like geographic
location, corporate affiliation and industry segment (vendor,
operator, researcher, etc.).

Margaret,

While I am very much in favor of a more diverse IETF population
and leadership, the above, especially when combined with Martin
Rex's later comment, is part of the reason why I see the problem
as terribly difficult and not yielding easily to petitions,
design teams, instructions to confirming bodies (particularly
problematic as other discussions have shown), or good intentions.

As a specific example, I think the IETF would be considerably
strengthened by more diversity in corporate affiliations and
industry segments as you suggest above.   As with gender
diversity, my impression is that we are getting more homogeneous
rather than more diverse.  One of the problems is time
commitment and associated costs.  For many corporations, most
startups, and a significant fraction of actual individual
participants, service in leadership positions is feasible only
if those positions are really part-time and significant
attention is paid to either cost containment or spreading
marginal costs around the community.  Yet the IESG (and, to a
slightly lesser extent, the IAB) have tended to assign more and
more work and responsibility to themselves,

If we want more diversity along corporate, role, and related
economic axes, we need (as others have pointed out) to shrink
the jobs.  In the IESG's case, that may require reducing the
number of WGs we think we can operate in parallel.
Unfortunately, there are many reasons to continue to _expand_
the jobs: on a point basis, it will always be easier to add
tasks to existing leaders than to consider whether those tasks
are really necessary, to consider sunsetting other tasks, or to
organize and manage alternate ways to get them done.  It also
isn't clear that the community cares: I note that the recent
effort to allow the IAB and IESG to appoint people other than
the Chairs to serve on the IAOC/Trust, and an earlier one to
separate the IAOC and the Trust, went exactly nowhere.  On the
other hand, if we are serious, I think it needs to be something
that Nomcoms are committed (preferably without more rules) to
enforce by asking candidates their positions on job-shrinking
and by retiring incumbents who contribute to job-expansion.
Those expansions are perhaps also influenced by the observation
that, if the incumbents have the time and support for an
expanded role, such expansion doesn't seem to be harmful.  That
is part of a classic example of why already-homogeneous
organizations tend to become even more homogeneous, at leat in
the absence of disruptive changes.

best,
john

Re: Mentoring

[Ben Campbell]

On Mar 20, 2013, at 3:09 AM, Brian E Carpenter  
wrote:

> However, I think an important part of that is ensuring that people
> do *not* focus exclusively on a specific target, even if they are
> busy people as Ben said.

Change the sense of "ensuring" to "encouraging", and I agree. But as worded, 
that sounds a lot like making it harder for someone to focus on the work they 
are interested in. I think that's more likely to make people stop coming than 
making them generalize their work.

Re: Diversity of IETF Leadership

[John C Klensin]

--On Wednesday, March 20, 2013 06:53 -0400 Margaret Wasserman
 wrote:

>...
> I am not suggesting that we start collecting or publishing
> this information, just saying that it makes it hard to tell
> whether our leadership is reasonably representative of the
> community in some of these areas.
> 
> Also, I think there are some area where diversity is important
> to the IETF that are not on this list, like geographic
> location, corporate affiliation and industry segment (vendor,
> operator, researcher, etc.).

Margaret,

While I am very much in favor of a more diverse IETF population
and leadership, the above, especially when combined with Martin
Rex's later comment, is part of the reason why I see the problem
as terribly difficult and not yielding easily to petitions,
design teams, instructions to confirming bodies (particularly
problematic as other discussions have shown), or good intentions.

As a specific example, I think the IETF would be considerably
strengthened by more diversity in corporate affiliations and
industry segments as you suggest above.   As with gender
diversity, my impression is that we are getting more homogeneous
rather than more diverse.  One of the problems is time
commitment and associated costs.  For many corporations, most
startups, and a significant fraction of actual individual
participants, service in leadership positions is feasible only
if those positions are really part-time and significant
attention is paid to either cost containment or spreading
marginal costs around the community.  Yet the IESG (and, to a
slightly lesser extent, the IAB) have tended to assign more and
more work and responsibility to themselves, 

If we want more diversity along corporate, role, and related
economic axes, we need (as others have pointed out) to shrink
the jobs.  In the IESG's case, that may require reducing the
number of WGs we think we can operate in parallel.
Unfortunately, there are many reasons to continue to _expand_
the jobs: on a point basis, it will always be easier to add
tasks to existing leaders than to consider whether those tasks
are really necessary, to consider sunsetting other tasks, or to
organize and manage alternate ways to get them done.  It also
isn't clear that the community cares: I note that the recent
effort to allow the IAB and IESG to appoint people other than
the Chairs to serve on the IAOC/Trust, and an earlier one to
separate the IAOC and the Trust, went exactly nowhere.  On the
other hand, if we are serious, I think it needs to be something
that Nomcoms are committed (preferably without more rules) to
enforce by asking candidates their positions on job-shrinking
and by retiring incumbents who contribute to job-expansion.
Those expansions are perhaps also influenced by the observation
that, if the incumbents have the time and support for an
expanded role, such expansion doesn't seem to be harmful.  That
is part of a classic example of why already-homogeneous
organizations tend to become even more homogeneous, at leat in
the absence of disruptive changes.

best,
   john

www.rfc-editor.org and www.ietf.org TCP window scaling

[Mikael Abrahamsson]

Hello.

As far as I can tell, www.rfc-editor.org doesn't support TCP window 
scaling. It also doesn't support ftp on its IPv6 address:


swmike@uplift:~$ telnet -4 www.rfc-editor.org 21
Trying 64.170.98.47...
Connected to rfc-editor.org.
Escape character is '^]'.
220 "FTP Server Ready"
quit
221 Goodbye.
Connection closed by foreign host.
swmike@uplift:~$ telnet -6 www.rfc-editor.org 21
Trying 2001:1890:126c::1:2f...
telnet: Unable to connect to remote host: Connection refused

14:00:38.045593 IP (tos 0x10, ttl 64, id 33826, offset 0, flags [DF], 
proto TCP (6), length 60) xxx.xxx.xxx.xxx.36300 > 64.170.98.47.21: Flags 
[SEW], cksum 0xc541 (correct), seq 1822128746, win 5840, options [mss 
1460,sackOK,TS val 3080584776 ecr 0,nop,wscale 7], length 0


14:00:38.224653 IP (tos 0x0, ttl 57, id 0, offset 0, flags [DF], proto TCP 
(6), length 56) 64.170.98.41.21 > xxx.xxx.xxx.xxx.36300: Flags [S.], cksum 
0x9c17 (correct), seq 831902177, ack 1822128747, win 5792, options [mss 
1460,sackOK,TS val 332539598 ecr 3080584776], length 0


I get 124 kilobyte/s when I download 
. That seems quite 
slow by todays standards. Since I have 179ms delay, it doesn't really hit 
me as indicating 16 or 32 kilobyte window size, but somewhere in between.


www.ietf.org doesn't seem to support TCP window scaling either:

13:58:13.565917 IP xxx.xxx.xxx.xxx.41603 > 12.22.58.30.80: Flags [SEW], 
seq 3844537042, win 5840, options [mss 1460,sackOK,TS val 3080548657 ecr 
0,nop,wscale 7], length 0


13:58:13.746501 IP 12.22.58.30.80 > xxx.xxx.xxx.xxx.41603: Flags [S.], seq 
4206253981, ack 3844537043, win 5792, options [mss 1460,sackOK,TS val 
357513706 ecr 3080548657], length 0


Any specific reason for this? My host connects with "wscale 7".

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Diversity of IETF Leadership

[Dhruv Dhody]

On Wed, Mar 20, 2013 at 5:40 PM, Riccardo Bernardini
wrote:

>  if I do not know the, say, sexual orientation of a candidate, I cannot
> discriminate (even on a subconscious level) using that information.
>
>
Hi Riccardo,

I hope you are not suggesting candidates to remain in closet, to not be
discriminated? :D

Dhruv

Re: Diversity of IETF Leadership

[Martin Rex]

Margaret Wasserman wrote:
> 
> On Mar 12, 2013, at 2:24 PM, Dan Harkins  wrote:
> > 
> >  I'd love to get out of this rat hole. Perhaps the signatories of the
> > open letter can restate the problem they see so it isn't made in terms of
> > race and gender.
> 
> The letter specifically mentioned the axes of race, gender, geographic
> location and corporate affiliation, so the letter was not only about
> race and gender.  Other people have mentioned other pertinent axes in
> the e-mail discussion, such as industry segment and background/experience.
> 
> I don't think it is possible for remove race and gender from the list of
> axes, though, since there is a notable lack of diversity in those areas.

The monetary and time resources necessary to fill an I* position adequately
appear quite significant to me, and I believe it would be hard to fill
them without strong support from an employer which covers the monetary
investment.

Any "lack of diversity" in the IESG/IAB/IAOC of the IETF leadership
is IMHO related to the "lack of interest" in longterm planning in
the majority of management of large companies--those which can reasonably
expect to still be around and still sell products in some area a few years
into the future.

-Martin

Re: Diversity of IETF Leadership

[Riccardo Bernardini]

On Wed, Mar 20, 2013 at 11:53 AM, Margaret Wasserman wrote:

>
> Hi Stewart,
>
> On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
> > Age
> > Disability
> > Gender reassignment
> > Marriage and civil partnership
> > Pregnancy and maternity
> > Race
> > Religion and belief
> > Sex
> > Sexual orientation
>
> The U.S. has a similar (although not identical) list, and it may vary a
> bit state-by-state.
> >
> > If we are going to have an itemized list of diversity characteristics,
> we should not pick and choose, we should include the full list.
>
> While I certainly wouldn't suggest we start discriminating based on _any_
> of these factors, it is very difficult to measure our results in some of
> these areas, as we do not collect this information from IETF attendees, nor
> do we publish the age, disability status, gender status, marital status,
> religion or sexual orientation of our I* members.


> I am not suggesting that we start collecting or publishing this
> information, just saying that it makes it hard to tell whether our
> leadership is reasonably representative of the community in some of these
> areas.
>
>
I would say that in this case we are almost surely automatically fair:
 while one can suspect that gender or geographical origin could add a bias
(even an unwanted one), if I do not know the, say, sexual orientation of a
candidate, I cannot discriminate (even on a subconscious level) using that
information.


> Also, I think there are some area where diversity is important to the IETF
> that are not on this list, like geographic location, corporate affiliation
> and industry segment (vendor, operator, researcher, etc.).
>
> Margaret
>
>

Re: Diversity of IETF Leadership

[Eliot Lear]

Let's not play Internet lawyers about this.  How Jari's design team
bring in real lawyers at the appropriate time?

Re: Diversity of IETF Leadership

[Stewart Bryant]

On 20/03/2013 10:53, Margaret Wasserman wrote:

Hi Stewart,

On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:

Age
Disability
Gender reassignment
Marriage and civil partnership
Pregnancy and maternity
Race
Religion and belief
Sex
Sexual orientation

The U.S. has a similar (although not identical) list, and it may vary a bit 
state-by-state.

If we are going to have an itemized list of diversity characteristics, we 
should not pick and choose, we should include the full list.

While I certainly wouldn't suggest we start discriminating based on _any_ of 
these factors, it is very difficult to measure our results in some of these 
areas, as we do not collect this information from IETF attendees, nor do we 
publish the age, disability status, gender status, marital status, religion or 
sexual orientation of our I* members.

I am not suggesting that we start collecting or publishing this information, 
just saying that it makes it hard to tell whether our leadership is reasonably 
representative of the community in some of these areas.

Also, I think there are some area where diversity is important to the IETF that 
are not on this list, like geographic location, corporate affiliation and 
industry segment (vendor, operator, researcher, etc.).

Margaret

.

There are methods of anonymously determining the profile of the IETF in 
the above terms, but to preserve the anonymity of such information, and 
understand its statistical significance this should probably be gathered 
by a specialist organization outside the IETF but on our behalf.


The extended list needs further review and consideration. For example, 
perhaps  we should take a leaf from the IEEE and consider who funds work 
items rather than simply use current affiliation as we do today. This 
makes things more transparent both at the corporate and the consulting 
level.


Stewart

Re: Diversity of IETF Leadership

[Margaret Wasserman]

Hi Stewart,

On Mar 20, 2013, at 2:04 AM, Stewart Bryant  wrote:
> Age
> Disability
> Gender reassignment
> Marriage and civil partnership
> Pregnancy and maternity
> Race
> Religion and belief
> Sex
> Sexual orientation

The U.S. has a similar (although not identical) list, and it may vary a bit 
state-by-state.
> 
> If we are going to have an itemized list of diversity characteristics, we 
> should not pick and choose, we should include the full list.

While I certainly wouldn't suggest we start discriminating based on _any_ of 
these factors, it is very difficult to measure our results in some of these 
areas, as we do not collect this information from IETF attendees, nor do we 
publish the age, disability status, gender status, marital status, religion or 
sexual orientation of our I* members.  

I am not suggesting that we start collecting or publishing this information, 
just saying that it makes it hard to tell whether our leadership is reasonably 
representative of the community in some of these areas.

Also, I think there are some area where diversity is important to the IETF that 
are not on this list, like geographic location, corporate affiliation and 
industry segment (vendor, operator, researcher, etc.).

Margaret

Re: [IETF] back by popular demand - a DNS calculator

[Ray Bellis]

On 21 Feb 2013, at 02:46, Carlos M. martinez 
mailto:carlosm3...@gmail.com>> wrote:

Wasn't the 'evil bit' able to hold the value 2 ?

Use all evil bits for IP addresses and we'll soon have no need for IPv6.

Geoff Huston and I wrote a draft to use the evil bit to indicate the presence 
of IPv4 NATs.  It could be used as a tie-breaker for Happy Eyeballs.  It's 
expired, though.



Ray

Re: [IPFIX] Last Call: (Flow Selection Techniques) to Proposed Standard

[Benoit Claise]

Dear authors,

While reviewing draft-ietf-ipfix-mediation-protocol, Rahul got some 
feedback that actually concerns draft-ietf-ipfix-flow-selection-tech.

Can you please take this into account.

Regards, Benoit




Few comments.

 1. Page 8:
 1. The difference between "Intermediate Selection Process" and
"Intermediate Flow Selection Process" is not clear. Is the
first one selecting record purely on matching content (value
of the fields) in the record and the second one selecting on
matching attributes of the fields that are not part of the
record in *addition* to matching content in the record? An
example would help here.

BC> Granted, this is difficult to understand from the definitions only. 
There is some history behind these two separate definitions. Anyway, you 
get it right from your message above.
I was thinking to add to a section 2.1 "Differences between Intermediate 
Selection Process and Intermediate Flow Selection Process" in the 
draft-ietf-ipfix-mediation-protocol draft. However, thinking about it 
some more, this section should really be done in 
draft-ietf-ipfix-flow-selection-tech-14, to avoid some more confusion.
There is already section 3. "Difference between Intermediate Flow 
Selection Process and Packet Selection". Some more text should be added 
on the difference between Intermediate Selection Process and 
Intermediate Flow Selection Process


When created, draft-ietf-ipfix-mediation-protocol will refer to that new 
section.



1.
 1. Also in the example " e.g., Filteringonly records from a given
network to a given Collector" - Does "given network" means
"source-ip/source-prefix of the exporter"?.

BC> It means matching the flow records to a certain 
prefix/AS/you-name-it, and exporting those matched flow records to an 
exporter.

See for example, section 6.1 in RFC 6183
This could be explained better in the new section in 
draft-ietf-ipfix-flow-selection-tech (See previous point)




The IESG has received a request from the IP Flow Information Export WG
(ipfix) to consider the following document:
- 'Flow Selection Techniques'
as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-01. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


Intermediate Flow Selection Process is the process of selecting a
subset of Flows from all observed Flows.  The Intermediate Flow
Selection Process may be located at an IPFIX Exporter, Collector, or
within an IPFIX Mediator.  It reduces the effort of post-processing
Flow data and transferring Flow Records.  This document describes
motivations for using the Intermediate Flow Selection process and
presents Intermediate Flow Selection techniques.  It provides an
information model for configuring Intermediate Flow Selection Process
techniques and discusses what information about an Intermediate Flow
Selection Process should be exported.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/ballot/


The following IPR Declarations may be related to this I-D:

http://datatracker.ietf.org/ipr/1540/



___
IPFIX mailing list
ip...@ietf.org
https://www.ietf.org/mailman/listinfo/ipfix

Re: [IAB] WCIT slides

[Jonne.Soininen]

Hi Arturo,


Good points that you have made. However, I would like to just sharpen some
of the things. There are many governments that do not understand how the
Internet works. Well, there are a lot of people even in the IETF that
might not really know how Internet works, and even bigger number outside
the IETF. However, there is a growing number of government that does
understand this at least on some level. This is due to the years of work
that different people, and organizations (including ISOC, RIRs, ICANN,
etc) that have put a lot of effort into this locally and internationally.
So, there is proof even governments can be educated... ;)

Therefore, that work has to continue, as you say, in all levels including
technical and political. The I* organizations have to pull together to
make this happen, and have done it already for a while. However, new
people and new insight for the work is needed, always.

Cheers,

Jonne.

On 3/19/13 10:32 PM, "Arturo Servin"  wrote:

>
>   As I mentioned in the mic during the IAB-sponsored Discussion of WCIT,
>during the week I had the opportunity to talk and interact to some of
>the policy fellows invited by ISOC (in general were people from the
>national regulator or from the ministry of telecommunications -AFAIK-).
>I also had the opportunity (along with Marcelo Bagnulo) to have
>breakfast with them and to present a summary of the Internet ecosystem
>and its complexities.
>
>   From my experience during the week and the IAB-sponsored Discussion of
>WCIT I have this comments that I said I was going to share in the list:
>
>- It seems that there is not much understanding for governments in how
>the Internet ecosystem works.
>
>- Governments believe (or believed) that ITU is/was the common place to
>discuss and try to resolve Internet matters.
>
>- The Internet is an open entity with many organizations interacting
>with each other and the relationships among them may be very complex. We
>need to communicate this to governments and help them to interact with
>all the Internet-stake-holders.
>
>- Everyone has a place and a role in the Internet open model. Even
>governments. We need to let them play, help them to find their place,
>teach them the rules of the game and avoid to step in each others feet
>(I used the example of an RIR standardizing protocols or the IETF trying
>to mandate national laws)
>
>- To solve many of the today's Internet problems requires interaction at
>several layers (technical, policy, government and the separation between
>them is very blur) and between a diverse set of actors. It requires
>communication and coordination among all parties.
>
>- The communication and dialogue has to be a common effort. Today it is
>not enough to say that the IETF or the X forum is open to everybody.
>Being open is a must, the next step is going out and create
>communication channels, not wait for them.
>
>- The Internet does not have a common API for governments and it may
>never have one. Local APIs do not exists or are complex. [1]
>
>- As technical community we need to inform governments which
>technological solutions we already have. This minimize or eliminate
>their desire to "re-invent the wheel" in closed forums or create
>pseudo-standards that contradict ours.
>
>   I think that is all. I hope it helps for future discussion about the
>topic.
>
>
>Regards,
>as
>
>[1] I borrowed the idea of the "Government API" from John Curran.
>
>On 3/15/13 10:57 AM, Joel M. Halpern wrote:
>> With apologies for the problems making these slides available, and
>> thanks to Bernard for finding a work-around, for now the slides are
>> available via links from
>> http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/
>> 
>> Yours,
>> Joel M. Halpern
>> 
>>  Original Message 
>> Subject: Re: [IAB] WCIT slides
>> Date: Fri, 15 Mar 2013 13:40:04 +
>> From: Bernard Aboba 
>> 
>> 
>> I have created a blog entry on the IAB website that points to
>> the slides, agenda and session recording:
>> http://www.iab.org/2013/03/14/wcit-what-happened-whats-next/
>> 

Re: Mentoring

[Brian E Carpenter]

On 20/03/2013 01:23, Spencer Dawkins wrote:
> On 3/19/2013 8:01 PM, Ben Campbell wrote:
> 
>> I think this means we should closely consider the goals of a mentoring
>> effort. Is it to help them navigate the IETF structure, personalities,
>> and immune system to get something done? Is it to help them become the
>> next generation of IETF leaders? I suspect those two goals do not lend
>> themselves to the same approach.
> 
> Yeah, I agree with Ben here.
> 
> I'd go further and suggest that helping people get something done is a
> good thing, and at least some of the people who have gotten something
> done are more likely to to hang around, but if people want to be part of
> the next generation of IETF leadership without actually getting
> something done first, encouraging them may not take the IETF to a happy
> place.

Correct, we wish to convert successful participants into long-term
participants and future leaders, and the first step is converting new
participants into successful participants [RFC4144].

However, I think an important part of that is ensuring that people
do *not* focus exclusively on a specific target, even if they are
busy people as Ben said.

   Brian

Re: Getting rid of the dot

[Yao]

I agree with Brian.

IETF has no king.
If the badge said that somebody is a chair, it may imply that there has a 
"king".

dot is better !

Jiankang Yao

- Original Message - 
From: "Brian E Carpenter" 
To: "Carsten Bormann" 
Cc: 
Sent: Tuesday, March 19, 2013 4:05 PM
Subject: Re: Getting rid of the dot


> On 18/03/2013 22:10, Carsten Bormann wrote:
>> I wouldn't mind replacing my blue dot with an indication *what* WG I chair, 
>> and in which area that is.
>> 
>> Might be a bit more logistics when chairs change, but nothing that can't be 
>> solved with a DYMO labelmaker.
> 
> I can only speak for myself, but I find badges hard enough to take
> in at a glance even with the current amount of dot clutter. I don't
> think that adding more detail is wise, and I think the notion that
> "dot = knows what's going on" is simple and useful, even without
> decoding the colour.
> 
> Heresy: I'm *not* convinced that putting labels on newcomers is such
> a good idea, because it has exactly the opposite implication to a dot
> of any colour.
> 
>   Brian

Re: Getting rid of the dot

[Dave Cridland]

On 19 Mar 2013 22:47, "Ole Jacobsen"  wrote:
> I can just see the list of MUST, SHOULD and MAY have attributes,

Tsk. RFC 2119 only applies to interoperability requirements, as you well
know.

So unless we're also swapping t-shirts...

RE: Getting rid of the dot

[l.wood]

There's always some excuse as to why multi-homing is never done properly.


On 03/19/13 20:38, Michael Richardson allegedly wrote:
> Actually, I'd just settle for a badge that wasn't always
> backwards.

It costs a lot more to get lanyards that attach at two corners.