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
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 *
In message <8d23d4052abe7a4490e77b1a012b63077516d...@mbx-01.win.nominum.com>,
Ted Lemon writes:
> On May 2, 2013, at 9:56 PM, Mark Andrews 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
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 pub
-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 wrote:
>
>> source control
>
> I don't think it has been emphasized enough how important that is from a
> document quality perspective.
>
> More importan
On May 2, 2013, at 9:56 PM, Mark Andrews 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 compliant, and of
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 o
On May 2, 2013, at 9:47 PM, Dave Crocker 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
review, and hen
On May 2, 2013, at 9:41 PM, Carsten Bormann 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 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 activ
On May 2, 2013, at 6:58 PM, Dave Crocker 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 think another i
On May 3, 2013, at 01:13, Peter Saint-Andre 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.
People who aren'
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 force
> 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
-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
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 t
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
-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 pe
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 IES
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 goal
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 su
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).
Rega
Pete Resnick 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 don't limit your thinking
Hannes Tschofenig 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 the IESG reviews for
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 deal
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 positio
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 al
On May 2, 2013, at 4:32 PM, Michael Richardson wrote:
>
>> "SM" == SM 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]?
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 07:21, "Eggert, Lars" 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" signal to
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
po
On 05/02/2013 04:19 PM, Fred Baker (fred) wrote:
>
> On May 2, 2013, at 8:12 AM, Stephen Farrell
> 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
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.o
On Wed, May 1, 2013 at 9:33 AM, Michael Richardson wrote:
> <#part sign=pgpmime>
>
> > "Jari" == Jari Arkko 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
> Jari> process. Next week t
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 slip
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 ca
On May 2, 2013, at 8:12 AM, Stephen Farrell
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 busy with their day-job
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 wast
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 o
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
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
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 a
> "SM" == SM 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 fact
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 Di
- Original Message -
From: "Jari Arkko"
To: "IETF list"
Cc: "Pete Resnick"
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
reviews and changes in the late stages of the IETF pro
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 paten
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 existi
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
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 al
49 matches
Mail list logo
