Tony,
[top-posting since that's what you did]
AIUI, the intention is not for the RIRs to be controlling the market,
but rather to provide the same value they do now: a location where I can
see who is responsible for a given address.
I think the RIRs all have a transfer policy now. So when a
Shane,
It's been clear to me for a while that the RIRs have conflicting goals,
and they interpret that conflict in differing ways, based on their
respective memberships' input. Just in case others are interested (I'm
fairly certain that Shane and Tony already know), there is a mailing
list for
psuger wrote:
Dear colleagues,
I am a member of a lead user project planning to run real live RFID
use tests. This test intends to use the [RFC 5395] Private Use 0xFFF0,
65520 Class as PERFID (for Provisional Experimentation RFID) since
there is no Experimentation Classes assigned.
Mssr
Spencer,
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
Simon Josefsson wrote:
One attack could works like this:
1) Client establish an client-authenticated HTTPS session with a TLS SNI
for blog.example.org and sends a HTTP GET with a Host: header for
internal-website.example.org.
2) The server TLS code authenticate and authorize the client
Martin Rex wrote:
Simon Josefsson wrote:
One attack could works like this:
1) Client establish an client-authenticated HTTPS session with a TLS SNI
for blog.example.org and sends a HTTP GET with a Host: header for
internal-website.example.org.
2) The server TLS code authenticate and authorize
Hi Joe,
Thanks from my side as well. I would just like to add some supplementary
explanation below...
Koodli, Rajeev wrote:
Hi Joe,
Thank you for your review. I am one of the co-authors.
Please some below:
-Original Message-
From: Joe Touch [mailto:to...@isi.edu]
Sent:
Hi, Yakov,
Thanks for the quick response (I can still remember what I was thinking).
Thanks also for the explanation that you're not able to tighten a couple of
SHOULDs to MUSTs because of previous specifications. Makes sense to me
(should be flogging the OTHER document).
I think we're
On Sep 28, 2009, at 8:07 PM, Dave CROCKER wrote:
Folks,
A number of people have indicated that they believe the draft
contract language is standard, and required by the government.
It occurs to me that we should try to obtain copies of the exact
language used for meetings by other
It seems that this is really up to the application. Both server names
are authenticated under the same session. It seems an application
server may require them to be the same or allow them to be different.
-Original Message-
From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org]
On 9/24/09 18:31, Sep 24, Ole Jacobsen wrote:
To repeat: The IAOC does not think we are in any real danger of having our
meeting disrupted or terminated due to actions which would be deemed in
violation of the clause in question. We expect a meeting in China to be just
like any other IETF
Just so some of the gallery is heard from on the list, I am presuming
that they are also counting the input from the survey.
I have no idea how many people responded to that, nor what they said.
I know that I indicated that I thought this was reasonable as long as
certain specific risks had
Adam,
Not quite. I think we have heard the comments of the community loud
and clear and we are working hard to deal with the issues. I also
should state that we have not formally made a decision about this
proposed meeting. The survey is still open, and comments are still
coming in, both on
Joseph Salowey (jsalowey) jsalo...@cisco.com writes:
It seems that this is really up to the application. Both server names
are authenticated under the same session. It seems an application
server may require them to be the same or allow them to be different.
I would agree if the draft
The IESG has received a request from the Internationalized Domain Names
in Applications, Revised WG (idnabis) to consider the following document:
- 'Right-to-left scripts for IDNA '
draft-ietf-idnabis-bidi-06.txt as a Draft Standard
The IESG plans to make a decision in the next few weeks,
The IESG has received a request from the Internationalized Domain Names
in Applications, Revised WG (idnabis) to consider the following document:
- 'Internationalized Domain Names for Applications (IDNA): Definitions
and Document Framework '
draft-ietf-idnabis-defs-11.txt as a Draft
The IESG has received a request from the Internationalized Domain Names
in Applications, Revised WG (idnabis) to consider the following document:
- 'Internationalized Domain Names in Applications (IDNA): Protocol '
draft-ietf-idnabis-protocol-16.txt as a Draft Standard
The IESG plans to make
The IESG has received a request from the Internationalized Domain Names
in Applications, Revised WG (idnabis) to consider the following document:
- 'Internationalized Domain Names for Applications (IDNA): Background,
Explanation, and Rationale '
draft-ietf-idnabis-rationale-13.txt as an
The IESG has received a request from the Internationalized Domain Names
in Applications, Revised WG (idnabis) to consider the following document:
- 'The Unicode code points and IDNA '
draft-ietf-idnabis-tables-07.txt as a Draft Standard
The IESG plans to make a decision in the next few
A modified charter has been submitted for the Behavior Engineering for
Hindrance Avoidance (behave) working group in the Transport Area of the
IETF. The IESG has not made any determination as yet. The modified
charter is provided below for informational purposes only. Please send
your comments
A modified charter has been submitted for the Access Node Control Protocol
(ancp) working group in the Internet Area of the IETF. The IESG has not
made any determination as yet. The modified charter is provided below for
informational purposes only. Please send your comments to the IESG
mailing
A new IETF working group has been proposed in the Transport Area. The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (i...@ietf.org) by Tuesday,
October 6,
A new IETF working group has been formed in the Applications Area. For
additional information, please contact the Area Directors or the WG
Chairs.
Virtual World Region Agent Protocol (vwrap)
---
Current Status: Active Working Group
Chairs:
The IP Flow Information Export (ipfix) working group in the Operations and
Management Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the working group
Chairs.
IP Flow Information Export (ipfix)
The charter of the Network Endpoint Assessment (nea) working group in the
Security Area of the IETF has been updated. For additional information,
please contact the Area Directors or the working group Chairs.
Network Endpoint Assessment (nea)
-
Last Modified:
25 matches
Mail list logo
