On 4 Jun 2009, at 04:06, Mark Andrews wrote:
In message aaab52ef-ad0a-4d3c-9b28-b864f342d...@sabahattin-gucukoglu.com
, Sabahattin Gucukoglu writes:
The problem is this: the authoritative servers for a domain can
easily
never be consulted for DNS data if the resource being looked up
happens
Sam,
Thanks for posting your review. It caused me to have a look at the
document, because I've been considering writing something of a missive
on my own. I have to say that I enjoyed reading this draft up to about
Section 3, and then I came to some problems. I'll spell those out in a
At 12:22 03-06-2009, Sam Hartman wrote:
I appreciate the work that has gone into this document. People have
worked hard to find examples, cases and even pithy
sayings/architectural principles from many areas of the IETF. The
document tries to be broad and to look at a lot of options. I think
Hello,
Section 7.1 of draft-ietf-enum-3761bis-04 is about DNS Security. One
sentence caught my attention:
Because of these threats, a deployed ENUM service SHOULD include
mechanisms to ameliorate these threats.
My reading of that is that a deployed ENUM service should include
Sam,
Thank you for your review and opinions.
I would like to remind you and let many people that are not aware about
the history of the document know one fact that may be important. This
document is an outcome of the discussions hold at the IESG retreat in
May 2006. I was then the 'fresh' AD
In the discussion of IETF consensus of this document and its position as a
BCP or otherwise, can I throw into the melting pot
draft-ietf-pce-manageability-requirements-06.txt
This particular I-D was developed within the PCE working group to apply only
in that working group. It covers similar
Dan == Romascanu, Dan (Dan) droma...@avaya.com writes:
Dan Sam, Thank you for your review and opinions.
Dan I would like to remind you and let many people that are not
Dan aware about the history of the document know one fact that
Dan may be important. This document is an
Hi Sam,
A clarification and a clarification question in-line.
Dan
-Original Message-
From: Sam Hartman [mailto:hartmans-i...@mit.edu]
Sent: Thursday, June 04, 2009 2:23 PM
To: Romascanu, Dan (Dan)
Cc: Sam Hartman; ietf@ietf.org; ops...@ietf.org
Subject: Re: Last Call:
On Wed, 27 May 2009, The IESG wrote:
- 'Nominating Committee Process: Earlier Announcement of Open Positions
and Solicitation of Volunteers'
draft-dawkins-nomcom-dont-wait-03.txt as a BCP
I have two issues with this.
1) This places a new responsibility at the feet of IETF secretariat.
Sabahattin Gucukoglu wrote:
Glue data, additional and non-authoritative by design, intent and
specification, aren't what I want caches to keep.
You had better cache glue As, as long as they are tagged as glue
As with a domain name of query.
Then, the cached information may be used as glue
[this one more publicly]
Dan,
Based on the goals you set out below, I would argue that the document is
too long. I would recommend sticking with principles and calling out a
few examples. I think this is done reasonably well in Section 2, and
less so elsewhere. I would also suggest that
On Wed, Jun 03, 2009 at 03:27:42PM +0900, Masataka Ohta wrote:
Though we have to trust the zone administration put correct referral
and glue data in a master zone file, unless we use DNSSEC, we don't
have to trust the zone administration never issue certificates over
forged keys of child
Thanks for review ... just wanted to respond to one point in this.
On Jun 3, 2009, at 4:47 PM, Spencer Dawkins wrote:
C5. User Identity Protection: The location URI MUST NOT contain
information that identifies the user or device. Examples include
phone extensions, badge numbers,
Adopting this document as a BCP would be a serious mistake, and I hope it
will be strongly opposed.
There is absolutely no evidence that following the dictates of this document
will improve the quality of the IETF's work, and we certainly know it won't
improve the timeliness. There is no
So, there is no point to deploy DNSSEC.
no ?
http://jprs.co.jp/en/topics/081125.html
regards
Marc
--
Les enfants teribbles - research / deployment
Marc Manthey
Vogelsangerstrasse 97
D - 50823 Köln - Germany
Vogelsangerstrasse 97
Geo: 50.945554, 6.920293
PGP/GnuPG: 0x1ac02f3296b12b4d
Hi -
From: Eliot Lear l...@cisco.com
To: Sam Hartman hartmans-i...@mit.edu
Cc: ops...@ietf.org; ietf@ietf.org
Sent: Wednesday, June 03, 2009 11:15 PM
Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management
(Guidelines for Considering Operations and Management
of New
This is an open call for participation in the new ³homegate² mailing list,
which is dedicated to discussing issues relating to broadband home gateway
devices. There has been a BoF request submitted relating to this, which you
can find at
Joel M. Halpern wrote:
To put it differently, the OPS area has as much right to propose their
requirements as any other area (Transport Congestion, Security, ...)
has. And generally, the community has listened to such requests and
gone along with them.
Yes, we have produced a bit of a
This does not mean we have to simply accept what they (OPS) say. But it
does mean we should give it a fair review, looking at the details,
rather than objecting on principle.
This is absolute nonsense. Most of the people actually doing work in the
various areas do not have the time,
Eric == Eric Rosen ero...@cisco.com writes:
Eric If we are going to talk about adding new hoops for folks to
Eric jump through, we should first discuss whether any such hoops
Eric are necessary. We should not start the discussion by
Eric looking at the details of the particular
Eric == Eric Rosen ero...@cisco.com writes:
Eric I don't see that OPSAWG has any business imposing
Eric requirements on work done by other WGs in other Areas.
Obviously I agree with this statement. However I do believe that the
ops area can propose and build consensus on requirements
To put it differently, the OPS area has as much right to propose their
requirements as any other area (Transport Congestion, Security, ...)
has. And generally, the community has listened to such requests and
gone along with them.
Yes, we have produced a bit of a problem that our initial
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
Marc Manthey wrote:
So, there is no point to deploy DNSSEC.
no ?
No, no point.
http://jprs.co.jp/en/topics/081125.html
FYI, JPRS, which is a commercial entity to administrate JP domain,
is commercially motivated not to admit it merely an untrustworthy
third party.
In general, registries
Andrew Sullivan wrote:
Though we have to trust the zone administration put correct referral
and glue data in a master zone file, unless we use DNSSEC, we don't
have to trust the zone administration never issue certificates over
forged keys of child zones.
If an attacker can get its bogus data
On Jun 3, 2009, at 8:35 PM, Masataka Ohta wrote:
The problem is that the accuracy and integrity of DNSSEC is not
cryptographically, but socially secure.
DNS over UDP is prone to port/transaction-id guessing, where
cryptography could play a protective role. The risk of these values
In message 4a285750.9010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Andrew Sullivan wrote:
Though we have to trust the zone administration put correct referral
and glue data in a master zone file, unless we use DNSSEC, we don't
have to trust the zone administration never issue
On Jun 4, 2009, at 9:24 AM, Cullen Jennings wrote:
Thanks for review ... just wanted to respond to one point in this.
On Jun 3, 2009, at 4:47 PM, Spencer Dawkins wrote:
C5. User Identity Protection: The location URI MUST NOT contain
information that identifies the user or device.
Total of 110 messages in the last 7 days.
script run at: Fri Jun 5 00:53:02 EDT 2009
Messages | Bytes| Who
+--++--+
13.64% | 15 | 10.40% |73803 | mo...@necom830.hpcl.titech.ac.jp
7.27% |8 | 6.18% |43869 |
The IESG has received a request from the Congestion and Pre-Congestion
Notification WG (pcn) to consider the following document:
- 'Metering and marking behaviour of PCN-nodes '
draft-ietf-pcn-marking-behaviour-03.txt as a Proposed Standard
The IESG plans to make a decision in the next few
The IESG has received a request from the TCP Maintenance and Minor
Extensions WG (tcpm) to consider the following document:
- 'TCP Congestion Control '
draft-ietf-tcpm-rfc2581bis-05.txt as a Draft Standard
The implementation report supporting the advancement to Draft Standard
is at:
31 matches
Mail list logo
