- Original Message -
From: Lou Berger lber...@labn.net
To: Melinda Shore melinda.sh...@gmail.com
Cc: ietf@ietf.org
Sent: Saturday, April 13, 2013 1:09 PM
Melinda,
I'm not so sure debating the merits of a specific measure has value or
not is really that helpful, and I probably just
- Original Message -
From: l.w...@surrey.ac.uk
To: daedu...@btconnect.com; arturo.ser...@gmail.com; ietf@ietf.org
Sent: Saturday, April 13, 2013 3:46 AM
If you think security and congestion are arcane, you have... problems.
This was an actual ietf working geoup, and not some e.g. W3c
Joel,
Thanks for your review.
Minor issues:
If compliance is a big issue, then this document seems
under-specified. For example, it says in section 5.1 In order to be
compliant with this document, at least the Property Match Filtering
MUST be implemented. However, Property Match
Responding to various people in one e-mail.
To summarise, we have procedures that say what kinds of Discusses are
appropriate, and personal engineering preferences are not. Legitimate issues
should be raised, however, and in the case of most big issues, the right
approach would be to send a
On Apr 15, 2013, at 4:44 AM, t.p. daedu...@btconnect.com wrote:
So perhaps, to reduce the bias, e.g. towards western white, any system
of choosing should give preference to the views of those who do not
attend IETF meetings, for whom judgement is based solely on the
contributions the person in
On Apr 11, 2013, at 10:37 PM, Stefan Santesson ste...@aaa-sec.com wrote:
To put it simply. Given how OCSP is designed, the only way to allow good
to represent a white-list, is if revoked can be returned for everything
else.
I realize it's unfair of me to take this quote out of context.
On Thu, Apr 11, 2013 at 5:27 PM, Fred Baker (fred) f...@cisco.com wrote:
In my opinion, some individual ADs seem to, from their behavior, feel that
they have not done their jobs unless they have raised a discuss. The one
that took the cake for me personally was a discuss raised by a
An extension may differentiate which serial number that results in a
revoked response, that is actually issued and revoked, or if there is
any
other particular reason for responding revoked.
In my universe a syntactically valid serial number can only be good,
revoked
or non-issued. But
[Piyush] From an RP's perspective finding status of serial numbers
serves no purpose unless they can associate that serial number with a
certificate.
Absolutely, that is the client's perspective of this.
Great. We agree
When an OCSP client extracts the serial number from a certificate
Stefan,
I don't think that we have any gaps in the technical understanding of this
proposal. Based on the discussions over the last few months, I can
confidently say that the difference of opinion is around the benefits of
adoptions and the costs associated with it.
Here are the possible goals
On Fri, Apr 12, 2013 at 8:24 PM, Abdussalam Baryun
abdussalambar...@gmail.com wrote:
How can a memebr of staff in a company argue with the manager about the
manager's decisions or performance? Only Owners/shareholders can question
managers and staff. IMO, the meeting/list discussions on
Salvatore
Dear all,
A new version of the Internet Draft on Flow Selection Techniques has
been submitted. It contains the following changes:
-A new section illustrating the difference between Intermediate Flow
Selection Process and Intermediate Selection Process has been added,
-The
Toerless,
A question because my institutional memory does reach as far back:
How much was Europe represented over the decades in IETF leadership ?
Right now for example IESG seems to have maybe at least 5
europeans (don't really know how to figure out location for all of them,
those where
On Apr 12, 2013, at 10:47 PM, Andy Bierman a...@yumaworks.com wrote:
During IESG review, the ADs from other areas should
restrict their comments to issues related to their area.
The final review should avoid changes made
which are feature redesigns or feature enhancements,
and limit changes
On 15/04/2013 15:23, Ted Lemon wrote:
...
So in practice, although I feel great sympathy for this position, I think
it's mistaken. I want the other ADs to comment on anything that they notice
that looks like a problem.
There's an important class of problem that can only be found by
On Apr 15, 2013, at 7:45 AM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
On 15/04/2013 15:23, Ted Lemon wrote:
...
So in practice, although I feel great sympathy for this position, I think
it's mistaken. I want the other ADs to comment on anything that they
notice that looks
On 4/15/2013 7:23 AM, Ted Lemon wrote:
So it's hard to see the harm in [late non-area input by the IESG],
It gives the IESG an exemption to participating in WG and IESG last call
processes, which then frustrates the rest of the community that does not
have this opportunity.
It says that
On Apr 15, 2013, at 11:36 AM, Joe Touch to...@isi.edu wrote:
It gives the IESG an exemption to participating in WG and IESG last call
processes, which then frustrates the rest of the community that does not have
this opportunity.
You could equally say that the IETF last call frustrates the
On 15/04/13 15:45, Brian E Carpenter wrote:
On 15/04/2013 15:23, Ted Lemon wrote:
...
So in practice, although I feel great sympathy for this position, I think it's
mistaken. I want the other ADs to comment on anything that they notice that
looks like a problem.
There's an important class
Ted == Ted Lemon ted.le...@nominum.com writes:
Ted You could equally say that the IETF last call frustrates the WG
Ted process, since a document can fail IETF last call, and this can
Ted be extremely frustrating for working groups. Witness the
Ted fiasco in the MIF working
On Apr 15, 2013, at 9:09 AM, Ted Lemon ted.le...@nominum.com wrote:
On Apr 15, 2013, at 11:36 AM, Joe Touch to...@isi.edu wrote:
It gives the IESG an exemption to participating in WG and IESG last call
processes, which then frustrates the rest of the community that does not
have this
On Apr 15, 2013, at 12:23 PM, Michael Richardson mcr+i...@sandelman.ca wrote:
Maybe we should have an IETF first call (for objections), rather than
last call.
I think that would look a lot like a DoS attack on the IETF, but it would be
nice if there were a way to make it work.
On 04/15/2013 05:26 PM, Joe Touch wrote:
We can continue to appoint groups with additional rounds of review, but IMO,
they are scoped (and the IESG review guidance appears to back up that point).
I think Joe is correct there. Another data point is that we
asked secdir (who currently have an
On Apr 15, 2013, at 6:50 AM, Ted Lemon ted.le...@nominum.com wrote:
On Apr 15, 2013, at 4:44 AM, t.p. daedu...@btconnect.com wrote:
So perhaps, to reduce the bias, e.g. towards western white, any system
of choosing should give preference to the views of those who do not
attend IETF meetings,
On Fri, April 12, 2013 7:22 pm, Melinda Shore wrote:
On 4/12/13 1:26 PM, Lou Berger wrote:
No argument from me, I'm just asking that a comment/position/question
that I don't understand be substantiated.
And I'm telling you that I think the numbers are highly suggestive
of bias.
This is
Melinda,
My own feeling is that if we were to find that the
numbers supported the notion that there's bias
present in the system we probably couldn't do anything
about it without tearing the organization apart, so,
I am actually a little bit more optimistic about it, for a couple of reasons.
On Sat, April 13, 2013 8:18 am, Ray Pelletier wrote:
On Apr 13, 2013, at 8:46 AM, Stephen Farrell stephen.farr...@cs.tcd.ie
wrote:
On 04/13/2013 01:09 PM, Lou Berger wrote:
gender bias
...
western white guys.
It may be that the latter phrase is a common term in
north America, (I
The IESG has received a request from the Keying and Authentication for
Routing Protocols WG (karp) to consider the following document:
- 'Database of Long-Lived Symmetric Cryptographic Keys'
draft-ietf-karp-crypto-key-table-07.txt as Proposed Standard
The IESG plans to make a decision in the
The IESG has approved the following document:
- 'X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol - OCSP'
(draft-ietf-pkix-rfc2560bis-20.txt) as Proposed Standard
This document is the product of the Public-Key Infrastructure (X.509)
Working Group.
The IESG contact
The IESG has approved the following document:
- 'The TLS Multiple Certificate Status Request Extension'
(draft-ietf-tls-multiple-cert-status-extension-08.txt) as Proposed
Standard
This document is the product of the Transport Layer Security Working
Group.
The IESG contact persons are Sean
The IESG has approved the following document:
- 'SAVI Threat Scope'
(draft-ietf-savi-threat-scope-08.txt) as Informational RFC
This document is the product of the Source Address Validation
Improvements Working Group.
The IESG contact persons are Ted Lemon and Brian Haberman.
A URL of this
A new Request for Comments is now available in online RFC libraries.
RFC 6910
Title: Completion of Calls for the
Session Initiation Protocol (SIP)
Author: D. Worley, M. Huelsemann,
R. Jesske, D. Alexeitsev
The IESG has approved the following document:
- 'Using the ECC Brainpool Curves for IKEv2 Key Exchange'
(draft-merkle-ikev2-ke-brainpool-04.txt) as Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Sean
The IESG has completed a review of draft-templin-v6ops-isops-18
consistent with RFC5742.
The IESG has no problem with the publication of 'Operational Guidance for
IPv6 Deployment in IPv4 Sites using ISATAP'
draft-templin-v6ops-isops-18.txt as an Informational RFC.
The document provides
34 matches
Mail list logo
