Is it really so completely out of this world to expect the decency
to ask whether it is OK to take a photo for the purpose of _publication_?
Leaving it up to the individual subjects whether they prefer to
relocate further to the background first or prefer to temporarily
leave the room? Especially
Dear IAOC,
I suggest that your standard dealings with local hosts should
include requiring them to perform a local check on whether the
standard "Note Well" takes account of all local legal requirements,
including for example consent to publication of images. If it doesn't,
the host should provide
Brian,
> I suggest that your standard dealings with local hosts should include
> requiring them to perform a local check on
> whether the standard "Note Well" takes account of all local legal
> requirements, including for example
> consent to publication of images. If it doesn't, the host shoul
Hi Linda,
> Respect your advice. However, some wording in the proposed charter are too
> ambiguous, is it the intent?
>
> For example:
>
> "An NVO3 solution (known here as a Data Center Virtual Private Network
> (DCVPN)) is a VPN that is viable across a scaling range of a few thousand VMs
to
>
Hi Stewart,
> >> The NVO3 WG will write the following informational RFCs, which
> >> must be substantially complete before rechartering can be
> >> considered:
> >
> > "substantially complete" is sufficiently subjective to risk a riot at some
point
> > in the future!
> > Can we be more precise wit
Hi,
> > NVO3 will document the problem statement, the applicability, and an
> > architectural framework for DCVPNs within a data center
> > environment. Within this framework, functional blocks will be defined to
> > allow the dynamic attachment / detachment of VMs to their DCVPN,
> > and the inte
Christian,
On 2012-04-25 08:57, Christian Huitema wrote:
> Brian,
>
>> I suggest that your standard dealings with local hosts should include
>> requiring them to perform a local check on
>> whether the standard "Note Well" takes account of all local legal
>> requirements, including for example
Dear Brian;
On Wed, Apr 25, 2012 at 3:42 AM, Brian E Carpenter
wrote:
> Dear IAOC,
>
> I suggest that your standard dealings with local hosts should
> include requiring them to perform a local check on whether the
> standard "Note Well" takes account of all local legal requirements,
> including
+1
The name should reflect the final product, not the path taken to get there.
If people were to use these records then they would see them in the
DNS zone and see them listed as TLSA and look for an RFC with that
name. Only the people who were involved in the group would know that
DANE and TLSA
I have raised these comments in the WG numerous times, I am raising
them here as I do not believe that anyone is going to implement the
specification as currently described.
As currently written, the specification attempts to mandate client
behavior when DANE records are encountered in ways that a
A question in line.
On Wed, Apr 25, 2012 at 6:01 AM, Adrian Farrel wrote:
> Hi Linda,
>
>> Respect your advice. However, some wording in the proposed charter are too
>> ambiguous, is it the intent?
>>
>> For example:
>>
>> "An NVO3 solution (known here as a Data Center Virtual Private Network
>
Thanks, Joe. Looks like we've reached agreement on most things.
There are a few items left where Sam's input is needed.
I'll wait to see what he has to say.
Thanks,
Steve
> -Original Message-
> From: Joe Salowey [mailto:jsalo...@cisco.com]
> Sent: Wednesday, April 25, 2012 1:34 AM
> To:
I see no value in deallocating code point spaces and a huge amount of
potential harm.
Except at the very lowest levels of the protocol stack (IP and BGP)
there is really no technical need for a namespace that is limited. We
do have some protocols that will come to a crisis some day but there
are p
On 25/04/2012 14:57, Marshall Eubanks wrote:
A question in line.
On Wed, Apr 25, 2012 at 6:01 AM, Adrian Farrel wrote:
Hi Linda,
Respect your advice. However, some wording in the proposed charter are too
ambiguous, is it the intent?
For example:
"An NVO3 solution (known here as a Data C
On Tue, 24 Apr 2012, David Morris wrote:
The IETF meetings are actually not totally public. You must purchase a
'ticket' to attend. We would not allow someone to walk in off the street
and photograph the functions, or even sit in a meeting and take notes.
Without commenting specifically about
On Wed, Apr 25, 2012 at 09:52:39AM -0400, Phillip Hallam-Baker wrote:
> dependency on the DNSSEC trust chain despite the easily observed fact
> that less than 97% of DNS resolvers will pass anything other than
> A/ and CNAME records.
I'm having a hard time understanding that sentence. Could
On Apr 25, 2012, at 7:27 AM, Phillip Hallam-Baker wrote:
> Except at the very lowest levels of the protocol stack (IP and BGP)
> there is really no technical need for a namespace that is limited.
Arguable, but irrelevant since the reality is that historically many (most?)
protocols defined by the
Dear all,
I have made a couple more clarifications to the text below based on additional
feedback from Daniel on the use of the active PW selection algorithm in use
cases presented in Section 15.
I am copying the new updated Section 5.1. All the changes from the current
version of the draft are
Dear SM,
Thank you for the review.
Please see inline.
Cheers,
Med
>-Message d'origine-
>De : mboned-boun...@ietf.org [mailto:mboned-boun...@ietf.org]
>De la part de SM
>Envoyé : dimanche 22 avril 2012 01:26
>À : ietf@ietf.org
>Cc : mbo...@ietf.org
>Objet : Re: [MBONED] Last Call:
>
On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote:
The browser providers do not hard fail on OCSP because doing so would
require them to wait for the OCSP response within the TLS handshake
and this is considered an unacceptable performance degradation.
And with the current ocsp.entrust.net issue
> I see no value in deallocating code point spaces and a huge amount of
> potential harm.
It depends on the size of the space. I completely agree that if the space is
large - and that's almost always the case - then deallocating is going to be
somewhere between silly and very damaging.
Deprecacti
Hi Med,
At 08:05 25-04-2012, mohamed.boucad...@orange.com wrote:
Med: Do you mean, cite RFC4291 in addition to the ref to Appendix A.2?
Yes, and have Appendix A.2 as informative.
Med: Yes, because as listed in Appendix A.2, we wanted to have an a
prefix in the ff3x::/32 range.
You are using
+1
Deprecating a code point is very different from deallocating it which
implies that it is going to be given out again in the future. Last
thing I want is a used code point.
I agree that avoiding multiple allocations is also a function of IANA,
but this is also something that argues for not bein
Not arguable in the fashion that you do. You seem to want to signal
disagreement without needing to actually argue a contrary case.
Cutting pieces out of someone's argument to make it look stupid is
itself a stupid trick.
On Wed, Apr 25, 2012 at 12:55 PM, David Conrad wrote:
> On Apr 25, 2012,
Some additional modest last call comments on draft-ietf-dane-protocol-19...
terminological issues
-
The "usage" notion has at least five term/phrase variations used in the spec. I
found this quite confusing. Here's the variations I find..
usage = usage type = certificate u
On Wed, Apr 25, 2012 at 11:15 AM, Andrew Sullivan
wrote:
> On Wed, Apr 25, 2012 at 09:52:39AM -0400, Phillip Hallam-Baker wrote:
>
>> dependency on the DNSSEC trust chain despite the easily observed fact
>> that less than 97% of DNS resolvers will pass anything other than
>> A/ and CNAME recor
On Wed, Apr 25, 2012 at 11:47 AM, Paul Wouters wrote:
> On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote:
>> Rather than mandating hardfail or any particular client behavior, the
>> specification should simply state that the client MUST conclude that
>> the DANE status of the certificate is inval
This version of the NVO3 charter reflects the discussions
on the list and comments received as of this afternoon.
I propose to take this to the IESG for their second
review tomorrow.
Stewart
==
NVO3: Network Virtualization Over Layer 3
Chairs - TBD
Area - Routing
Area Director - Stewart B
I would strongly support what Wes is talking about here. I see two (other)
reasons for keeping blue sheets. The first is it is a recognized method of
showing we have an open standards process. The second is to support those who
are trying to defend themselves in patent suits. Frankly, I hope
Hi Eric,
At 15:06 25-04-2012, Eric Burger wrote:
For the former purpose, just having a list is sufficient. However,
for the latter purpose, one needs records that would be admissible
in court. Without eating our dog food and having some sort of
audited digital signature technology, a simple sca
Does deleting "IETF" in the following
sentence:
"Any documented solutions
will use existing IETF protocols if suitable."
satisfy your concerns?
- Stewart
Those were my thoughts when the text was written.
Stewart
On 26/04/2012 00:57, david.bl...@emc.com wrote:
Joe and Pat,
I'm less concerned about this - I think the words "if suitable" regarding
use of existing IETF protocols are sufficient to support choosing the best
solution whether it comes
Ned,
On Apr 25, 2012, at 10:46 AM, Ned Freed wrote:
>> I see no value in deallocating code point spaces and a huge amount of
>> potential harm.
> It depends on the size of the space.
Why? We're talking about completed "experiments". I'm unclear I see any
particular value in having IANA staff c
> Ned,
> On Apr 25, 2012, at 10:46 AM, Ned Freed wrote:
> >> I see no value in deallocating code point spaces and a huge amount of
> >> potential harm.
> > It depends on the size of the space.
> Why?
Because if you deallocate and reallocate it, there can be conflicts. Perhaps
you haven't notic
Ned,
On Apr 25, 2012, at 7:31 PM, Ned Freed wrote:
I see no value in deallocating code point spaces
>>> It depends on the size of the space.
>> Why?
> Because if you deallocate and reallocate it, there can be conflicts. Perhaps
> you haven't noticed, but a lot of times people continue to us
35 matches
Mail list logo
