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 b
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 sho
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'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comme
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 fail.
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 assistance
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 consciously
On 9/12/13 2:07 PM, "Ted Lemon" wrote:
>On Sep 12, 2013, at 1:49 PM, "Dickson, Brian"
>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 who possesses the root key
On 9/12/13 7:24 AM, "Theodore Ts'o" 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 p
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 fro
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 fr
On Sep 12, 2013, at 7:24 AM, Theodore Ts'o 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 fal
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 fro
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 thi
On 13 sep. 2013, at 19:17, S Moonesamy 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 "Proposed Standard"
>
On Sep 13, 2013, at 2:32 PM, Olaf Kolkman wrote:
>
> On 13 sep. 2013, at 19:17, S Moonesamy 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
On 13 sep. 2013, at 20:03, Carsten Bormann wrote:
> On Sep 13, 2013, at 16:56, Olaf Kolkman 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.
>
On Sep 13, 2013, at 16:56, Olaf Kolkman 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 IETF is not a h
On Sep 13, 2013, at 20:50, Olaf Kolkman 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 2011 document is
--On Friday, September 13, 2013 16:56 +0200 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
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.
26 matches
Mail list logo
