Hi Yoav,
On 04/30/2013 08:09 PM, Yoav Nir wrote:
Hi Martin,
On Apr 30, 2013, at 6:21 PM, Martin Stiemerling
martin.stiemerl...@neclab.eu wrote:
Hi Ted,
On 04/30/2013 01:19 AM, Ted Hardie wrote:
So, this page: http://www.ietf.org/iesg/members.html still has
TBD listed for one of the
Hi Matt, Allison,
At 23:32 01-05-2013, Martin Stiemerling wrote:
However, I do not have the answers to your questions, i.e., I am the
wrong person to ask or answer.
:-)
The NomCom Chair posted a statement on March 9 [1] where it is mentioned that:
The Nomcom will continue its work until
On Tue 30/Apr/2013 20:02:11 +0200 Edward Lewis wrote:
On Apr 30, 2013, at 12:28, Alessandro Vesely wrote:
...The basic fact that killed the SPF type is the ability to use
TXT as a replacement. There must be an analogous of Gresham's
law: Bad types drive out good ones.
I disagree with the
On Wed 01/May/2013 03:04:52 +0200 Mark Andrews wrote:
In message 517ff144.5040...@tana.it, Alessandro Vesely writes:
On Tue 30/Apr/2013 01:07:42 +0200 Mark Andrews wrote:
SPF is techically superior to TXT is lots of ways.
[...]
For TXT you need to lookup the existing RRset, extract
the
On Mon 29/Apr/2013 05:14:50 +0200 John Levine wrote:
The Patently-O blog has a new guest post by Jorge Contreras, who among
other things is the IETF's lawyer, on a recent court decision about
how to determine what's an appropriate RAND royalty rate for
standard-essential patents. The patents
- Original Message -
From: Jari Arkko jari.ar...@piuha.net
To: IETF list ietf@ietf.org
Cc: Pete Resnick presn...@qti.qualcomm.com
Sent: Wednesday, May 01, 2013 4:33 PM
Subject: call for ideas: tail-heavy IETF process
I wrote a blog article about how we do a fairly significant amount of
Subject: Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE Date: Thu, May 02, 2013 at
11:20:22AM +0200 Quoting Alessandro Vesely (ves...@tana.it):
What percentage of NS servers use dynamic updates primarily? (I only
happened to use nsupdate occasionally, e.g. to fix dhcp hiccups.)
Every Active
SM == SM s...@resistor.net writes:
SM There is an open position which has not been filled. Is NomCom
SM 2012 still continuing its work?
SM The IETF usually has a NomCom Chair. Who is the current NomCom
SM Chair [2]?
The nomcom chair continues to do the work.
The nomcom is
In your previous mail you wrote:
If we are unwilling to bring RFC back to a place were it does not
equal STD, then we need to create a new category of document which
amounts to fully baked ID. Things like IANA allocations could occur
at that point.
= IMHO the last point (IANA
And here we come to a conflict between what we as a community would
like, versus what the market decides. This leads to a few questions:
1. Do we have to make a decision at any point from a protocol
standpoint that the market has in fact made a decision? I ask this
question because I performed
I your blog, you wrote:
Having been involved in the process for many years, often the bigger changes
at this stage relate to cross-area issues, or the fact that the careful
reviews from the IETF last call, directorates, and 15 ADs often represents a
significant increase in the number of
On 05/02/2013 03:54 PM, Fred Baker (fred) wrote:
I your blog, you wrote:
Having been involved in the process for many years, often the bigger changes
at this stage relate to cross-area issues, or the fact that the careful
reviews from the IETF last call, directorates, and 15 ADs often
Mr. Resnick, for the record, I wasn't upset. Believe it or not, I was
actually applying an suggestion posted last month or so here with the
IETF diversity talks to help get a major WG issue resolved, one with a
near surety of an appeal, resolved and addressed much faster and hence
avoid a
On May 2, 2013, at 8:12 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
When asked if more could be done, (without any specific proposal
for what to do) the response was that increasing the workload
would maybe lead to a significant drop in that 80% figure since
secdir folks are also
I'm glad folks have brought this up.
I contacted Jari about this the other day and he has advised me to get
started on the 2013 nomcom volunteer recruiting now, even though we have a
period of overlap with the 2012 nomcom. This happened at least once before;
we have an overriding concern not to
Hi,
I contacted Jari about this the other day and he has advised me to get started
on the 2013 nomcom volunteer recruiting now, even though we have a period of
overlap with the 2012 nomcom. This happened at least once before; we have an
overriding concern not to cause the 2013 schedule to
On Wed, May 1, 2013 at 9:33 AM, Michael Richardson mcr+i...@sandelman.cawrote:
#part sign=pgpmime
Jari == Jari Arkko jari.ar...@piuha.net writes:
Jari I wrote a blog article about how we do a fairly significant
Jari amount of reviews and changes in the late stages of the IETF
Hi, Robert
Thanks a lot for your continuous careful review.
Please see replies inline.
-Original Message-
From: Robert Sparks [mailto:rjspa...@nostrum.com]
Sent: Wednesday, May 01, 2013 12:33 AM
To: re...@ietf.org; draft-ietf-6renum-gap-analy...@tools.ietf.org
Cc: gen-...@ietf.org;
On 05/02/2013 04:19 PM, Fred Baker (fred) wrote:
On May 2, 2013, at 8:12 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
When asked if more could be done, (without any specific proposal
for what to do) the response was that increasing the workload
would maybe lead to a significant
Hi Alessandro, Doug,
My task is to keep draft-ietf-spfbis-4408bis moving forward and to
maintains a critical and technical perspective of the draft. The two
weeks Working Group Last Call for draft-ietf-spfbis-4408bis-14 was
announced on April 9, 2013 [1]. The document shepherd review was
On May 2, 2013, at 07:21, Eggert, Lars l...@netapp.com wrote:
Yeah, all kinds of issues, but if we created a new thing here in between WGLC
and PS, the broader industry would never understand.
That is a matter of naming and marketing (candidate RFC?).
The this is baked, go and implement it
Hi Jari, Hi Pete,
three issues come to my mind:
a) From several past discussions it is clear that we are not really able
(maybe not willing) to change our processes. Even the smallest change
faces a lot of resistance. Due to the resistance our response is to
back-off and we solve a different
On May 2, 2013, at 4:32 PM, Michael Richardson mcr+i...@sandelman.ca wrote:
SM == SM s...@resistor.net writes:
SM There is an open position which has not been filled. Is NomCom
SM 2012 still continuing its work?
SM The IETF usually has a NomCom Chair. Who is the current
One quick thing:
On 5/2/13 1:14 PM, Hannes Tschofenig wrote:
From several past discussions it is clear that we are not really able
(maybe not willing) to change our processes.
Note that although we did ask the bigger question, the more central
question relates to what we on the IESG can do
On 5/2/2013 9:02 AM, S Moonesamy wrote:
If anyone has any objection I suggest raising it during the Last Call.
Given that you can be 100% confident that the issue will be raised
during IETF LC, wouldn't it be better to hash it out in the WG (as we
have attempted to do)? Or is the WG's
Doug,
No hat.
On Thu, May 02, 2013 at 12:22:03PM -0700, Doug Barton wrote:
Given that you can be 100% confident that the issue will be raised
during IETF LC, wouldn't it be better to hash it out in the WG (as
we have attempted to do)? Or is the WG's position, we have no
intention of dealing
Hannes Tschofenig hannes.tschofe...@gmx.net wrote:
There is no interest to research where delay really happen.
This is an important point. We might want to measure before we cut.
[...] From my
own experience I noticed that there are many reasons for delay and I am not
sure I can blame it to
Pete Resnick presn...@qti.qualcomm.com wrote:
Note that although we did ask the bigger question, the more central
question relates to what we on the IESG can do all by ourselves (without
making changes to the formal processes) that we can discuss during our
IESG meeting next week. So
Would people like to see a new version of the SIRS draft?
In addition to the questions John raised below, Francis
and others mentioned: lack of reviewers. Also there is the
question of overlap with Area review teams such as secdir,
and there is accumulated experience from Gen-ART (RFC 6385).
In your previous mail you wrote:
We want the highest quality documents possible for developers to
translate into implementations.
= I am afraid this statement is not fully consistent.
Regards
francis.dup...@fdupont.fr
PS: note it is not an attack against you: in fact you gave a good
As a non-native English speaker, but a language pedant nonetheless, I
can empathize with people who put Discusses on badly written documents.
I suggest that we budget for a number of WG drafts per year (say, 20
IETF-wide) to go through professional, paid-for heavy-duty editing, with
these
On 5/2/13 11:14 AM, Hannes Tschofenig wrote:
b) There is no interest to research where delay really happen. Your
statistics just tell that there is delay but not why (of course). From
my own experience I noticed that there are many reasons for delay and
I am not sure I can blame it to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
As a non-native English speaker, but a language pedant nonetheless, I can
empathize with people who put Discusses on badly written documents.
I suggest that we budget for a number of WG drafts per
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
On 5/2/2013 3:25 PM, Jari Arkko wrote:
But the delay was really not my main concern. Primarily because I think other issues such
as transparency to the working group or late surprises are more fundamental issues than
mere timing. But also because I actually*do* have some statistics that seem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 5/2/13 4:03 PM, Marc Petit-Huguenin wrote:
On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
As a non-native English speaker, but a language pedant
nonetheless, I can empathize with people who put Discusses on
badly written documents.
I suggest
Working groups were taking around 500 days and now take around 600.
The IESG was taking around 200 days and now takes around 110.
The RFC then and now takes around 100 days (with lots of variation
between the then and the now, of course.)
Considering the 'now'
Hi Doug,
At 12:22 02-05-2013, Doug Barton wrote:
Given that you can be 100% confident that the issue will be raised
during IETF LC, wouldn't it be better to hash it out in the WG (as
we have attempted to do)? Or is the WG's position, we have no
intention of dealing with this unless we're
On May 3, 2013, at 01:13, Peter Saint-Andre stpe...@stpeter.im wrote:
source control
I don't think it has been emphasized enough how important that is from a
document quality perspective.
More importantly for this discussion, it also somewhat mitigates the document
editor as a choking point.
On May 2, 2013, at 6:58 PM, Dave Crocker d...@dcrocker.net wrote:
The RFC then and now takes around 100 days (with lots of variation
between the then and the now, of course.)
Bear in mind that one of the delays that can occur and is credited to the RFC
editor is author delays in AUTH48; I
On 5/2/2013 4:13 PM, Peter Saint-Andre wrote:
Instead of imposing even more work on the RFC Editor team, I suggest
that you find someone in the WG, in your company, in the IETF
community (etc.) to help with the language issues. I did this recently
with a document in one of the WGs where I'm
On May 2, 2013, at 9:41 PM, Carsten Bormann c...@tzi.org wrote:
People who aren't aware of it should look at the httpbis github experiment.
The pull request is a powerful model of WG collaboration.
Several authors in the dhc working group have been doing the same thing, to
good effect.
On May 2, 2013, at 9:47 PM, Dave Crocker d...@dcrocker.net wrote:
If the community does not have enough interest in the work to write it well,
it has bigger problems that won't be remedied by more RFC Editor effort...
Also worth considering is that if a document is hard to read, it is hard to
In message 5182828c.3040...@isdg.net, Hector Santos writes:
Mr. Resnick, for the record, I wasn't upset. Believe it or not, I was
actually applying an suggestion posted last month or so here with the
IETF diversity talks to help get a major WG issue resolved, one with a
near surety of an
On May 2, 2013, at 9:56 PM, Mark Andrews ma...@isc.org wrote:
How do we deal with sites?
How do we deal with vendors that ship such product?
I say we punch 'em.
Seriously, the IETF doesn't have an enforcement arm. It's up to buyers to
check to see that what they are buying is protocol
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/02/2013 06:41 PM, Carsten Bormann wrote:
On May 3, 2013, at 01:13, Peter Saint-Andre stpe...@stpeter.im wrote:
source control
I don't think it has been emphasized enough how important that is from a
document quality perspective.
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
In message 8d23d4052abe7a4490e77b1a012b63077516d...@mbx-01.win.nominum.com,
Ted Lemon writes:
On May 2, 2013, at 9:56 PM, Mark Andrews ma...@isc.org wrote:
How do we deal with sites?
How do we deal with vendors that ship such product?
I say we punch 'em.
Seriously, the IETF doesn't have
seems to me that
o spf is still used, whether we think it is a good idea or not
o spf is using the spf rrtype
o we don't shoot an rrtype which is still being used
o overloading txt with a whole lot of things we don't like is
stupid++ for s many reasons
if you don't like spf, then
Total of 226 messages in the last 7 days.
script run at: Fri May 3 00:53:03 EDT 2013
Messages | Bytes| Who
+--++--+
7.08% | 16 | 6.62% | 118279 | d...@dcrocker.net
3.54% |8 | 3.01% |53739 | ves...@tana.it
The IESG has approved the following document:
- 'MPLS-TP Applicability; Use Cases and Design'
(draft-ietf-mpls-tp-use-cases-and-design-08.txt) as Informational RFC
This document is the product of the Multiprotocol Label Switching Working
Group.
The IESG contact persons are Adrian Farrel and
The 2012-2013 IETF Nominating committee (Nomcom) is pleased to
announce the selection of Spencer Dawkins for the position of Transport
Area Director on the IESG. The IAB (in its role as a confirming body)
confirms this selection and Spencer has agreed to serve the community in
this role.
Hello,
During IETF 86, the IAB formally approved the RFC Format Requirements
and Future Development document for publication. This draft outlines
the requirements gathered from the communities of interest regarding the
Canonical format for the RFC Series. With those requirements in hand,
the
53 matches
Mail list logo
