Michael,
I rejected the errata since they were both changing the consensus
of a WG. That level of change is not how the errata system is to be
used. Your approach of writing a new draft proposing these changes is
the correct approach to changing that consensus.
Regards,
Brian
On 5/23/13 10:25 AM, Michael Sweet wrote:
Christian,
I'm happy to write up a new draft proposing my changes and go through that
process. I'm not happy that my errata have been summarily rejected in less than
24 hours with no time for review.
Consider: hundreds of millions of printers, computers, and mobile devices have
been certified and shipped with IPv6 link local support using the IPvFuture
format over the last 8 years. It took those 8 years for the IETF to agree on a
new format with serious compatibility and interoperability issues with the base
IETF standard (STD 66 aka RFC 3986), and my errata against the published RFC
have been rejected after less than 24 hours of discussion.
How do we notify users of RFC 6874 that there are proposed changes, if not in
pending errata?
How long will it take to get a new draft approved that fixes the problems in
RFC 6874? I certainly hope the answer is not 8 years...
On 2013-05-23, at 2:47 AM, Christian Huitema <huit...@microsoft.com> wrote:
Michael, you are asking that the consensus of the WG be reversed. The errata
process is not the way to handle this. You have to go through the motions:
write a draft, submit it, get consensus...
-----Original Message-----
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Michael
Sweet
Sent: Wednesday, May 22, 2013 11:10 PM
To: Brian E Carpenter
Cc: br...@innovationslab.net; ipv6@ietf.org; bob.hin...@gmail.com;
ted.le...@nominum.com; RFC Errata System
Subject: Re: [Technical Errata Reported] RFC6874 (3630)
Brian,
What you're apparently missing is that the client is using the zoneid to choose
a network interface to route packets to that link local address. If the server
returns a uri in its response that uses the same link local address but without
the client's zoneid, then the client will be unable to use said uri because it
won't know which interface to use. Yes the server doesn't care but the client
depends on it (for link local anyways).
This issue is specifically why we (the Printer Working Group) require IPP
Clients to include the zoneid in the HTTP Host header and require IPP Servers
to use the Host value in any generated URIs.
Sent from my iPad
On 2013-05-23, at 1:26 AM, Brian E Carpenter <brian.e.carpen...@gmail.com>
wrote:
As far as I can tell this is completely incorrect and the RFC is
completely correct. It's so wrong that I can't even see how to explain
it. By definition, a ZoneID has no meaning outside the host; its only
effect is to direct the packet to the desired interface on that host.
It has absolutely nothing to do with routing on the network.
Regards
Brian Carpenter
On 23/05/2013 15:51, RFC Errata System wrote:
The following errata report has been submitted for RFC6874,
"Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource
Identifiers".
--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6874&eid=3630
--------------------------------------
Type: Technical
Reported by: Michael Sweet <msw...@apple.com>
Section: 3
Original Text
-------------
Such bare "%" signs are for user interface convenience, and need to
be turned into properly encoded characters (where "%25" encodes "%")
before the URI is used in any protocol or HTML document. However,
URIs including a ZoneID have no meaning outside the originating node.
It would therefore be highly desirable for a browser to remove the
ZoneID from a URI before including that URI in an HTTP request.
Corrected Text
--------------
Such bare "%" signs are for user interface convenience, and need to
be turned into properly encoded characters (where "%25" encodes "%")
before the URI is used in any protocol or HTML document. HTTP Clients
MUST include a ZoneID in any URIs provided in an HTTP request since
HTTP Servers will need it when generating URIs, otherwise the IPv6
address will not be routable.
Notes
-----
The original advice ignores a very real issue: HTTP Servers that generate URIs
from the client's Host: need to include the Client's zoneid in order for the
link local address to be usable/routable.
Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or rejected.
When a decision is reached, the verifying party (IESG) can log in to
change the status and edit the report, if necessary.
--------------------------------------
RFC6874 (draft-ietf-6man-uri-zoneid-06)
--------------------------------------
Title : Representing IPv6 Zone Identifiers in Address Literals
and Uniform Resource Identifiers
Publication Date : February 2013
Author(s) : B. Carpenter, S. Cheshire, R. Hinden
Category : PROPOSED STANDARD
Source : IPv6 Maintenance
Area : Internet
Stream : IETF
Verifying Party : IESG
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
