On Wed Jun 8 05:57:15 2011, Pete Resnick wrote:
On 6/7/11 11:00 PM, Peter Saint-Andre wrote:
And, more to the point I think, to greatly decrease the quality of
RFCs
published. Perhaps that's OK, but we need pretty strong consensus
that
it's the right thing to do, and I haven't seen that
Vint Cerf wrote:
setting aside interpretation and semantics for a moment, would there
be utility in maintaining tables for each instance of Unicode?
Yes, because developers will have different versions of Unicode
available to them. It would also help developers to migrate by seeing
what has
Paul Hoffman wrote:
On Jun 7, 2011, at 6:24 PM, John C Klensin wrote:
I think this is an improvement but there is one issue about
which we have slightly different impressions. I hope the
difference can be resolved without needing yet more tedious
arguments about documentation. Indeed, if
+1
--On Wednesday, June 08, 2011 12:50 +0100 Alexey Melnikov
alexey.melni...@isode.com wrote:
Vint Cerf wrote:
setting aside interpretation and semantics for a moment,
would there be utility in maintaining tables for each
instance of Unicode?
Yes, because developers will have different
(Subject line changed to reflect my belief that this is not
about 5892bis. I've also removed the copy to the gen-art list
-- if this isn't about 5892bis, it isn't on their agenda, even
though Roni's review may have partially stimulated the thread.)
--On Tuesday, June 07, 2011 19:45 -0700 Paul
The discussion make it clear to me that the tasks for IANA are not clear. It
seems that there needs to be a table for each supported version of Unicode.
Thats document should state that clearly. It is a point where RFC 5892 seems
to be vague, and we should take this opportunity to remove
I have read parts of the document and I find it ok.
The DHCP Server SHOULD allocate a subnet with prefix size less than
or equal to the size P specified in the request. In other words, a
subnet at least the size requested and possibly bigger.
I agree, but prefix size less than or equal to
I'm sorry, I seem to have goofed up during mail editing...
I meant to write that cassifying 6to4 as historic is INappropriate use
of the IETF process in the last sentence.
-Martin
Martin Rex wrote:
George, Wesley wrote:
It's time to remove the stabilisers on the IPv6 bicycle.
This
From: Keith Moore [mailto:mo...@network-heretics.com]
Sent: Tuesday, June 07, 2011 11:21 AM
To: George, Wesley
Cc: ietf@ietf.org; v6...@ietf.org
Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
(Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic
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-dnsext-rfc2672bis-dname-22
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document:
setting aside interpretation and semantics for a moment, would there be
utility in maintaining tables for each instance of Unicode?
v
On Tue, Jun 7, 2011 at 10:45 PM, Paul Hoffman paul.hoff...@vpnc.org wrote:
On Jun 7, 2011, at 6:24 PM, John C Klensin wrote:
I think this is an improvement
Dear all,
AD suggests that we send a last call summary to the list.
Below is the summary for IESG last call to 5892bis draft.
Any comments are welcome.
Jiankang Yao as a co-chair of APPSAWG
---
Summary:
The IESG last call for draft-faltstrom-5892bis-04.txt
From: Martin Rex m...@sap.com
Classification of 6to4 as historic is [in]appropriate use of the IETF
process, because it would be a political .. statement.
Well, we've never done _that_ before, have we? Wouldn't want to set an
unfortunate precedent.
Noel
On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote:
From: Martin Rex m...@sap.com
Classification of 6to4 as historic is [in]appropriate use of the IETF
process, because it would be a political .. statement.
Well, we've never done _that_ before, have we? Wouldn't want to set an
unfortunate
Well, a little miscommunication; I had meant to send the summary to the
APPSAWG where the document was discussed, but sending it to the IETF
list is OK too. Since it's here, one comment:
On 6/8/11 2:04 AM, Jiankang YAO wrote:
issue4: Add the IANA IDNA registry or
On 2011-06-09 04:17, james woodyatt wrote:
On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote:
From: Martin Rex m...@sap.com
Classification of 6to4 as historic is [in]appropriate use of the IETF
process, because it would be a political .. statement.
Well, we've never done _that_ before, have we?
Hi -
From: james woodyatt j...@apple.com
To: ietf@ietf.org
Cc: v6...@ietf.org
Sent: Wednesday, June 08, 2011 9:17 AM
Subject: Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt
On Jun 8, 2011, at 9:04 AM, Noel Chiappa wrote:
From: Martin Rex m...@sap.com
Classification
Noel Chiappa wrote:
From: Martin Rex m...@sap.com
Classification of 6to4 as historic is [in]appropriate use of the IETF
process, because it would be a political .. statement.
Well, we've never done _that_ before, have we? Wouldn't want to set an
unfortunate precedent.
I'm much more
I really think that the right answer is to write an applicability statement for
6to4 that:
- refers to the existing documents about 6to4 problems
- points out use cases for 6to4 which work well, and others that work less well
- emphasizes that 6to4 is a short-term solution and was always
On Jun 7, 2011, at 4:33 AM, TJ wrote:
Less than 1% of the IPv6 traffic reaching us is 6to4.
Unless you provide IPv6 only sites, you should see very little ... that is
part of the point :).
snip
It's time to remove the stabilisers on the IPv6 bicycle.
I agree, but get me native
On 8 Jun 2011, at 21:19, Keith Moore wrote:
Nor, bluntly, is it about a few big content providers or whomever else you
want to label as important. The internet is a hugely diverse place, and you
don't get to dismiss the concerns of people whom you want to label as red
herrings. Again,
On Jun 8, 2011, at 2:32 PM, Dmitry Anipko wrote:
[...] And it unclear to me why IETF would want to take away a _transition_
technique from people for whom it is working...
Let's be very clear. This proposed RFC would not take away the 6to4
transition mechanism. The working group
On Jun 8, 2011, at 7:05 PM, Tim Chown wrote:
On 8 Jun 2011, at 21:19, Keith Moore wrote:
Nor, bluntly, is it about a few big content providers or whomever else you
want to label as important. The internet is a hugely diverse place, and you
don't get to dismiss the concerns of people whom
In message 92fb2780-5f10-4173-a982-12e114bff...@network-heretics.com, Keith M
oore writes:
I really think that the right answer is to write an applicability statement f
or 6to4 that:
- refers to the existing documents about 6to4 problems
- points out use cases for 6to4 which work well, and
On Jun 8, 2011, at 11:35 PM, Mark Andrews wrote:
Have broken 6to4 relays is *good* for the long term health of the
Internet. Applications should cope well with one address of a
multi-homed server being unreachable. Billions of dollars have
been wasted because this has not been seen as a
The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Subnet Allocation Option'
draft-ietf-dhc-subnet-alloc-12.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has approved the following document:
- 'Multicast Acquisition Report Block Type for RTP Control Protocol
(RTCP) Extended Reports (XRs)'
(draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt) as a Proposed Standard
This document is the product of the Audio/Video Transport Extensions
The IESG has received a request from the Audio/Video Transport Payloads
WG (payload) to consider the following document:
- 'RTP Payload Format for MPEG-4 Audio/Visual Streams'
draft-ietf-payload-rfc3016bis-01.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks,
The IESG has approved the following document:
- 'URN Namespace for the Defence Geospatial Information Working Group
(DGIWG)'
(draft-reed-urn-dgiwg-03.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
30 matches
Mail list logo
