Changing our reference to RFC 5209 to be normative may cause
more problems than it solves. As RFC 3967 (BCP 97) says,
IETF procedures generally require that a standards track RFC
may not have a normative reference to another standards track
document at a lower maturity level or to a non
Dean Willis wrote:
Having a car won't do any good. There is, as far as I can tell, no
place to park it but the hotel valet.
According to this web page, complimentary self-parking is available
at the Caribe Royale.
http://www.cariberoyale.com/accommodations/services/
Thanks,
Steve
I also, with regret, would like to add my name to the recall
petition. I am NomCom eligible.
Thanks,
Steve
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
Message-
From: Stephen Hanna
Sent: Tuesday, May 22, 2012 4:00 PM
To: 'Sam Hartman'
Cc: e...@ietf.org; sec...@ietf.org; ietf@ietf.org
Subject: RE: Updated secdir review of draft-ietf-emu-chbind-15.txt
Sam,
I see now that you are concerned not with circumstances where
the NAS terminates
describing the attack scenario and countermeasures.
Thanks,
Steve
-Original Message-
From: Sam Hartman [mailto:hartmans-i...@mit.edu]
Sent: Monday, May 21, 2012 5:51 PM
To: Stephen Hanna
Cc: Sam Hartman; e...@ietf.org; sec...@ietf.org; ietf@ietf.org
Subject: Re: Updated secdir review
The changes in draft-ietf-emu-chbind-15.txt satisfactorily address
almost all of the comments in my April 13, 2012 secdir review. I do
have one remaining substantive comment on this latest draft and two
non-substantive ones.
Substantive Comment
---
The last paragraph of section
To: Stephen Hanna
Cc: draft-ietf-emu-chb...@tools.ietf.org; sec...@ietf.org; IETF-
Discussion list; Sam Hartman
Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14
Importance: High
On Apr 24, 2012, at 2:05 PM, Stephen Hanna wrote:
Joe,
I'm glad that my comments were useful to you
that the response did not come from the requested URL.
Thanks,
Steve
-Original Message-
From: Mark Nottingham [mailto:m...@mnot.net]
Sent: Sunday, January 29, 2012 6:50 PM
To: Stephen Hanna
Cc: Julian Reschke; draft-nottingham-http-new-sta...@tools.ietf.org;
sec...@ietf.org; ietf
Yes
-Steve
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Monday, January 30, 2012 10:10 AM
To: Stephen Hanna
Cc: Mark Nottingham; draft-nottingham-http-new-sta...@tools.ietf.org;
sec...@ietf.org; ietf@ietf.org
Subject: Re: secdir review of draft
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
: Friday, January 13, 2012 3:27 PM
To: Stephen Hanna
Cc: draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org;
ietf@ietf.org
Subject: Re: secdir review of draft-nottingham-http-new-status-03
On 2012-01-13 20:59, Stephen Hanna wrote:
I have reviewed this document as part
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
considerations. Then you could list
those explicitly in the last paragraph of the Security Considerations.
Thanks,
steve
-Original Message-
From: carlb...@g11.org.uk [mailto:carlb...@g11.org.uk]
Sent: Tuesday, July 26, 2011 6:42 AM
To: Stephen Hanna
Cc: ietf@ietf.org; sec...@ietf.org; draft
: Tuesday, July 26, 2011 7:24 AM
To: Stephen Hanna
Cc: ietf@ietf.org; sec...@ietf.org; draft-ietf-dime-priority-
avps@tools.ietf.org; lionel.mor...@orange-ftgroup.com
Subject: RE: secdir review of draft-ietf-dime-priority-avps-04
Steve,
Quoting Stephen Hanna sha...@juniper.net
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments
that
might not be evident to someone who is not a security expert.
Thanks,
Steve
-Original Message-
From: Tom.Petch [mailto:sisyp...@dial.pipex.com]
Sent: Thursday, August 13, 2009 4:00 AM
To: Stephen Hanna; sec...@ietf.org; ietf@ietf.org;
draft-ietf-netconf-partial-l...@tools.ietf.org
operation on the server.
Are there any concerns with this proposal?
If so, please explain.
Thanks,
Steve
-Original Message-
From: Bert (IETF) Wijnen [mailto:berti...@bwijnen.net]
Sent: Thursday, August 13, 2009 7:35 AM
To: Stephen Hanna
Cc: Tom.Petch; sec...@ietf.org; ietf@ietf.org
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors should treat these comments just like any
other comments.
This document defines conventions for well-known Kerberos principal
names and
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
Ted Hardie wrote:
For the charter discussions, I want to know whether it will
be an aim of the working group to standardize:
* a way of carrying this information
* the structure of this information (but not its content)
* a standard representation of the content, so that access to the
vendor
Sam Hartman wrote:
One of the things coming out of the most recent BOF was a
strong desire for PA-level interoperability. That can be
accomplished through standardized attributes or
vendor-specific attributes that are sufficiently well
documented (and not subject to patents) that third
Vidya Narayanan wrote:
I am very apprehensive of achieving any meaningful PA-level
interoperability. I am not sure what minimum set of PA attributes will
be standardized, but, whatever that set is, I doubt will be sufficient
to provide any acceptable level of security, even for the endpoints.
Ted,
As I understand your concerns expressed below, you are concerned
that standardizing attributes for NEA would be redundant and
pointless: redundant because vendor-specific attributes will
cover the same information in more detail and pointless because
remediation will not be possible given
Vidya,
Thanks for your response. I think we may be getting closer to
understanding each other's perspectives. That's a good thing.
Let me respond to your comments inline below. I hope you won't
mind if I clip a bit since this thread is starting to get long.
Vidya Narayanan wrote:
A. Any
I have seen a lot of discussion about whether NEA provides
network protection. In fact, it has been suggested that
the charter be revised to say NEA must not be considered
a protection mechanism for networks. I don't agree.
Let's start by examining this concept of network protection.
It's an
34 matches
Mail list logo
