For your information: additional details about the process and the coordination
group are now available, here:
https://www.icann.org/resources/pages/process-next-steps-2014-06-06-en
Jari Arkko
It was pointed out that I got the RFC numbers wrong. Sorry. I should have RFC
6220 (role of IETF protocol parameters operators) and RFC 2850 (IAB charter).
Jari
we need to keep the flexibility of bringing in someone new
agree
But my main issue is that the draft sounds like its trying to take over and
redefine an ISOC program, which I don't think the IETF can or should do. The
ISOC program has a purpose, a history and at least from my perspective
First off, we like to be in a situation where past IETF discussion, consensus,
RFCs, and current work program guide what the leaders say. I think this was
largely the case with the Montevideo statement as well. Of course these are
judgment calls. Please send us feedback - I for instance talk in
Dave:
On IANA:
Further, I believe there is no IETF context
RFC 6020 and
http://www.iab.org/wp-content/IAB-uploads/2011/07/IANA-IAB-FNOI-2011.pdf
Jari
As I noted in my review of the draft, the document has a core flaw in
its sense of history. It has invented an interpretation of rough
consensus that was not part of its original formulation.
I consider the current focus on reconciling minority views to be quite an
excellent enhancement
FWIW, on the issue of Informational RFCs seen as cast in stone:
I think I've seen that problem occasionally. I.e. people assigning a far too
high value to a document, just because it is an RFC. The world changes, our
understanding changes, and as Dave pointed out processes evolve… RFCs need to
Dave,
The fact that you had to reach back 2.5 years, to a frankly rather obscure
document that came from the IAB and not the broader IETF, demonstrates my
point that we lacked meaningful context
You asked for context and I provided a context. We can certainly debate how
meaningful it is.
All: Thanks much for the review changes.
Jari
On Oct 8, 2013, at 11:50 PM, Ben Campbell b...@nostrum.com wrote:
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please wait for
Glad to hear it - I think this is an enormously useful document.
I'm wondering if wg chair training at an upcoming meeting can't
be spent on it. Vancouver's too soon, but what about London?
Good idea.
Jari
This wording is surprising. It looks like it is the revelations that
undermined confidence, and not the NSA actions. I would prefer
something like, to avoid shooting the messenger:
Of course :-) We meant that the loss of privacy causes concern, not the
revelations.
Jari
The document talks about ways in which consensus processes can be successfully
run in the IETF. After the last few rounds of versions, I believe this document
is ready to move forward.
My goal is to publish it as an Informational RFC. It is an explanation of
principles and how they can be
Josh, Stephen,
It is important to understand the limitations of technology in this discussion.
We can improve communications security, and in some cases reduce the amount
information communicated. But we cannot help a situation where you are
communicating with a party that you cannot entirely
Olaf, John, Pete,
I know I have more mail to process and that you've already converged. I just
wanted to say something about this:
draft Proposed rewrite
While commonly less mature specifications will be published as
Informational or Experimental RFCs, the IETF may, in
exceptional cases,
Thanks for your review, Roni. The Gen-ART reviews by you and the rest of the
team are essential for me to do my work. And thank you authors for writing a
clear and useful document.
I must say that like Roni, I had some trouble with the document classification.
It did read more as an
Absolutely. I have noted at least 20 messages in the recent flood that
mention useful things the IETF can do, which is exactly what my provocative
message asked for. But (as Bruce's own recent posts show) the main weak spots
are not protocols and algorithms.
Yes.
Jari
I think we should seize this opportunity to take a hard look at what we can do
better. Yes, it is completely correct that this is only partially a technical
problem, and that there is a lot of technology that, if used, would help. And
that technical issues outside IETF space, like endpoint
And that no amount of communication security helps you if you do not the guy
at the other end.
Do not *trust* the guy at the other end. Typos, sigh…
I also agree that the minutes are the most complete/official record we have.
Jari
On Sep 6, 2013, at 1:40 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
I tend to agree with Pete - the minutes are more like an official
record, as well. BTW, the IESG Charter (RFC 3710) says:
The
Olaf, John, Scott,
In fact, going back to the language of RFC2026 for Full (now Internet)
Standard. It confirms that popularity (significant implementation) is one
necessary but not sufficient criterium.
Sorry. I was careless when I wrote about the effort. I didn't mean to suggest
that we
Olaf, Scott,
Apologies for a late reply on this (I was on vacation after the IETF). But
thank you for writing this draft. My general comment is that the draft makes
what in my mind is an accurate correction to our documents, aligning the
documents to the current reality. I'd be happy to take
There's a point that I think should be made here, something like:
In practice, interoperable implementations are commonly based on
Proposed Standard documents, so whatever design defects those
documents have tend to become part of the interoperable network,
perhaps in the form of
SM,
I assumed that the message was generated by the data tracker.
The secretariat sends out last call and WG review messages, but the data comes
from the tracker. For WGs, this is actually a relatively recent addition. A
while ago the proposed charters were not tracked in the database. In any
SM:
I certainly agree that in incidents like this, a timely notification is in
order. (Of course to the extent that the outage itself allows us to do that.
Sometimes the outage or the queue that has built up during the outage delays
sending a notification.)
And we normally do send
Peter: Thank you very much for your review.
Based on this review and my own review, I am recommending the approval of this
draft in today's telechat. (Note that other ADs have raised a number of other
issues, some of which I agree with, but I did not want to repeat their
comments.)
Jari
On
Thank you for your review, David. The Gen-ART reviews are important feedback
for me to understand where I should look more closely.
In this case your review caused me to read the draft in detail, and I now have
similar question as you did. I have raised a Discuss in my IESG ballot so that
we
David: Thank you. I have placed a no-objection ballot for this draft.
Jari
On Jul 29, 2013, at 2:20 PM, Black, David david.bl...@emc.com wrote:
The -06 version of this draft resolves all of the concerns raised by the
Gen-ART
review of the -05 version - the -06 version is ready for
First, I'd like to highlight something that is important. There is no inherent
preference to posting a lot, a moderate amount, or none at all. Everything
depends on context. If you are providing useful input and furthering the
discussion, a lot of mails is ok. And no mails can be a problem,
Very productive venue, easy to access city, several hotels near the venue
for alternatives, walkable area around the venue, lots of options for
restaurants, good public transit system, etc. And I enjoyed the social
social venue as well (thanks DENIC)!
I really do hope we return in the
I'd like to get a couple of volunteers to take notes in the plenary. Please
send mail, or see me at the front before the meeting. Thanks.
Jari
The missing two (diversity, IAOC) plenary slides have been uploaded. I'm sorry
that they were missed in the heat of the preparations for the meeting.
All materials are available at:
https://datatracker.ietf.org/meeting/87/materials.html
Jari
Dave,
I've been finding discussion and actions about newcomers far more interesting
this year, than most previous ones. So I think it's worth pressing on
several fronts, to see how we can both accommodate such folk better, as well
as be clear about when and where and how such
We have discussed diversity at the IETF at length. Yesterday, Pete Resnick and
I wrote an article about what we think the goal for the IETF should be, as well
as listing some of the early activities that we have taken at the IETF. Our
goal is making the IETF more inclusive for everyone who
Arturo:
Now, something general related to the blog. Perhaps it would be good to
enable comments, isn't it?
Yes, that has been issue that has bugged me as well. The IT team tells me that
it is problematic from a spam perspective, and they do not want me spending my
time
I agree with John that audio and other things would be useful, but Brian is
also correct that they do involve some work. Let us see what we can do on audio
for IETF-88. Past recordings of the tutorials are available at
http://www.ietf.org/edu/process-oriented-tutorials.html#newcomers.
The
Simon,
for your information, the Meetecho team is going to record five tutorials on
Sunday:
http://www.ietf.org/meeting/87/remote-participation.html#meetecho
We have already provided a URL for those who want to remotely attend the IAOC
Overview Session. If you think this might be of
(Dropping a few lists from the distribution.)
Brian, Dave,
It reads rudely when taken out of context. But try reading the whole
paragraph in RFC 3184:
IETF participants who attend Working Group meetings read the
relevant Internet-Drafts, RFCs, and e-mail archives beforehand, in
As I would like to know what it is I watched
http://www.youtube.com/watch?v=QAnW9HTkbsI It was a pleasant surprise to see
a new approach instead of the usual boring presentations.
Very nice indeed. Thanks for doing it!
(There's also http://www.youtube.com/watch?v=_G96ULX7Iak)
Jari
John,
In the interest of encouraging remote participation and
involvement in those BOFs, could these posters be made available
online before the reception? Will they eventually be
incorporated into the minutes?
Good questions. We can work on that…
And, incidentally, is there a way for
Janet,
I am another remote participant who would like to be able to subscribe to the
meeting-specific mailing list.
I can skip (myself) the ones about coffee and cookies, but definitely want
to read the ones about schedule changes, etc.
And even the other messages give me a taste
I see no reason why the 87attend...@ietf.org list shouldn't be open to remote
participants. Is that not the case already? We should be doing all we can to
encourage participation.
Several people pointed out already (in private e-mail) that the list might be
all that is needed, and it
Hi,
I just wanted to send pointers to two recent blog articles that I wrote:
A Different Internet
http://www.ietf.org/blog/2013/07/a-different-internet/
The Web of Things
http://www.ietf.org/blog/2013/07/the-web-of-things/
Jari
Hector,
You raise an important point - and one that isn't just about mentoring, but the
overall approach in our ability to involve more remote participation. We have
and will continue to improve the facilities to improve the remote participation
experience. Looking back, one big change in the
And the -05 version includes the text to address that editorial nit - it's
ready for publication as a Proposed Standard RFC. Many thanks to the authors
for productively addressing the review comments.
And many thanks to you, David, for your review. Based on this review and my own
review of
Peter,
Thank you very much for your detailed review. And Murray, thanks for taking
into account the comments. FWIW, I plan to ballot No-Objection for this draft
based on the Gen-ART review (and my own far less detailed review).
Jari
First, I wanted to agree with what Pat said:
While generally IETF is helped by cross pollination and multi-day attendance
is a good thing to encourage, there are times when the work of a particular
group is helped by the attendance of some subject matter experts who are only
interested in
Scott,
is there a reason to not disclose who the individual participant is?
No, but actually that text just came from the standard boilerplate for the last
call text in these cases. In reality has been several people asking for this to
be done, e.g., SM wrote a document about 2050 and a few
Toerless, SM, and others who commented on the importance of recognising people
who made contributions: I fully agree, of course. Giving credit for
contributions, be it about being the developer of a major protocol, having your
name on the author list, or being mentioned in the acknowledgments
i have never considered writng one. sour grapes make bad wine.
Errors do happen, for everyone and for all organisations. We do not treat
appeals as sour grapes at the IESG, IAB or other places that receive them. We
consider them an opportunity to review whether something was missed. At the
Ben, thank you very much for the review, and Michael, thank you for answering
and addressing the issues.
I am still concerned about the crypto profile question, however. I'd like to
understand what the lack of a profile specification means for interoperability
and the ability of others to use
Roni, Simo - thank you for the review and for addressing the issue. I plan to
ballot a No-Objection for this draft.
Jari
Tim,
was surprised to see a total of 15 proposed BoFs
That is a relatively big number. There is a very high attrition rate, however.
That people are coming to the IETF with proposals to do work is probably a
healthy thing; it would be more worrying if there were no BoFs proposed.
Indeed!
Chris: The last call on RFC 2050 bis has ended. The draft will be shortly on
the IESG telechat, up for an approval decision and/or suggestion for changes. I
personally think it is ready to move forward. That is not to say that we
wouldn't take comments, if you have some.
As for the rest of the
Phillip,
For the record, there have been several ongoing efforts. First, there is a
diversity design team. We expect some results from them before IETF-87, lets
deal with those when they come. Second, the IAOC has looked hard at the
possibilities for reaching further out in the geographical
John,
For the record, I still believe that 2050bis should be
published. Regardless of what I think of some of the things it
says, I think it is reasonably reflective of reality and that
reality is always worth documenting.
Thanks.
As to my more general comments, they were not really
I'm concerned about readers who aren't as
cognizant of and comfortable/familiar with the relationships among
OUIs and the identifiers based on them as people like you and me.
Thanks your review, David. The Gen-ART reviews are important for me in helping
decide if the documents may have issues
perhaps we should go to the source of the problem and require a phd
dissertation and defense from draft authors.
A couple of years ago I worked with someone who completed his PhD thesis on a
topic faster than it took to publish the RFC on the same topic… that was my
wake-up call for IETF
I am sad to hear about this. I remember Hugh from various IPsec test events.
And the lights… I still remember the lights.
Jari
Randy, Warren,
One (IMO) good idea that was mentioned recently (sorry, I cannot
remember by whom, may have been Jim Martin) was for someone from the
IETF to present a short summary of interesting work at NOG meetings.
this has been done many times. imiho, it has not stirred up much useful
Lloyd,
http://www.arkko.com/tools/recrfcstats/d-contdistr.html
(Jari, what time period is that across? Oceania doesn't rate a mention…)
Recent RFCs is anything from RFC 5400 onwards. An arbitrary definition.
And Oceania is listed under Australia per
http://en.wikipedia.org/wiki/Continent...
Mark:
I would take those numbers with a HUGE grain of salt (as Jari documents).
Indeed
For example, I've lived in Australia since 2006, and yet am only listed as
producing RFCs in the USA.
My apologies. I added a data item to recognise you…
Jari
by looking into the statistics of I-Ds and RFCs, it is strange that we get
sometimes high rate in the I-D going in IETF from some regions but the
success rate of I-Ds to become RFCs is very low (5- 50).
There seems to be a general pattern where new participants first participate
and/or
I'm not quite sure the currency exchange issues are key for this discussion.
FWIW, I think you can still budget in Euros for the Berlin meeting, but I'm
only 97% sure :-)
Anyway, I wanted to highlight that, as has been pointed out by many, just
meeting at some place makes little sense. But the
John,
* People aren't aware the IETF exists, or what it does, or that it has
an open participation model
* People don't read and write English well enough to be comfortable
participating
* People are unaccustomed to and perhaps uncomfortable expressing
overt disagreement
* People
James:
did you know that you have a audio/video realtime interactive communications
WG churning out proposals and solutions that is *actively* ignoring
emergency communications in its entirety? No? Look at RTCweb, which will
become a dominant form of interactive communications between
Vinayak,
Maybe several co-located meetings or having people from the IETF speak at
universities and regional ISOC chapters around the meeting might help. Also
showcasing the good work done by their Latin American peers might help as
well.
Good ideas. Thanks.
Jari
For what it is worth, I wanted to provide my perspective on this. I of course
believe that it is important that the IETF reaches out to an even more
international participation than it already has. This is first of all because
we really need the views from different types of organisations and
Dave, Ralph,
Jari has expressed the goal of having AD concerns be raised more publicly.
Moving AD review and comment to the IETF Last Call venue nicely accomplishes
this, too.
I just posted elsewhere a suggestion to move this review even earlier, to WG
last call. Accomplishes most of
And yes, it's hard to participate without spending (significant) time. I
don't know how else this could be done though. It's at least my opinion that
if time is made available, the barrier of entry is probably the lowest of any
similar organisation I can think of.
That is my experience as
I feel that the discussion is stuck on the different perceptions on whether an
AD's actions are either blocking reasonable progress, or an essential
correction to a mistake that went undetected.
I'd like to make a couple of observations. First of all, we at the IESG process
10-25 documents
Joe,
Broken, agreed.
Yep.
Unclear, nope - please review the NON-DISCUSS criteria, notably:
The motivation for a particular feature of a protocol is not clear enough. At
the IESG review stage, protocols should not be blocked because they provide
capabilities beyond what seems necessary
Just FYI that I wrote another article, this time on permissionless innovation
and the role of open standards. We've talked about these topics earlier, but
this has been on my mind recently - I've been traveling in recent weeks and
talking about the roles of various organisations and styles of
I wanted to send an update, after having discussed this topic in the IESG
retreat that we just had here in Dublin. The overall plan is to start with
three specific changes listed below. Note that these are approaches that we
have discussed, and more detailed plans will be developed in the
Heather, all,
You are correct, Peter. MISSREF and AUTH48 are not part of the RFC
Editor timed states, and the RFC Editor timed states have been largely
under 7 weeks for the last year.
Indeed. The actual time for what RFC Editor does for documents is quite short
(and thank you and others at
Hannes,
The aim of this group is to find out how to reference IETF RFC (and standards
from other organizations, like the W3C) since the European Commission seems
to be unable to just reference standards beyond a small set of organizations
(such as ETSI).
As you can imagine, the
Hannes,
Regarding your point about process changes I agree that we've struggled there.
But for some reason I'm quite optimistic that we can do the right changes.
Regarding your point on deployment time being even longer, my observation has
been that most changes have the right time, and that
Ted,
Bear in mind that one of the delays that can occur and is credited to the RFC
editor is author delays in AUTH48; I think another is document dependencies:
a document that has passed IESG review may wait indefinitely in the RFC
editor queue until the documents it depends on are
I wrote a blog article about how we do a fairly significant amount of reviews
and changes in the late stages of the IETF process. Next week the IESG will be
having a retreat in Dublin, Ireland. As we brought this topic to our agenda,
Pete and I wanted to raise the issue here and call for
I think the statistics are very interesting and we should continue developing
them, but we should also not be driven by them. I'll repeat again what I've
said before: I can see increasing both participation diversity and leadership
diversity being useful for the IETF. We are limited by various
Ted: Very nice post and good ideas. Thanks.
Jari
Dan: the original reason for wanting to understand who the meeting participants
are (as a subset of all IETF participants) was a desire to track our
participation. Similarly to how we already track where they come from, and
present that pie chart in the plenary.
You raise an issue about
Pete:
Your eyeballing had you put the ratio at about (snip)
FWIW, I took a database of first names, added a little piece of code on my
document statistics page to guess genders to calculate aggregate numbers. I get
results such as 13% of recent RFCs having female authors. Perhaps inline with
AB,
I think we do not want to change the nature of the IETF, we will still go with
organisation that is designed around what needs to be achieved. Two working
group chairs is a good, well working setup from a practical management
standpoint. We've seen examples elsewhere of what happens when
Responding to various people in one e-mail.
To summarise, we have procedures that say what kinds of Discusses are
appropriate, and personal engineering preferences are not. Legitimate issues
should be raised, however, and in the case of most big issues, the right
approach would be to send a
Toerless,
A question because my institutional memory does reach as far back:
How much was Europe represented over the decades in IETF leadership ?
Right now for example IESG seems to have maybe at least 5
europeans (don't really know how to figure out location for all of them,
those where
Melinda,
My own feeling is that if we were to find that the
numbers supported the notion that there's bias
present in the system we probably couldn't do anything
about it without tearing the organization apart, so,
I am actually a little bit more optimistic about it, for a couple of reasons.
Joel,
Different doesn't generally mean good, in the peering case.
There are plenty of examples of monopoly PTTs or regulators engaging in
behavior that impacts the usability of or availability of traffic exchange,
there's all sorts of market failures, and there's deliberately
of
this team should not stop other efforts or proposals from going forward. For
instance, there is an independent effort in looking at improvements in
mentoring.
Jari Arkko
-
For the purposes of this team, we think of diversity as something that covers
international participation, different
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
John,
Fine plan if we can put a stop to having breakfast and lunch be
the prime target for assorted management and coordination
meetings.
Yes.
I would, however, favor conducting a lottery among, say,
first-year attendees (but not first time unless they qualified
by useful mailing list
.pdf (page 59).
Jari Arkko
IETF Chair
Thanks for describing this, David. I found it very useful and enlightening.
Jari
On Mar 12, 2013, at 4:41 PM, David Harrington dbharring...@comcast.net wrote:
Hi,
Many suggestions have been made about ways to resolve the issue of finding
suitable candidates for TSV Area Director, or
Dave, all,
We talked about this in the Monday plenary. Obviously people have read or
understood the situation in different ways. But that should not stop us from
reaching a common understanding of the situation now that we realised we had
read it differently. You indicated that you thought you
By way of testing whether I understand your text, here is a re-coding, meant
to be simplistic and procedural:
1. The body (and/or the controlling documents for the body) defines its
slots (positions). Nomcom fills the slots.
2. The body offers its view of the requirements for
Ted,
Efforts to increase to diversity are a very different optimization--by
making more visible that opportunities are present for all, these
initiatives attempt to increase the pool of talent over time.
Thanks for your thoughts. I thought the above was an important observation.
Jari
positions. But I am sure we
will make a lot of progress on this, and the design team would be important in
helping the leadership understand what actions we can take. So thanks again for
making the suggestion.
Jari Arkko
The IETF meeting is beginning on Sunday. I'd like to welcome everyone to the
meeting! This blog highlights some of topics that I find most interesting in
the meeting:
http://www.ietf.org/blog/2013/03/welcome-to-ietf-86/
Jari
FWIW, I do believe that noncoms may decide for themselves what the final
requirements are for specific positions. This is true in this case as well. The
IESG has a role to send the starting point for these requirements, the desired
expertise. (But it is possible that the nomcom does not see a
A few personal thoughts follows. For the record this is completely at the
general level, I have no inside knowledge about the nomination process.
I am of the opinion that ADs should not be selected based on them being rare
super experts. The ability to learn, as Sam pointed out, is perhaps
Margaret,
However, I question the wisdom of choosing to work on this issue _right now_
in the middle of the nomcom selection process, rather than choosing the best
candidates we can and working on this problem for next year, or for future
years. It doesn't seem likely that there are
1 - 100 of 543 matches
Mail list logo
