Stefan Santesson wrote:
> "Martin Rex" wrote:
>
> >Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
> >single_requests_only(8), unsupported_extension(8) } with well-defined and
> >conflict-free semantics to the existing enum would be perfectly backwards
> >compatible.
>
>
On 3/25/13 10:21 PM, Stefan Santesson wrote:
Hi David,
Nits:
idnits 2.12.15 said:
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If
you
have contacted all the original authors and they are
Ted,
> Remembering that this is an informational draft, which does a pretty good job
> of informing the reader about the problem space, is it your opinion that the
> issues you have raised _must_ be addressed before the document is published,
> or do you think the document is still valuable even i
Hi Stefan,
This looks good - thank you for the prompt response.
It looks like my speculation on item [1] was wrong, so could you respond
to the question below, please?:
> >[1] Section 2.2:
> >
> > NOTE: The "revoked" state for known non-issued certificate serial
> > numbers is al
I think I can add text to address this. I will look more closely tomorrow, and
send you a proposal.
Thank you for all your efforts reviewing this.
Yours,
Joel
Sent from my Android phone using TouchDown (www.nitrodesk.com)
-Original Message-
From: Black, David [david.bl...@emc.com]
Recei
Hi David,
Yes I missed to respond to that aspect.
This is a bit complicated, but we have a large legacy to take into account
where some responders implements just RFC 2560, while some deliver
pre-generated responses according to RFC 5019 (Light-weight OCSP). LW
responders are not capable of produ
Hi Stefan,
> Does this answer your question?
Yes, please add some of that explanation to the next version of the draft ;-).
Coverage of existing responder behavior/limitations (important "running code"
concerns, IMHO) and alternatives to using "revoked" ("have a number of tools
to prevent the cli
It is risky to assume that existing clients would work appropriately if
you send them a new never seen before error code.
I'm not willing to assume that unless a big pile of current implementers
assures me that this is the case.
/Stefan
On 3/27/13 3:14 PM, "Martin Rex" wrote:
>Stefan Santesson
Stefan Santesson wrote:
>
> It is risky to assume that existing clients would work appropriately
> if you send them a new never seen before error code.
>
> I'm not willing to assume that unless a big pile of current implementers
> assures me that this is the case.
As I wrote: As long as the spec
Would it suffice to replace
Old:
If the bridging topologies which connects the switches changes, or
if LACP [IEEE802.3ad] changes which links are used to deliver
traffic, the switch may need to move the SAVI state to a different
port, are the state may need to be moved or reestablished
Then it will be done. I will wait for the AD to decide what other
changes are needed, and then will either make this change or include it
in an RFC Editor note.
Thank you,
Joel
On 3/27/2013 12:42 PM, Black, David wrote:
That would do nicely.
Thanks,
--David
-Original Message-
Fro
All -
draft-sparks-genarea-imaparch has been revised to address comments from
Pete Resnick and Barry Leiba. Jari Arkko has suggested that the security
considerations
section contain something like what RFC6778 contained about potential
risks to CPU
and I/O utilization. I plan to make that chan
Sam Hartman wrote:
> Martin Rex wrote:
>> Oh, here is a message from the Security AD back then (Sam
>> Hartman), commenting on requirements for rfc2560bis (the I-D
>> under last call right now!):
>>
>> http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
>
> To be clear, I didn't com
Russ, Jari, IAB,
Recently, there has been a lot of discussion in the IETF about diversity.
A lot of people observed that the IETF is not good in fostering a culture
that naturally promotes diversity and that is attractive for younger people
to join. One way to make the IETF more accessible and a
On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct
wrote:
> Then it will be done. I will wait for the AD to decide what other changes
> are needed, and then will either make this change or include it in an RFC
> Editor note.
> Old:
> If the bridging topologies which connects the switches ch
15 matches
Mail list logo
