Just to clarify this point.
The text in the introduction where the authors retained change control
was a leftover from the original draft that was intended to go
informational.
We simply forgot to remove this when we changed the scope to
informational.
This is fixed in version 03 of the draft.
This empty appendix was removed in draft 02.
As Russ stated before, an IPR disclosure has been posted to the IETF IPR
page which can be found at:
Stefan Santesson
Program Manager, Standards Liaison
Windows Security
-Original Message-
From: Bill Strahm [mailto:[EMAIL PROTECTED]
Sent: d
Sorry, managed to hit send button to early.
The IPR statement is available at:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=688
Stefan Santesson
Program Manager, Standards Liaison
Windows Security
-Original Message-
From: Stefan Santesson
Sent: den 28 februari 2006 1
Adding to Ari's arguments.
There is one more argument why it would less functional to send the
mapping data in the extension.
The current draft under last call also includes a negotiation mechanism
where the client and server can agree on what type of mapping data they
support.
If the mapping dat
"Stefan Santesson" <[EMAIL PROTECTED]> writes:
> Adding to Ari's arguments.
> There is one more argument why it would less functional to send the
> mapping data in the extension.
>
> The current draft under last call also includes a negotiation mechanism
> where the client and server can agree on w
I can see many situations where the information in this is not
sensitive. In fact, in the primary use case, the use mapping
information is not sensitive. An enterprise PKI is used in this
situation, and the TLS extension is used to map the subject name in
the certificate to the host account n
Russ Housley <[EMAIL PROTECTED]> writes:
> I can see many situations where the information in this is not
> sensitive. In fact, in the primary use case, the use mapping
> information is not sensitive. An enterprise PKI is used in this
> situation, and the TLS extension is used to map the subject
Eric:
> I can see many situations where the information in this is not
> sensitive. In fact, in the primary use case, the use mapping
> information is not sensitive. An enterprise PKI is used in this
> situation, and the TLS extension is used to map the subject name in
> the certificate to the
Eric,
In a general sense, name hints are IDs and IDs are not secrets and no
security system should depend on them being secrets.
However, there might be privacy concerns on where and when you want to
send what ID info to whom. We may e.g. have an issue of aggregate
knowledge. It is always good de
"Stefan Santesson" <[EMAIL PROTECTED]> writes:
> Eric,
>
> In a general sense, name hints are IDs and IDs are not secrets and no
> security system should depend on them being secrets.
>
> However, there might be privacy concerns on where and when you want to
> send what ID info to whom. We may e.g
Folks,
The IETF 65 working group meetings will be streamed and recorded in Dallas
TX begining March 20th at 0900 CST, UTC -6.
Streams will be 64Kb/s or lower httpd streamed mp3 audio, a format
playable by some client of virtually any platform capable of supporting
internet raid type applicat
In message <[EMAIL PROTECTED]>, Joel Jaeggli w
rites:
>Folks,
>
>The IETF 65 working group meetings will be streamed and recorded in Dallas
>TX begining March 20th at 0900 CST, UTC -6.
>
>Streams will be 64Kb/s or lower httpd streamed mp3 audio, a format
>playable by some client of virtually any
Russ Housley wrote:
We all know that there is not going to be a single name form that is
useful in all situations. We also know that you cannot put every useful
name form into the certificate. In fact, the appropriate value can
change within the normal lifetime of a certificate, so putting
Title: HOAKEY BoF in Dallas
Hi folks,
This an announcement for the HOAKEY BoF in IETF Dallas.
The BOF is now a combination of the initial HOAKEY and Pre-Authentication BoFs, The teams are asked to hold a joint BoF as there are some perceived overlaps. So it is a 2.5 hour BoF, where each te
Hi -
If the document gives a false impression that the values of
traceRouteHopsHopIndex could be interpreted as hop numbers,
an editorial change to dispel that notion would make sense.
(Likewise, if "consecutive integers starting at one" was the intent, and
is what current implementations actually
http://english.people.com.cn/200602/28/eng20060228_246712.html
http://www.interfax.cn/showfeature.asp?aid=10411&slug=INTERNET-POLICY-MII-DOMAIN%20NAME-DNS
http://www.domainesinfo.fr/vie_extensions.php?vde_id=859
http://politics.slashdot.org/politics/06/02/28/1610242.shtml
Please look at the pre
Information on the other part of the HOAKEY BOF, PREAUTH, is given
below.
PREAUTH chairs:
Yoshihiro Ohba ([EMAIL PROTECTED])
Alper yegin ([EMAIL PROTECTED])
PREAUTH charter:
http://www.opendiameter.org/pipermail/preauth/2006-February/57.html
PREAUTH Mailing list:
http://www.opendiameter.o
I think we relax, go to the bar and have a drink.
These questions will sort themselves out. There is no conflict or
ambiguity unless ICANN decides to issue the same TLDs.
MIT could decide to add an j key to their telephones and issue people
complex numbers for use in internal calls. This would ca
At 04:49 01/03/2006, Hallam-Baker, Phillip wrote:
These questions will sort themselves out. There is no conflict or
ambiguity unless ICANN decides to issue the same TLDs.
Dear Phillip,
Full agreement. Let not confuse alt-roots and open-roots. The Chinese
TLDs are in the top zone for nearly 2 y
19 matches
Mail list logo
