Weekly posting summary for ietf@ietf.org

[Thomas Narten]

Total of 246 messages in the last 7 days.
 
script run at: Fri Mar 22 00:53:03 EDT 2013
 
Messages   |  Bytes| Who
+--++--+
  4.88% |   12 |  6.03% |   128365 | d...@dcrocker.net
  0.41% |1 |  9.07% |   192830 | f...@clock.org
  3.25% |8 |  2.77% |58870 | arturo.ser...@gmail.com
  0.41% |1 |  5.55% |   117980 | t...@ecs.soton.ac.uk
  3.25% |8 |  2.62% |55680 | brian.e.carpen...@gmail.com
  2.85% |7 |  2.69% |57279 | s...@resistor.net
  3.25% |8 |  2.28% |48556 | jh...@pfrc.org
  2.85% |7 |  2.55% |54171 | mary.ietf.bar...@gmail.com
  2.85% |7 |  2.45% |52196 | john-i...@jck.com
  2.85% |7 |  2.22% |47243 | spen...@wonderhamster.org
  2.85% |7 |  2.11% |44918 | morrowc.li...@gmail.com
  2.44% |6 |  1.78% |37880 | m...@sap.com
  2.03% |5 |  1.66% |35308 | mo...@network-heretics.com
  1.63% |4 |  1.95% |41580 | far...@umn.edu
  2.03% |5 |  1.52% |32308 | melinda.sh...@gmail.com
  1.63% |4 |  1.90% |40312 | pau...@packetizer.com
  2.03% |5 |  1.46% |31091 | jo...@taugh.com
  1.63% |4 |  1.62% |34562 | tglas...@earthlink.net
  1.63% |4 |  1.58% |33691 | jcur...@istaff.org
  1.22% |3 |  1.75% |37246 | sprom...@unina.it
  1.63% |4 |  1.24% |26325 | s...@internet2.edu
  1.63% |4 |  1.19% |25366 | b...@nostrum.com
  1.63% |4 |  1.16% |24673 | fgalie...@gmail.com
  1.63% |4 |  1.15% |24470 | hous...@vigilsec.com
  1.63% |4 |  1.14% |24175 | jari.ar...@piuha.net
  1.63% |4 |  1.10% |23358 | swm...@swm.pp.se
  1.63% |4 |  0.96% |20494 | wor...@ariadne.com
  1.22% |3 |  1.19% |25212 | f...@cisco.com
  1.22% |3 |  1.15% |24469 | galvin+i...@elistx.com
  1.22% |3 |  1.14% |24179 | ebur...@standardstrack.com
  1.22% |3 |  1.01% |21428 | alejandroacostaal...@gmail.com
  1.22% |3 |  0.99% |20952 | dhark...@lounge.org
  1.22% |3 |  0.90% |19124 | l...@cisco.com
  1.22% |3 |  0.84% |17887 | mcr+i...@sandelman.ca
  1.22% |3 |  0.83% |17733 | do...@dougbarton.us
  1.22% |3 |  0.82% |17466 | o...@cisco.com
  0.81% |2 |  1.05% |22230 | r...@ipv.sx
  0.81% |2 |  0.83% |17648 | y...@checkpoint.com
  0.81% |2 |  0.82% |17408 | dhruv.i...@gmail.com
  0.81% |2 |  0.77% |16361 | acoo...@cdt.org
  0.81% |2 |  0.73% |15463 | chris.dearl...@baesystems.com
  0.81% |2 |  0.72% |15290 | stbry...@cisco.com
  0.81% |2 |  0.71% |15003 | sm+i...@elandsys.com
  0.41% |1 |  1.10% |23483 | salvatore.danto...@uniparthenope.it
  0.81% |2 |  0.66% |14057 | d...@cridland.net
  0.81% |2 |  0.63% |13318 | stpe...@stpeter.im
  0.81% |2 |  0.61% |13020 | barryle...@computer.org
  0.81% |2 |  0.59% |12536 | ra...@qti.qualcomm.com
  0.81% |2 |  0.57% |12176 | l.w...@surrey.ac.uk
  0.81% |2 |  0.57% |12117 | m...@lilacglade.org
  0.81% |2 |  0.54% |11487 | m...@sandelman.ca
  0.81% |2 |  0.54% |11442 | j...@joelhalpern.com
  0.81% |2 |  0.52% |11068 | c...@tzi.org
  0.41% |1 |  0.78% |16615 | bcla...@cisco.com
  0.41% |1 |  0.57% |12083 | i.g...@comcast.net
  0.41% |1 |  0.55% |11771 | hannes.tschofe...@gmx.net
  0.41% |1 |  0.55% |11723 | nar...@us.ibm.com
  0.41% |1 |  0.52% |10995 | henning.schulzri...@fcc.gov
  0.41% |1 |  0.47% |10052 | framefri...@gmail.com
  0.41% |1 |  0.45% | 9514 | jonne.soini...@renesasmobile.com
  0.41% |1 |  0.44% | 9349 | j...@mit.edu
  0.41% |1 |  0.44% | 9257 | cntre...@gmail.com
  0.41% |1 |  0.43% | 9098 | mmor...@cisco.com
  0.41% |1 |  0.42% | 8917 | ray.bel...@nominet.org.uk
  0.41% |1 |  0.40% | 8613 | mstjo...@comcast.net
  0.41% |1 |  0.39% | 8236 | presn...@qti.qualcomm.com
  0.41% |1 |  0.39% | 8207 | j...@jlc.net
  0.41% |1 |  0.35% | 7437 | carlosm3...@gmail.com
  0.41% |1 |  0.35% | 7355 | r...@netapp.com
  0.41% |1 |  0.34% | 7127 | d...@virtualized.org
  0.41% |1 |  0.33% | 7086 | t...@att.com
  0.41% |1 |  0.33% | 6984 | eck...@cisco.com
  0.41% |1 |  0.33% | 6937 | health...@gmail.com
  0.41% |1 |  0.31% | 6683 | rdroms.i...@gmail.com
  0.41% |1 |  0.31% | 6584 | lber...@labn.net
  0.41% |1 |  0.30% | 6472 | alexey.melni...@isode.com
  0.41% |1 |  0.30% | 6443 | rog...@gmail.com
  0.41% |1 |  0.30% | 6356 | jab...@hopcount.ca
  0.41% |1 |  0.30% | 6290 | elw...@dial.pipex.com
  0.41% |1 |  0.29% | 6173 | abdussalambar...@gmail.com
  0.41% |1 |  0.29% | 6170 | sak...@tanu.org
  0.41% |1 |  0.29% | 6094 | ebur...@cs.georgetown.edu
  0.41% |1 |  0.28% | 6017 | hsan...@isdg.net
  0.41% |1 |  0.28% | 6000

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

[Paul E. Jones]

Got it.  Thanks!  I'll make that change.

Paul

> -Original Message-
> From: Alissa Cooper [mailto:acoo...@cdt.org]
> Sent: Thursday, March 21, 2013 9:45 AM
> To: Paul E. Jones
> Cc: ietf@ietf.org; apps-disc...@ietf.org; webfin...@ietf.org
> Subject: Re: [apps-discuss] Last Call:  10.txt> (WebFinger) to Proposed Standard
> 
> I suggest adding the sentence without the word "implicitly." The result
> would be:
> 
> "Further, WebFinger MUST NOT be used to provide any personal information
> to any party unless explicitly authorized by the person whose
> information is being shared. Publishing one's personal data within an
> access-controlled or otherwise limited environment on the Internet does
> not equate to providing authorization of further publication of that
> data via WebFinger."
> 
> Thanks,
> Alissa
> 
> On Mar 20, 2013, at 9:28 PM, Paul E. Jones  wrote:
> 
> > 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

[Eric Burger]

Quite the contrary. I am interpreting a few of the 'diversity' posts as saying 
the IETF has fewer companies participating and much fewer smaller companies 
participating. And I am interpreting those posts as implying some nefarious 
plot on the part of large, Western, White-European-Male-Dominated companies to 
make it that way. I was just positing that the IETF might be reflective of the 
networking industry as a whole.

My thesis, not at all proven and one I am not married to, is there are fewer 
*companies* out there. With fewer companies, we should not be surprised there 
are fewer companies participating. On the big side, a ton of major players 
either merged or left the business. On the small side, a bunch of companies 
either got acquired or went bankrupt.

Fred Baker and Keith Moore have it right: we need to attract new blood.

On Mar 21, 2013, at 1:01 AM, Hector Santos  wrote:

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

[Gen-art] Review: draft-ietf-ipfix-flow-selection-tech-14.txt

[Joel M. Halpern]

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


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


Document: draft-ietf-ipfix-flow-selection-tech-14.txt
Flow Selection Techniques
Reviewer: Joel M. Halpern
Review Date: 21-March-2013
IETF LC End Date: 1-April-2013
IESG Telechat date: N/A

Summary: This document is ready for publication as a proposed standard.

Major issues: none (the previous major issue has been resolved by 
revision.  Thank you.)


Minor issues:
The tracker does not indicate a document shepherd for this document.

	If compliance is a big issue, then this document seems under-specified. 
For example, it says in section 5.1 "In order to be compliant with this 
document, at least the Property Match Filtering MUST be implemented." 
However, Property Match Filtering as defined in section 5.1.1 is a range 
of behaviors, so it is unclear which property tests must be supported 
(any, all possible?) in order to be compliant.



Nits/editorial comments: None

Re: Less Corporate Diversity

[John C Klensin]

--On Thursday, March 21, 2013 10:51 -0800 Melinda Shore
 wrote:

> On 3/21/13 9:19 AM, SM wrote:
>> I welcome feedback from anyone. 
> 
> All righty, then.  I do think that when someone is offering an
> opinion on the role of the IESG in moving work through the
> IETF, it's helpful if they've actually brought new work to the
> IETF, socialized it, negotiated with ADs around creating a new
> working group or rechartering an existing one, etc.  Because
> the IESG effectively functions as gatekeepers to taking on new
> work, it matters a lot that they have reasonably wide
> visibility into the industry and into real-world networking
> problems.  Having an IESG in which everybody has pretty much
> the same background is not how you achieve that.
> 
> It appears to be the case that people don't understand the
> gatekeeping role of the IESG in bringing new work into the
> organization unless they've experienced it directly.

FWIW.  I would add to the above that it is hard -- perhaps not
impossible, but hard-- to understand the document approval role
of the IESG and how it works in practice without experiencing it
first hand.  That experience could come from inside the IESG or
as a WG Chair, author, or shepherd who gets to be on the front
lines of the interactions.  I think it is a problem that others
in the community --especially those who end up on the Nomcom or
making suggestions to it-- don't have that understanding those
experiences bring, but it is a bit of a separate problem except
when it gets tangled up in this sort of discussion.

I, and I believe Melinda, have been pushing back on several of
Martin's comments and a few of yours, not because you lack some
particular credentials but because those remarks don't describe
the workings of the IESG in its various functions as we
understand and have experienced it.  At least for me, every "you
haven't done X" or "you haven't been a Y" comment isn't about
qualifications to comment but is merely a hypothesis as to why
our understanding of how the system works and yours and/or
Martin's are different.

best,
   john

Re: Less Corporate Diversity

[Melinda Shore]

On 3/21/13 9:19 AM, SM wrote:
> I welcome feedback from anyone. 

All righty, then.  I do think that when someone is offering an
opinion on the role of the IESG in moving work through the IETF,
it's helpful if they've actually brought new work to the IETF,
socialized it, negotiated with ADs around creating a new working
group or rechartering an existing one, etc.  Because the IESG
effectively functions as gatekeepers to taking on new work, it
matters a lot that they have reasonably wide visibility into
the industry and into real-world networking problems.  Having
an IESG in which everybody has pretty much the same background
is not how you achieve that.

It appears to be the case that people don't understand the
gatekeeping role of the IESG in bringing new work into the
organization unless they've experienced it directly.

Melinda

Re: Less Corporate Diversity

[SM]

draft-mrex-tls-secure-renegotiation-04 lists Martin Rex as one of the 
authors.  According to the authors of RFC 6176 Martin Rex has 
reviewed that specification.  According to the editor of RFC 4752 
Martin Rex has contributed to the document.


If being a RFC author is what matters I should stop commenting about 
drafts and focus on being a RFC author.  A significant number of 
drafts from RFC authors fail to be adopted due to lack of 
socialization.  If being Working Group Chair is what matters I should 
do whatever it takes to get that title.  The title won't help me 
understand how to deliver the work.


I welcome feedback from anyone.  I do not bother about whether the 
individual is a RFC author or a Working Chair; any feedback is useful 
to me.  In my opinion Martin Rex's contribution to the IETF is 
significant.  That opinion is not based on what is written in a draft 
or a RFC, or because of a title.


Regards,
-sm

P.S. The IETF is a place of many misunderstandings.

Re: Less Corporate Diversity

[John C Klensin]

--On Thursday, March 21, 2013 17:23 +0100 Martin Rex
 wrote:

> Keith Moore wrote:
>...
>> IESG is the review body of last resort.  When WGs do a poor
>> job of  review, especially cross-area review, the burden
>> falls on IESG to take  up the slack.

> As I understand and see it, the IESG is running IETF
> processes,  is mentoring IETF processes (towards WG Chairs,
> BOFs, individuals with complaints/appeals), and is trying to
> keep an eye on the overall architecture, and put togethe the
> pieces from reviews they obtain from their trusted reviewers,
> such as directorates.

Not only does that not match closely what is specified in the
various BCPs, but there is much to quibble about it in practice.
Again, I strongly suggest that actual experience with how things
work would be a lot better than suggesting changes on the basis
of theorizing.

>...
> I also don't see how _more_ reviews could make things worse.

Actually, we have worked examples of that too.  One problem
typically arises when someone reads a document, doesn't
understand it, but, having done the work, bogs document
processing down with typographic and editorial issues that did
not create ambiguity and that could easily be resolved by the
RFC Editor.

Had you said "more competent, focused, and substantive reviews"
I would have agreed.

> I believe it would be naive to expect IESG to perform reviews
> all by their own, either not asking for or ignoring all other
> input and then VOTE in committe style.

But this was exactly the expectation some years ago and
continues to be the expectation of an ADs who have not
established their own review support mechanisms.

> The way the IETF positions are defined and filled, biases of
> various ways are _inevitable_.  They solution to this is to
> set up processes in a fashion that will produce good results
> even where there is strong bias of various kinds -- aka "lack
> of diversity" -- by distributing the work to other IETF
> leadership positions besides IESG and by putting in place
> controls that will likely notice and object when IESG decisions
> seem to exhibit bias, and procedures to deal with this.

We more or less started with an IESG that was strictly a
steering and management body with standards approval elsewhere
(in the IAB of the time).   We did away with that, putting
document final review and approval in the IESG as well.  The
community has been extremely resistant to suggestions to change
that.  I agree with you that it would solve a number of problems
but we might be the only two people who believe that making the
change would be desirable on balance.  

Conversely, if you are convinced that there is real bias that
led to particular unfair and incorrect decisions, the appeals
process actually works very well.

> But once you structure processes&controls and distribute work
> in a fashion that makes it resilient to bias in I* positions,
> the whole issue of diversity will be much less of an issue for
> those positions.

As indicated above, I don't think that restructuring is going to
happen.  Even if it did, it would merely reduce the
possibilities for deliberate abuse and bias to distort the
system.  It wouldn't eliminate any of the other arguments for
diversity, most of which apply even if everyone is operating
completely in the open and in good faith.

   john


> 
> 
>> 
>> given the brokenness of IETF's structure.
> 
> Brokenness usually suggests defects that could have reasonably
> been avoided.  While there are certainly a number of features
> that each come at a cost, I'm not aware of an actual
> brokenness of the IETF's structure, i.e. something that could
> have been reasonably been avoided without loosing any benefits.
> 
> 
> -Martin

Re: Less Corporate Diversity

[Noel Chiappa]

> From: Melinda Shore 

> If everybody serving that gatekeeper function comes from a similar
> background (western white guy working for a large manufacturer)

To toy with Godwin's law for a moment - this sounds rather like western white
guy physics...

Noel

Re: Less Corporate Diversity

[Melinda Shore]

On 3/21/13 8:23 AM, Martin Rex wrote:
> As I understand and see it, the IESG is running IETF processes, 
> is mentoring IETF processes (towards WG Chairs, BOFs, individuals
> with complaints/appeals), and is trying to keep an eye on the
> overall architecture, and put togethe the pieces from reviews
> they obtain from their trusted reviewers, such as directorates.

They also gatekeep the work.  If they don't believe that something
is a problem, whether it because it's outside of the experience or
expertise, or it really isn't a problem, it doesn't get chartered,
it doesn't get sponsored, and it doesn't get published.  If
everybody serving that gatekeeper function comes from a similar
background (western white guy working for a large manufacturer)
it's going to tend to create certain biases in the work that's
taken on.

Melinda

Re: Less Corporate Diversity

[Martin Rex]

Keith Moore wrote:
> Martin Rex wrote:
> >
> > 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).
>
> IESG is the review body of last resort.  When WGs do a poor job of 
> review, especially cross-area review, the burden falls on IESG to take 
> up the slack.

As I understand and see it, the IESG is running IETF processes, 
is mentoring IETF processes (towards WG Chairs, BOFs, individuals
with complaints/appeals), and is trying to keep an eye on the
overall architecture, and put togethe the pieces from reviews
they obtain from their trusted reviewers, such as directorates.

>
> The idea that IESG shouldn't actually do review is naive in the extreme,

Huh?  I believe I never said nor implied this, and certainly never meant
something like that.

I also don't see how _more_ reviews could make things worse.

I believe it would be naive to expect IESG to perform reviews all by
their own, either not asking for or ignoring all other input and
then VOTE in committe style.

The way the IETF positions are defined and filled, biases of various
ways are _inevitable_.  They solution to this is to set up processes
in a fashion that will produce good results even where there is strong
bias of various kinds -- aka "lack of diversity" -- by distributing the
work to other IETF leadership positions besides IESG and by putting in
place controls that will likely notice and object when IESG decisions
seem to exhibit bias, and procedures to deal with this.

But once you structure processes&controls and distribute work in a fashion
that makes it resilient to bias in I* positions, the whole issue of
diversity will be much less of an issue for those positions.


>
> given the brokenness of IETF's structure.

Brokenness usually suggests defects that could have reasonably been
avoided.  While there are certainly a number of features that each
come at a cost, I'm not aware of an actual brokenness of the
IETF's structure, i.e. something that could have been reasonably been
avoided without loosing any benefits.


-Martin

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

[SM]

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

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


Yes.


specific in this document?


It may be easier to add text which provides a (simple) explanation 
about why RFC 2050 is obsolete.  The text in Section 5 (possibly with 
changes) could be moved to Section 1.


The draft already has the core of the text.  If Section 1 and Section 
2 are restructured most of the work is done.



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.


The above is clear and to the point.

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


Yes.  That's why I would suggest keeping the draft simple instead of 
getting into ICANN stuff.



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 above is clear and to the point.  It is good material for the draft.


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.


There is already a normative reference to RFC 2860.  Please note that 
I have not spent sufficient time reading the draft and related 
material to suggest whether or how to reference the terms in RFC 2860.


There argument is about the delineation of responsibility.  RFC 2860 
could be side-stepped; i.e. the draft could be turned into an 
understanding between the IETF and RIRs.  Obviously ICANN or any 
other organization can be added to the mix if anyone affiliated with 
the organization posts arguments to this mailing list to explain why 
that should be done.



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.


Ok.  I will try to be patient and wait for people with greater 
experience and knowledge to address those questions.



Thanks for the feedback - I hope I've helped explain at least some of the
reasoning behind the language in the draft.


Thank you for the clear explanations and providing the reasoning.

Regards,
-sm 

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

[Alissa Cooper]

I suggest adding the sentence without the word "implicitly." The result would 
be:

"Further, WebFinger MUST NOT be used to provide any personal information to any 
party unless explicitly authorized by the person whose information is being 
shared. Publishing one's personal data within an access-controlled or otherwise 
limited environment on the Internet does not equate to providing authorization 
of further publication of that data via WebFinger."

Thanks,
Alissa

On Mar 20, 2013, at 9:28 PM, Paul E. Jones  wrote:

> 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

[John C Klensin]

--On Thursday, March 21, 2013 08:53 + Brian E Carpenter
 wrote:

>  Individual ADs vary in their
> habits according to workload, but my sense is that there is a
> strong sense of collective responsibility and definitely not a
> sense of rubber stamping. You could check the statistices I
> suppose, but it is normal that when there is a DISCUSS ballot,
> it is from an AD in another IETF area, and very rarely from
> the co-AD in the same area. That wouldn't happen if the IESG
> was a rubber-stamping machine.

Agreed.  I also suggest that experience in putting both WG and
individual submission documents through the process in the last
several years (and experience that, as Melissa pointed out,
Martin apparently doesn't have) strongly suggests much more
intense scrutiny than would be consistent with rubber-stamping.
>From time to time, I'd suspected that some comments, especially
editorial ones, are posted to prove to everyone that the AD
involved actually did read the document.  That pattern and
associated discussions also strongly suggests that most ADs read
or otherwise carefully consider most documents.  Comments to
prove that one has read the document or that are generated
because, after doing all that work, one must have at least
_some_ comment may be a problem, but, if so, it is different
from the discussion on this thread.

> Therefore, diversity (on any axis) within the IESG can impact
> the results. But it is only at the output end, and diversity
> within WGs should be even more valuable in generating robust
> technical results.

Yes.  Over the years, I have been concerned about a different
issue with IESG diversity.  Today's IESG has 14 voting members
with 12 different company affiliations and no company apparently
supporting more than two ADs.  That is actually not bad in
either absolute terms or, I think, in comparison to the
community.  But we have had years in which company affiliations,
presumed sponsorship, and industry sectors have been much more
concentrated, possibly enough so to be fodder for antitrust
actions focused on particular sets of decisions especially if
industry partnerships and other relationships are considered.
More diversity provides some inherent protection against that
sort of problem as a useful side effect.

Of course, that organizational diversity doesn't help with the
100% European or North American males within a moderately narrow
age range dimensions of the broader issue.

   john

Re: Less Corporate Diversity

[Keith Moore]

On 03/20/2013 08:51 PM, Martin Rex wrote:

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).
IESG is the review body of last resort.  When WGs do a poor job of 
review, especially cross-area review, the burden falls on IESG to take 
up the slack.   The idea that IESG shouldn't actually do review is naive 
in the extreme, given the brokenness of IETF's structure.


Keith

Re: Less Corporate Diversity

[Keith Moore]

On 03/20/2013 07:20 PM, Martin Rex wrote:

The more diverse the "culture", the higher the probability for
miscommunication (misunderstanding and taking offense).
True, but without the diversity, the solutions provided by IETF are less 
likely to serve the interests of the extremely diverse Internet 
community.(And that's what we're here for.)


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).
Perhaps, but what we commonly do in IETF now is artificially narrow the 
scope of discussions to generate the appearance of consensus without the 
reality.   One result is that our protocols fail to meet the needs of a 
great many users.   Another result is that the Internet architecture has 
gone to hell, and we're now spending a huge amount of effort building 
kludges to fix the problems associated with other kludges and the 
new kludges will almost certainly create more problems resulting in a 
need for more kludges later.  (if you need an example, you need look no 
further than PCP and LSN)


Keith

Re: Less Corporate Diversity

[Brian E Carpenter]

Martin,

On 21/03/2013 00:51, Martin Rex wrote:
...
> 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).

I think you've misinterpreted the IESG procedures a bit. The definition
of a NO OBJECTION ballot in the IESG ranges from "I read it, and I have
no problem with it" to "I listened to the discussion, and I have no problem."
It's impossible to say objectively which of these extremes predominates,
but when I was General AD, I tried to at least speed-read every draft,
and studied the Gen-ART reviews carefully. Individual ADs vary in their
habits according to workload, but my sense is that there is a strong
sense of collective responsibility and definitely not a sense of
rubber stamping. You could check the statistices I suppose, but it
is normal that when there is a DISCUSS ballot, it is from an AD in
another IETF area, and very rarely from the co-AD in the same area.
That wouldn't happen if the IESG was a rubber-stamping machine.

Therefore, diversity (on any axis) within the IESG can impact the
results. But it is only at the output end, and diversity within WGs
should be even more valuable in generating robust technical results.

   Brian