Hi Bernard,
Reliance on discovery implies that there is no prior relationship, but the
document does not go so far as to explicitly make this statement. Since this
is so fundamental, a mention couldn’t hurt (to Section 3 perhaps).
This protocol does not assume any prior relationship b
Spencer Dawkins wrote:
(Nominees should not solicit support, and other IETF community
members should not post statements of support/non-support for
nominees) in any public forum.
I think you mean the latter.
I do, too.
A comma before "in" would probably do the job.
--
Doug Ewell * Thorn
David Wilson wrote:
>>The provision is through hops of certificate authorities,
> As I clearly stated,
As we are discussing on concepts described in two papers, your
own statement without proper quotation from the papers does
not mean anything.
> the actual signing is end to end,
The security
David Wilson wrote:
>>As has been discussed in the thread, DNSSEC is NOT a protection
>>against cache poisoning, because caches poisoned with forged
>>certificate breaks the security.
> I think you need to explain how this happens in detail.
In detail??? See below.
> With DNSSEC, a security awa
Hi Jari,
Ya know, I was looking at that text thinking the same thing...
I had an orthogonal question.
Should I read
Nominees should not solicit support, and other IETF community members
should not post statements of support/non-support for nominees in any
public forum.
as
(Nominees shou
I had an orthogonal question.
Should I read
Nominees should not solicit support, and other IETF community members
should not post statements of support/non-support for nominees in any
public forum.
as
(Nominees should not solicit support), and (other IETF community members
should not post
While philosophically I agree with Brian, practically I have to disagree.
My reasoning is that while we don't want that sort of thing to happen,
the only enforcement mechanism is what the nomcom chooses to do. And
while I would hope that they would consider such misbehavior a negative,
I don't
Brian Carpenter had a Last Call comment that I needed to follow up on...
Hi,
(IETF list not copied as I'm on leave and minimising email, but
there is nothing confidential about this comment.)
Feedback on nominees should always be provided privately to
NomCom. Nominees should not
On Jun 8, 2009, at 4:21 PM, Mary Barnes wrote:
I guess I'm still missing your original concern. But, one problem with
that sentence is that it's really out of context and would make more
sense if it were the first sentence in the last paragraph in section
8,
as that then leads to the text on
Hi Mary,
Responses inline. I've edited out sections that I think we have
closure on.
On Jun 8, 2009, at 1:55 PM, Mary Barnes wrote:
[...]
-- Section 6.2, value list:
-- In my previous review, I was confused as to the relationship
between
the geodetic/civic and LoBV/LoBR choices. I thi
On Jun 9, 2009, at 05:28, Dave Cridland wrote:
To be fair:
a) This one is *just* a poorly written draft [...].
...as an individual contribution,
...in the Informational category.
b) Apple are, at least, producing a public specification in a
reasonable forum for discussion.
Moreover, Mr.
On Jun 8, 2009, at 11:58 PM, Thomson, Martin wrote:
[1] The document is clear on its use of digest/basic: the LIS MUST
NOT rely on it being used. That’s in recognition of the above
constraint. In other words, the LIS MUST NOT fail a request because
the device did not provide authenticat
Martin Thomson said:
"Regarding client authentication, there are a number of
constraints on the solution that lead to the current choice. The most relevant
constraint is that there may be no prior relationship between LIS (network
operator) and device. In designing for arbitrary access networks
Support
> -Original Message-
> From: ietf-announce-boun...@ietf.org
> [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG
> Sent: Tuesday, June 02, 2009 10:01 PM
> To: IETF-Announce
> Cc: p...@ietf.org
> Subject: Last Call: draft-ietf-pwe3-ms-pw-arch (An
> Architecture for Mult
Masataka-san
Please learn to express your opinions in a manner that is appropriate
to a professional forum rather than a bar room brawl.
You are entitled to your opinion but not to converse in the abusive
and insulting manner you have chosen to use if you wish to receive a
reply.
The link you ga
On 2009-Jun-9, at 11:25 AM, Sean Turner wrote:
Other ECC documents in the IETF (TLS, SMIME, PKIX) indicate that
support for compressed keys are MAY while this draft says MUST NOT
for ECDSA and ECDH keys and MAY for ECMQV. What was the rationale
for this?
Simplicity. In my opinion, compr
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote:
> > This origin authentication and integrity is precisely what is
> required
> > to avoid the DNS cache poisoning which is the kind of vulnerability
> > which prompted this discussion.
>
> As has been discussed in the thread, DNSSEC is NOT a
On Tue, 2009-06-09 at 08:54 +0900, Masataka Ohta wrote:
> > DNSSEC provides two things. Firstly, it provides the means to
> digitally
> > sign RRsets. This provides data origin authentication and data
> > integrity.
>
> The provision is through hops of certificate authorities,
As I clearly stated
Doug,
Thanks for the quick reply.
Douglas Stebila wrote:
On 2009-Jun-9, at 11:25 AM, Sean Turner wrote:
Other ECC documents in the IETF (TLS, SMIME, PKIX) indicate that
support for compressed keys are MAY while this draft says MUST NOT for
ECDSA and ECDH keys and MAY for ECMQV. What was the
Hi,
[ASRG removed, since I cannot see even a little bit how this is
on-topic there. But if you think it is, feel free to republish this
as you like.]
On Tue, Jun 09, 2009 at 08:54:48AM +0900, Masataka Ohta wrote:
> As has been discussed in the thread, DNSSEC is NOT a protection
> against cache
On Tue Jun 9 12:57:45 2009, Roy T. Fielding wrote:
I don't like it when the IETF is abused
for marketing purposes.
To be fair:
a) This one is *just* a poorly written draft, rather than also being
filled with Apple product name-dropping, and gushing remarks about
The Jobs.
b) Apple are
On Jun 9, 2009, at 4:45 AM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : HTTP Live Streaming
Author(s) : R. Pantos
Filename: draft-pantos-http-live-streaming-01.txt
22 matches
Mail list logo
