Re: [Technical Errata Reported] RFC6874 (3630)

[t.petch <[e-mail]>]

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.

When I-Ds are urgently required, then they can become RFC in six months,
but that only happens when the correct processes are followed.

Tom Petch


----- Original Message -----
From: "Michael Sweet" <[e-mail]>
To: "Christian Huitema" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; "RFC Errata System" <[e-mail]>
 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 <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf
Of Michael Sweet
> > Sent: Wednesday, May 22, 2013 11:10 PM
> > To: Brian E Carpenter
> > Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; 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
<[e-mail]> 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 <[e-mail]>
> >>>
> >>> 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
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>