The problem I have is not so much with the decision to deprecate SPF
rrtype, it will remove this particular SPF protocol dual SPF/TXT call
overhead in the network, but more so about what it says for future
applications.
There will no incentive to design DNS applications with specific types,
On Tue 30/Apr/2013 21:54:11 +0200 David Conrad wrote:
On Apr 30, 2013, at 11:12 AM, Dave Crocker d...@dcrocker.net wrote:
What is the IETF-approved timeframe in which the market is
allowed to accept/reject a particular technology?
I've no idea what the lower limit is or should be, but I'm
On Tue 30/Apr/2013 19:11:15 +0200 Doug Barton wrote:
On 04/30/2013 09:28 AM, Alessandro Vesely wrote:
While it's too late for SPF, we can learn this lesson.
As has been repeatedly pointed out in the discussion on both dnsext
and spfbis, it is NOT too late for SPF. The way forward is simple:
On 4/30/13 7:45 PM, Sam Hartman wrote:
So my personal opinion is that this is a valid discussion to be having
even if we're having it again in IETF LC.
Folks,
This document is *not* in IETF LC. A particular WG member, who was
apparently upset with the tone of the argument on the SPFBIS and
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
#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
Jari process. Next week the IESG will be having a retreat in
Jari Dublin, Ireland.
On May 1, 2013, at 18:33, Michael Richardson mcr+i...@sandelman.ca wrote:
we need to create a new category of document which
amounts to fully baked ID
Yes. (I'm not sure it's a category, it might just be a stage.)
There is a stage in the development of a protocol where I no longer want to
On 5/1/13 10:39 AM, Carsten Bormann wrote:
On May 1, 2013, at 18:33, Michael Richardson mcr+i...@sandelman.ca
wrote:
we need to create a new category of document which amounts to
fully baked ID
Yes. (I'm not sure it's a category, it might just be a stage.)
Isn't that Proposed Standard?
On May 1, 2013, at 10:11 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
On 5/1/13 10:39 AM, Carsten Bormann wrote:
On May 1, 2013, at 18:33, Michael Richardson mcr+i...@sandelman.ca
wrote:
we need to create a new category of document which amounts to
fully baked ID
Yes. (I'm not sure
On 5/1/13 11:27 AM, Paul Hoffman wrote:
On May 1, 2013, at 10:11 AM, Peter Saint-Andre stpe...@stpeter.im
wrote:
On 5/1/13 10:39 AM, Carsten Bormann wrote:
On May 1, 2013, at 18:33, Michael Richardson
mcr+i...@sandelman.ca wrote:
we need to create a new category of document which amounts
Michael == Michael Richardson mcr+i...@sandelman.ca writes:
Michael If we are unwilling to bring RFC back to a place were it
Michael does not equal STD, then we need to create a new category
Michael of document which amounts to fully baked ID. Things like
Michael IANA
The blog nicely classes the problem as being too heavy-weight during
final stages. The quick discussion thread seems focused on adding a
moment at which the draft specification is considered 'baked'.
I think that's still too late.
Certainly it could be useful, but it's still very late in
Sam == Sam Hartman hartmans-i...@mit.edu writes:
Michael If we are unwilling to bring RFC back to a place were it
Michael does not equal STD, then we need to create a new category
Michael of document which amounts to fully baked ID. Things like
Michael IANA allocations could
Dave == Dave Crocker d...@dcrocker.net writes:
Dave I think that's still too late.
Dave Certainly it could be useful, but it's still very late in the
Dave process.
It's too late for Internet Changing Things (BGP4, TCP, IPv6 Header Options)..
It's still too early for things we
OK.
1) this idea is baked enough for cross-area review to make sense.
2) the protocol is not going to change significantly, one could
implement.
3) any future changes need thus to take into account impact on
existing implementations... BUT that doesn't mean that we can't
change things.
Hi Jari,
Thanks for the blog, and I agree with it. My ideas are below and sorry if
not short,
I may not have the full solution because never met participants in
meeting, but I think the source of the problem is as follows:
1- Many technical people feel better to discuss face to face (f2f) than
At 08:33 01-05-2013, Jari Arkko wrote:
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
On May 1, 2013, at 20:11, Michael Richardson mcr+i...@sandelman.ca wrote:
It's what PS *ought* to have been, and what RFCs were prior to
1990 or so.
One problem is certainly the cognitive barrier imposed by the RFC process.
-- RFCs never change, so you want to get them right;
-- there is a
How about having a running list (or registry) of IETF RFCs that have become the
de-facto standards?
Best regards,
Kathleen
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Carsten
Bormann
Sent: Wednesday, May 01, 2013 3:33 PM
To: Michael
Moriarty, == Moriarty, Kathleen kathleen.moria...@emc.com writes:
Moriarty How about having a running list (or registry) of IETF RFCs
Moriarty that have become the de-facto standards?
So, the STD series is pretty exactly this.
Newtrk also proposed more than one level of this.
--
On 02/05/2013 05:59, Dave Crocker wrote:
The blog nicely classes the problem as being too heavy-weight during
final stages. The quick discussion thread seems focused on adding a
moment at which the draft specification is considered 'baked'.
I think that's still too late.
What, you agree
On 5/1/2013 1:05 PM, Brian E Carpenter wrote:
On 02/05/2013 05:59, Dave Crocker wrote:
The blog nicely classes the problem as being too heavy-weight during
final stages. The quick discussion thread seems focused on adding a
moment at which the draft specification is considered 'baked'.
I
A draft does get cross-area review, at least once, often more than once.
Some drafts in some WGs get it earlier than others, by explicit
invitation. Others don't get it until the latest they can, when they go
to last call ... but a process point for cross-area review during WG
handling, already
On May 1, 2013, at 5:00 PM, Scott Brim s...@internet2.edu wrote:
Let's rename last call to
something like IETF review and stop giving people the wrong
expectations. Review outside the WG is vital, can be done repeatedly,
and must be done by the whole IETF at least once.
Yup. The term last
On May 1, 2013, at 1:59 PM 5/1/13, Dave Crocker d...@dcrocker.net wrote:
The blog nicely classes the problem as being too heavy-weight during final
stages. The quick discussion thread seems focused on adding a moment at
which the draft specification is considered 'baked'.
I think
On May 1, 2013, at 5:00 PM 5/1/13, Scott Brim s...@internet2.edu wrote:
A draft does get cross-area review, at least once, often more than once.
Some drafts in some WGs get it earlier than others, by explicit
invitation. Others don't get it until the latest they can, when they go
to last
On 01/05/13 21:05, Brian E Carpenter wrote:
On 02/05/2013 05:59, Dave Crocker wrote:
The blog nicely classes the problem as being too heavy-weight during
final stages. The quick discussion thread seems focused on adding a
moment at which the draft specification is considered 'baked'.
I think
On 01/05/13 21:05, Brian E Carpenter wrote:
On 02/05/2013 05:59, Dave Crocker wrote:
The blog nicely classes the problem as being too heavy-weight during
final stages. The quick discussion thread seems focused on adding a
moment at which the draft specification is considered 'baked'.
I think
On 05/01/13 17:43, Ralph Droms allegedly wrote:
On May 1, 2013, at 1:59 PM 5/1/13, Dave Crocker d...@dcrocker.net wrote:
I suspect that an earlier exercise at summarizing functional goals and
design approaches and issues will have a number of benefits, beyond enabling
earlier external
On May 1, 2013, at 19:35, Peter Saint-Andre stpe...@stpeter.im wrote:
Sorry: oughtn't that be Proposed Standard?
Yep, it ought to.
Crazy idea: Call a draft PS when it completes WG last-call and give it an RFC
number, call it something else when it passes IESG review (draft standard? :-)
and
The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Distributing Address Selection Policy using DHCPv6'
draft-ietf-6man-addr-select-opt-10.txt as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has approved the following document:
- 'Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID)
in Shared Address Deployments'
(draft-ietf-intarea-nat-reveal-analysis-10.txt) as Informational RFC
This document is the product of the Internet Area Working Group.
The
The IPsecME Working Group will hold a virtual interim meeting on
Thursday, May 16, 2013 via a phone bridge. The meeting will focus on
whether solutions are needed for fragmentation of IKEv2 messages, and
potential options in this space. For more background, see
The IESG has approved the following document:
- 'Link Metrics for the Mobile Ad Hoc Network (MANET) Routing Protocol
OLSRv2 - Rationale'
(draft-ietf-manet-olsrv2-metrics-rationale-04.txt) as Informational RFC
This document is the product of the Mobile Ad-hoc Networks Working Group.
The IESG
34 matches
Mail list logo
