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 |
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. Examp
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 nev
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
bein
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 bogu
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, registrie
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: draft-ietf-geopr
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 stand
> "Eric" == Eric Rosen 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 that we a
> "Eric" == Eric Rosen 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 propose
> 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,
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 proble
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
http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiSta
Hi -
> From: "Eliot Lear"
> To: "Sam Hartman"
> Cc: ;
> 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 Protocols and Protocol Extensions) to BCP
...
> Also, I
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
Te
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 evid
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, fir
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 z
[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 y
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
On Wed, 27 May 2009, The IESG wrote:
- 'Nominating Committee Process: Earlier Announcement of Open Positions
and Solicitation of Volunteers'
as a BCP
I have two issues with this.
1) This places a new responsibility at the feet of IETF secretariat.
That's a new actor (not even a perso
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:
> d
> "Dan" == Romascanu, Dan (Dan) 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 outcome of the
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 t
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 bri
25 matches
Mail list logo
