Hi,
this thread seems to have converged on getting the draft to address the
points in the email below before getting it evaluated by the IESG.
Andrew, could you please take care of adding text to the draft
addressing those points?
People have asked about the history of this draft and there have
Ted,
What I like about this message is that you have demonstrated the
*potential* severability of these issues. Things are set up as they are
for a matter of scaling. Clearly it ain't perfect, and as one of my
mentors would say, that represents an opportunity. It's also pretty
clear that we
At 15:26 09-09-2013, The IESG wrote:
The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'Threat Model for BGP Path Security'
draft-ietf-sidr-bgpsec-threats-06.txt as Informational RFC
The IESG plans to make a decision in the
Hi James,
thanks for clarifying your concern. With respect to the INSIPID WG
managing to successfully complete its charter, as you know, there have
already been a few people that have expressed concerns about it. Some
people seem to believe that there is a non-zero probability for INSIPID
to
Hello,
I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide
Colleagues
[I have added a number of people who were active in the discussion previously
to the CC, my apologies if that is bad etiquette but I wanted to make you
explicitly aware of this.]
Based on the discussion so far I've made a few modifications to the draft. I
am trying to
On 9/12/13 2:07 PM, Ted Lemon ted.le...@nominum.com wrote:
On Sep 12, 2013, at 1:49 PM, Dickson, Brian bdick...@verisign.com
wrote:
In order to subvert or redirect a delegation, the TLD operator (or
registrar) would need to change the DNS server name/IP, and replace the
DS
record(s).
Someone
On 9/12/13 7:24 AM, Theodore Ts'o ty...@mit.edu wrote:
On Wed, Sep 11, 2013 at 03:38:21PM -0400, Phillip Hallam-Baker wrote:
I disagree. DNSSEC is not just DNS: its the only available,
deployed, and
(mostly) accessible global PKI currently in existence which also
includes a
constrained
On 08/21/2013 09:20 PM, Romascanu, Dan (Dan) wrote:
Dear authors of draft-ietf-xrblock-rtcp-xr-qoe,
Please confirm that any and all appropriate IPR disclosures required for full
conformance with the provisions of BCP 78 and BCP 79 for this document have
already been filed. The confirmation
On 08/21/2013 09:20 PM, Romascanu, Dan (Dan) wrote:
Dear authors of draft-ietf-xrblock-rtcp-xr-qoe,
Network Working Group A. Clark
Internet-Draft Telchemy
Intended status: Standards Track
On 08/21/2013 09:20 PM, Romascanu, Dan (Dan) wrote:
Dear authors of draft-ietf-xrblock-rtcp-xr-qoe,
Please confirm that any and all appropriate IPR disclosures required for full
conformance with the provisions of BCP 78 and BCP 79 for this document have
already been filed. The confirmation
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o ty...@mit.edu wrote:
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are worried about the NSA, both of these are US
corporations), the whole
On 08/21/2013 09:20 PM, Romascanu, Dan (Dan) wrote:
Dear authors of draft-ietf-xrblock-rtcp-xr-qoe,
Network Working Group A. Clark
Internet-Draft Telchemy
Intended status: Standards Track
On 08/21/2013 09:20 PM, Romascanu, Dan (Dan) wrote:
Dear authors of draft-ietf-xrblock-rtcp-xr-qoe,
Please confirm that any and all appropriate IPR disclosures required for full
conformance with the provisions of BCP 78 and BCP 79 for this document have
already been filed. The confirmation
Chiming in a bit late here, however, the availability of stratum 1 clocks
and stratum 2 class time data on non IP and/or non interconnected networks
is now so large, I question why one would run NTP outside of the building
in many cases, certainly in an enterprise of any size.
A 1pulse per second
On 9/12/13 05:47, Gonzalo Camarillo wrote:
Therefore, this draft registers the Session-ID header field with the
IANA. The designated expert is reviewing this registration, per the
rules in RFC 5727.
Yes, I am, and the only reason I didn't rubberstamp this for
registration as soon as it hit my
Here's what I do feel strongly about: whatever the plan of record needs to be
clearly recorded in a place that people will find it. If draft-kaplan
registers Session-ID, we need two changes to the existing documents: First,
draft-kaplan needs to be crystal clear about the plan of record
Hi Olaf,
At 07:56 13-09-2013, Olaf Kolkman wrote:
Based on the discussion so far I've made a few modifications to the
draft. I am trying to consciously keep this document to the minimum
that is needed to achieve 'less is more' and my feeling is that
where we are now is close to the sweetspot
Based on the discussion so far I've made a few modifications to the draft.
I am trying to consciously keep this document to the minimum that is needed
to achieve 'less is more' and my feeling is that where we are now is close
to the sweetspot of consensus.
Section 4 makes me happy. I think
On 13 sep. 2013, at 19:17, S Moonesamy sm+i...@elandsys.com wrote:
The intended status would have to be BCP instead of Informational.
Correct…. fixed on trunk.
In Section 3.1:
A specific action by the IESG is required to move a
specification onto the standards track at the
On Sep 13, 2013, at 2:32 PM, Olaf Kolkman o...@nlnetlabs.nl wrote:
On 13 sep. 2013, at 19:17, S Moonesamy sm+i...@elandsys.com wrote:
The intended status would have to be BCP instead of Informational.
Correct…. fixed on trunk.
In Section 3.1:
A specific action by the IESG
On 13 sep. 2013, at 20:03, Carsten Bormann c...@tzi.org wrote:
On Sep 13, 2013, at 16:56, Olaf Kolkman o...@nlnetlabs.nl wrote:
* Added the Further Consideration section based on discussion on the
mailinglist.
I believe the current document is fine for a major part of the IETF
On Sep 13, 2013, at 16:56, Olaf Kolkman o...@nlnetlabs.nl wrote:
* Added the Further Consideration section based on discussion on the
mailinglist.
I believe the current document is fine for a major part of the IETF standards
activities.
It is, however, important to keep in mind that the
On Sep 13, 2013, at 20:50, Olaf Kolkman o...@nlnetlabs.nl wrote:
I am trying to see what one gets if one translates the fallacies into
positive actions, or answer the question on how do you cope with the fallacy.
I notice that your draft observes but doesn't seem to recommend.
Indeed, the
--On Friday, September 13, 2013 16:56 +0200 Olaf Kolkman
o...@nlnetlabs.nl wrote:
...
Based on the discussion so far I've made a few modifications
to the draft. I am trying to consciously keep this document
to the minimum that is needed to achieve 'less is more' and
my feeling is that
Masataka Ohta wrote:
It is still a hierarchical model of trust. So at the top, if you
don't trust Verisign for the .COM domain and PIR for the .ORG domain
(and for people who are worried about the NSA, both of these are US
corporations), the whole system falls apart.
Right. PKI is
The IESG has received a request from the Emergency Context Resolution
with Internet Technologies WG (ecrit) to consider the following document:
- 'Public Safety Answering Point (PSAP) Callback'
draft-ietf-ecrit-psap-callback-10.txt as Proposed Standard
The IESG plans to make a decision in the
The IESG has received a request from the Emergency Context Resolution
with Internet Technologies WG (ecrit) to consider the following document:
- 'Extensions to the Emergency Services Architecture for dealing with
Unauthenticated and Unauthorized Devices'
A new IETF working group has been proposed in the Security Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-23.
DTLS In
A new IETF working group has been proposed in the Transport Area. The
IESG has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-23.
Active
A new IETF working group has been proposed in the Internet Area. The IESG
has not made any determination yet. The following draft charter was
submitted, and is provided for informational purposes only. Please send
your comments to the IESG mailing list (iesg at ietf.org) by 2013-09-23.
IPv6 over
The Dynamic Host Configuration (dhc) working group in the Internet Area
of the IETF has been rechartered. For additional information please
contact the Area Directors or the WG Chairs.
Dynamic Host Configuration (dhc)
Current Status: Active WG
The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Session Initiation Protocol (SIP) History-Info Header Call Flow
Examples'
draft-ietf-sipcore-rfc4244bis-callflows-06.txt as Informational RFC
The IESG plans to make
The IESG has approved the following document:
- 'LISP MIB'
(draft-ietf-lisp-mib-13.txt) as Experimental RFC
This document is the product of the Locator/ID Separation Protocol
Working Group.
The IESG contact persons are Brian Haberman and Ted Lemon.
A URL of this Internet Draft is:
The IESG has approved the following document:
- 'Concise Binary Object Representation (CBOR)'
(draft-bormann-cbor-09.txt) as Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Barry Leiba.
A URL of this
A new Request for Comments is now available in online RFC libraries.
RFC 7010
Title: IPv6 Site Renumbering Gap Analysis
Author: B. Liu, S. Jiang,
B. Carpenter, S. Venaas,
W. George
Status:
36 matches
Mail list logo
