Re: [Technical Errata Reported] RFC6874 (3630)
t.petch <ietfc@btconnect.com> Fri, 24 May 2013 15:37 UTC
Return-Path: <ietfc@btconnect.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5030B21F8FE8 for <ipv6@ietfa.amsl.com>; Fri, 24 May 2013 08:37:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.527
X-Spam-Level:
X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZE5PSoVnZ5q for <ipv6@ietfa.amsl.com>; Fri, 24 May 2013 08:37:11 -0700 (PDT)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0186.outbound.messaging.microsoft.com [213.199.154.186]) by ietfa.amsl.com (Postfix) with ESMTP id E43AE21F8F4A for <ipv6@ietf.org>; Fri, 24 May 2013 08:37:10 -0700 (PDT)
Received: from mail118-db8-R.bigfish.com (10.174.8.238) by DB8EHSOBE038.bigfish.com (10.174.4.101) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 May 2013 15:37:09 +0000
Received: from mail118-db8 (localhost [127.0.0.1]) by mail118-db8-R.bigfish.com (Postfix) with ESMTP id B852A403C4; Fri, 24 May 2013 15:37:09 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -17
X-BigFish: PS-17(zzbb2dI98dI9371I936eI542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah19a27bh172cdfh8275bh8275dh8275chz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h)
Received: from mail118-db8 (localhost.localdomain [127.0.0.1]) by mail118-db8 (MessageSwitch) id 1369409827400173_16791; Fri, 24 May 2013 15:37:07 +0000 (UTC)
Received: from DB8EHSMHS013.bigfish.com (unknown [10.174.8.241]) by mail118-db8.bigfish.com (Postfix) with ESMTP id 5EDBD3E007D; Fri, 24 May 2013 15:37:07 +0000 (UTC)
Received: from AMSPRD0711HT001.eurprd07.prod.outlook.com (157.56.250.181) by DB8EHSMHS013.bigfish.com (10.174.4.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 May 2013 15:37:06 +0000
Received: from pc6 (86.173.197.168) by pod51017.outlook.com (10.242.14.162) with Microsoft SMTP Server (TLS) id 14.16.311.1; Fri, 24 May 2013 15:37:02 +0000
Message-ID: <033d01ce5893$c3522360$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: Michael Sweet <msweet@apple.com>
References: <20130523035151.7B24A6210A@rfc-editor.org> <519DA89C.5070704@gmail.com> <13FD8630-3CB7-46D5-9A27-A83EAD2E7F74@apple.com> <C91E67751B1EFF41B857DE2FE1F68ABA0FF4CC0A@TK5EX14MBXC274.redmond.corp.microsoft.com> <CF457469-49FC-42CC-9E04-487FE035CA10@apple.com> <014b01ce5854$be6c7880$4001a8c0@gateway.2wire.net> <9B503485-D9A7-4D90-991C-162D9C7EE8FF@apple.com>
Subject: Re: [Technical Errata Reported] RFC6874 (3630)
Date: Fri, 24 May 2013 16:31:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.173.197.168]
X-OriginatorOrg: btconnect.com
Cc: Christian Huitema <huitema@microsoft.com>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 May 2013 15:37:16 -0000
---- Original Message ----- From: "Michael Sweet" <msweet@apple.com> To: "t.petch" <ietfc@btconnect.com> Cc: "Christian Huitema" <huitema@microsoft.com>; <ipv6@ietf.org> Sent: Friday, May 24, 2013 1:10 PM > Tom, > > On 2013-05-24, at 4:00 AM, t.petch <ietfc@btconnect.com> wrote: > > Michael > > > > I would have been happy to see your erratum rejected in 24 minutes, > > because it is an abuse of process. It's a bit like submitting an I-D in > > Swahili, nothing wrong with Swahili but quite wrong for the context. > > > > Erratum are for errors, where the text did not mean what the WG had > > agreed on, where the grammar is wrong, not English, where the text is > > being misinterpreted. > > > > Changes to the function require an I-D. Having had that pointed out to > > you, and you might well have not realised the meaning of an erratum in > > the context of the IETF, other SDO may work differently, yet you persist > > in submitting errata; I hope that future ones are rejected as quickly. > > First, I *have* submitted errata before, both technical and editorial, for basically all of the IPP specifications, and most have been accepted as posted. In some cases the technical errata clearly change the meaning of the original text because the original text was plainly wrong. This is ALLOWED by the currently published process on the RFC Editor's page (which also notes it is a "slippery slope"...): > > http://www.rfc-editor.org/draft-rfc-editor-errata-process-02.txt > > I don't say this as an excuse, merely as explanation, and I don't know whether IPP's special status (PWG maintained) or my status (IPP Designated Expert) within the IETF has anything to do with the latitude that has been granted WRT my errata. > > As for discussing errata in the relevant IETF WG prior to submission, I was not aware of any formal process in this regards and apologize if I have upset you by starting with the errata reports. The process described in the above link implies that reporters start on the web portal to initiate such a discussion with the relevant working group, and the standards development process documents that are readily accessible from the IETF web page say nothing about errata or the errata process: > > http://www.ietf.org/about/process-docs.html > http://tools.ietf.org/html/rfc2026 > > I can also report that the RFC pages do not provide links to the relevant working group or mailing lists, and that the mailing list links on the main IETF page all take you to the message archives and not to the list subscription page (which I had to search for with Google...) > > So again I apologize if I did not follow the process, but honestly I thought I *was*. Michael No problem; my defensiveness is because I see the Area Director as the critical resource in the IETF, and raising an erratum tweaks their tail in a way that an e-mail to a WG list does not. Some with an issue to raise find and start with the main IETF list, where do I go with ..., and someone will always point them to the right area or WG. There is nothing wrong with raising an erratum as a first step when it falls within the IETF's use thereof; it is fine to raise an error if it really is an error. In this case, you are referencing an RFC which, like most such, was extensively discussed on a number of lists, so a lot of people put a lot of effort into producing what you now see, so to say it is wrong, well, that may not be the best way to get support for amending it. However, if you start with the RFC, by looking at the RFC-Editor pages, then the summary screen for RFC6874 tells you that the source is 6man, and clicking on that anchor takes you to a wiki for a Working Group, 6man in fact, which has a list of current work, archives and a charter, which contains details of how to join the mailing list for 6man. I did not know this until five minutes ago, but I expected that there would be a way to make the connection and indeed, there is. Could it be clearer? Can't think of anything offhand. Meanwhile, I don't understand the errata:-( yes I get the gist, but do not see the protocol sequence that causes you grief. Perhaps spelling it out in a longer e-mail to the 6man list would be a good step forward. At the back of my mind is the inkling that this may fly in the face of the IPv6 architecture, that ZoneIDs were carefully defined to have a limited scope and that what you want to do is in violation of that. Time will tell. Tom Petch PS I have always loved the term RFC; this is not a standard that the IETF has produced, carved in tablets of stone, but the best that the IETF has managed to produce so far and would LOVE to hear from anyone with a better idea, it is a Request For Comments:-) > (For reference, the PWG process for errata has direct reporting to the relevant workgroup, and that workgroup is identified in every document we produce...) > > > When I-Ds are urgently required, then they can become RFC in six months, > > but that only happens when the correct processes are followed. > > I'm glad to hear that is possible. Aside from IPP Everywhere, the in-review Wi-Fi Direct Services Print specification is also affected and in fact depends on IPv6 Link Local addressing. > > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Michael Sweet" <msweet@apple.com> > > To: "Christian Huitema" <huitema@microsoft.com> > > Cc: <brian@innovationslab.net>; <ipv6@ietf.org>; <bob.hinden@gmail.com>; > > <ted.lemon@nominum.com>; "RFC Errata System" <rfc-editor@rfc-editor.org> > > Thursday, May 23, 2013 3:25 PM > > > > > >> 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 <huitema@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-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > > Of Michael Sweet > >>> Sent: Wednesday, May 22, 2013 11:10 PM > >>> To: Brian E Carpenter > >>> Cc: brian@innovationslab.net; ipv6@ietf.org; bob.hinden@gmail.com; > > ted.lemon@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.carpenter@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 <msweet@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 > >> -------------------------------------------------------------------- > >> > > > > > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > >
- [Technical Errata Reported] RFC6874 (3630) RFC Errata System
- Re: [Technical Errata Reported] RFC6874 (3630) Brian E Carpenter
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Mikael Abrahamsson
- RE: [Technical Errata Reported] RFC6874 (3630) Christian Huitema
- Re: [Technical Errata Reported] RFC6874 (3630) Ted Lemon
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Brian Haberman
- Re: [Technical Errata Reported] RFC6874 (3630) Brian Haberman
- Re: [Technical Errata Reported] RFC6874 (3630) Ted Lemon
- Re: [Technical Errata Reported] RFC6874 (3630) Brian Haberman
- Re: [Technical Errata Reported] RFC6874 (3630) Ole Troan
- Re: [Technical Errata Reported] RFC6874 (3630) Brian Haberman
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) t.petch
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) t.petch
- RE: [Technical Errata Reported] RFC6874 (3630) Christian Huitema
- Re: [Technical Errata Reported] RFC6874 (3630) Kerry Lynn
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- RE: [Technical Errata Reported] RFC6874 (3630) Christian Huitema
- Re: [Technical Errata Reported] RFC6874 (3630) Kerry Lynn
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Kerry Lynn
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Ole Troan
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: Re: [Technical Errata Reported] RFC6874 (3630) Ray Hunter
- Strange use of link-local (was: [Technical Errata… Brian E Carpenter
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: Strange use of link-local (was: [Technical Er… Michael Sweet
- Re: Strange use of link-local (was: [Technical Er… Tim Chown
- Re: [Technical Errata Reported] RFC6874 (3630) Ray Hunter
- Re: [Technical Errata Reported] RFC6874 (3630) Ole Troan
- Re: [Technical Errata Reported] RFC6874 (3630) Bless, Roland (TM)
- Re: [Technical Errata Reported] RFC6874 (3630) Ole Troan
- Re: [Technical Errata Reported] RFC6874 (3630) Brian Haberman
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Bless, Roland (TM)
- Re: [Technical Errata Reported] RFC6874 (3630) Bless, Roland (TM)
- Re: [Technical Errata Reported] RFC6874 (3630) Brian Haberman
- Re: [Technical Errata Reported] RFC6874 (3630) Bless, Roland (TM)
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Richardson
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Richardson
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Ray Hunter
- Re: [Technical Errata Reported] RFC6874 (3630) Ole Troan
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Sweet
- Re: Strange use of link-local Brian E Carpenter
- Re: [Technical Errata Reported] RFC6874 (3630) Mark Smith
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Richardson
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Richardson
- Re: [Technical Errata Reported] RFC6874 (3630) Michael Richardson