Brian E Carpenter wrote:
However, see draft-wing-v6ops-happy-eyeballs-ipv6
Yuk. That approach appears to be from a completely different universe
that solutions to the IPv4-IPv6 migration issue.
Instead of solving the problem where it originates, at the network level,
it dumps the entire
In message 201101241115.p0obfpmu016...@fs4113.wdf.sap.corp, Martin Rex writes
:
Brian E Carpenter wrote:
However, see draft-wing-v6ops-happy-eyeballs-ipv6
Yuk. That approach appears to be from a completely different universe
that solutions to the IPv4-IPv6 migration issue.
Instead
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you
may receive.
Document:
Sure people can do this, but what is the point?
Let us imagine that as a matter of national policy we are all to live in
smaller houses to save energy. In what respect would such a policy be
realized if everyone bought a second, smaller house and started occupying
both simultaneously?
The
In message aanlktim22fksqt__6efh0k3lduutv6orsboemfrua...@mail.gmail.com, Phil
lip Hallam-Baker writes:
Sure people can do this, but what is the point?
Let us imagine that as a matter of national policy we are all to live in
smaller houses to save energy. In what respect would such a policy
There seem to be two differences between what the draft specifies right
now and what Gecko, at least, does:
1) Section 5.3 says:
Applications SHOULD resolve unrecognized about URIs in the
same way as about:blank.
Gecko treats unknown about:* as unparseable URIs, and is not likely to
Hi,
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Please resolve these comments along with any other Last Call comments you
may receive.
Document: draft-ietf-pwe3-oam-msg-map-14
draft-housley-two-maturity-levels-03 was just posted. It reflects much of the
discussion on this thread over the last few months. In particular, it embraces
the changes put forward in the recent proposal by Dave Crocker, Eric Burger,
Peter Saint-Andre, and Spencer Dawkins. Please take a look
On Sat, Jan 22, 2011 at 1:47 AM, Julian Reschke julian.resc...@gmx.de wrote:
I believe about qualifies for permanent as per
http://tools.ietf.org/html/rfc4395#section-2, if there's something
essential missing, we should fix it.
Hi Julian,
I think the key question is whether this qualifies as
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Sabahattin
Gucukoglu [m...@sabahattin-gucukoglu.com]
My thought right now is perhaps of an OS update that includes a background
client which tries very hard to reduce the effect of breakage
On 1/24/11 10:37 AM, Russ Housley wrote:
draft-housley-two-maturity-levels-03 was just posted. It reflects
much of the discussion on this thread over the last few months. In
particular, it embraces the changes put forward in the recent
proposal by Dave Crocker, Eric Burger, Peter
It seems to me that this proposal strikes a good balance in making an
effort to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...
2. I found this statement to be strange:
The intention of the two-tier
On 1/24/11 11:39 AM, Joel M. Halpern wrote:
It seems to me that this proposal strikes a good balance in making an
effort to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...
2. I found this statement to
On Mon, Jan 24, 2011 at 1:39 PM, Joel M. Halpern j...@joelhalpern.comwrote:
It seems to me that this proposal strikes a good balance in making an
effort to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Bob Hinden
[bob.hin...@gmail.com]
Wasn't the official definition of the meter also tied to Paris?
___
The original measurement was done on a
Earlier, Joel Halpern wrote:
It seems to me that this proposal strikes a good balance in making an effort
to improve the situation regarding our document track.
Regarding the particular clause:
On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
...
2. I found this statement to be strange:
Hi Ted,
At 10:02 24-01-11, Ted Hardie wrote:
I think the key question is whether this qualifies as well-defined
(section 2.3).
The draft declares some tokens/strings to be reserved, and names one such
string. It also declares that other strings may be reserved by other
specifications,
but it
Hi,
In adition to the meter, also the platinum kilogram is in Paris.
Although recently it was found that it has lost some weight
(compared to its brothers and sisters in other locations)...
Wasn't the official definition of the meter also tied to Paris?
On 1/24/2011 12:37 PM, Russ Housley wrote:
draft-housley-two-maturity-levels-03 was just posted. ...
Overall I find this spec to be an improvement over the previous version.
Here are a few areas where improvements can be made.
This phrase in Section 1:
In addition,
IETF
Hello all,
A few weeks ago, if you remember, we had a discussion on moving
Experimental RFCs to Historic. Among other, we spoke that the
definition of Historic status is not right and needs to be corrected.
I'm citing the corresponding message:
Hi,
I think that the author of RFC2026
25.01.2011 6:13, Tony Hansen wrote:
On 1/24/2011 12:37 PM, Russ Housley wrote:
draft-housley-two-maturity-levels-03 was just posted. ...
Overall I find this spec to be an improvement over the previous
version. Here are a few areas where improvements can be made.
[. . . . .]
One
Hello all,
There are a number of Full Standards (STD20-24), that, IMO, need
revsising. Firstly, all of these documents define the protocols only
for TCP and UDP, and that might be useful to define them for such
protocols, as DCCP or SCTP. Moreover, in spite of being the Full
Standards, it
The IESG has received a request from the Network Configuration WG
(netconf) to consider the following document:
- 'Network Configuration Protocol (NETCONF)'
draft-ietf-netconf-4741bis-07.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has approved the following document:
- 'MPLS Transport Profile User-to-Network and Network-to-Network
Interfaces'
(draft-ietf-mpls-tp-uni-nni-03.txt) as an Informational RFC
This document is the product of the Multiprotocol Label Switching Working
Group.
The IESG contact persons
The IESG has approved the following document:
- 'Lightweight DHCPv6 Relay Agent'
(draft-ietf-dhc-dhcpv6-ldra-03.txt) as a Proposed Standard
This document is the product of the Dynamic Host Configuration Working
Group.
The IESG contact persons are Ralph Droms and Jari Arkko.
A URL of this
The IESG has approved the following document:
- 'Indication of support for keep-alive'
(draft-ietf-sipcore-keep-12.txt) as a Proposed Standard
This document is the product of the Session Initiation Protocol Core
Working Group.
The IESG contact persons are Robert Sparks and Gonzalo Camarillo.
The IESG has approved the following document:
- 'Addition of the ARIA Cipher Suites to Transport Layer Security (TLS)'
(draft-nsri-tls-aria-01.txt) as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is
The IESG has no problem with the publication of 'The Internet Routing
Overlay Network (IRON)' draft-templin-iron-17.txt as an Experimental
RFC.
The IESG would also like the IRSG to review the comments in
the datatracker
The IESG has no problem with the publication of 'Cisco Vendor Specific
RADIUS Attributes for the Delivery of Keying Material'
draft-zorn-radius-keywrap-18.txt as an Informational RFC.
The IESG would also like the RFC-Editor to review the comments in
the datatracker
A new Request for Comments is now available in online RFC libraries.
RFC 6079
Title: HIP BONE: Host Identity Protocol
(HIP) Based Overlay Networking Environment (BONE)
Author: G. Camarillo, P. Nikander,
J.
A new Request for Comments is now available in online RFC libraries.
RFC 6092
Title: Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service
31 matches
Mail list logo
