Subject: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jul 2012 13:30:15 +0100

This version includes changes for the recent comments from Dave Thaler.
It needs a check by the WG that we still have consensus.

We did not delete one sentence in section 3 that Dave objects to:
"Consequently this document recommends that browsers
support this syntax in addition to the formal URI syntax defined
above."

The URI list raised no objection to the formal syntax change.

   Brian + Bob (as author)

-------- Original Message --------
Subject: I-D Action: draft-ietf-6man-uri-zoneid-02.txt
Date: Wed, 11 Jul 2012 05:23:52 -0700
From: [email-masked]
To: [email-masked]
CC: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
	Author(s)       : Brian Carpenter
                          Robert M. Hinden
	Filename        : draft-ietf-6man-uri-zoneid-02.txt
	Pages           : 10
	Date            : 2012-07-11

Abstract:
   This document describes how the Zone Identifier of an IPv6 scoped
   address can be represented in a a literal IPv6 address and in a
   Uniform Resource Identifier that includes such a literal address.  It
   updates RFC 3986 and RFC 4007 accordingly.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-uri-zoneid-02

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-6man-uri-zoneid-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Dave Thaler <[email-masked]>
Date: Thu, 12 Jul 2012 19:16:15 +0000

Brian and Bob already heard this but wanted list discussion before making
any changes to the doc, so posting publically...

Section 3 states:
> For example:
>
>     http://[fe80::a%en1]
>
>   It seems that modern browsers can be adapted to parse this because it
>   is inside of the "[" "]"'s.  

The sentence above isn't true (claim is way too broad).  The counter example
is that IE is a modern browser.   It cannot "be adapted" to treat
http://[fe80::1%251]/ as fe80::1%251 without breaking backwards 
compatibility with all the code that treats it as fe80::1%1.

>  This would permit the output of commands
>   like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser
>   address bar.

The sentence above is misleading, because the use of the "-" syntax
specified by this draft would already permit the output of commands like
ping6 -w ff02::1-en1 to be "cut and pasted" into a browser address bar.
The "would permit" implies that it wouldn't otherwise permit, which is
not true with draft -02.

>  Consequently this document recommends that browsers
>   above.

The above sentence is harmful.   

Consider http://[fe80::1%251]/

Is the embedded address
fe80::1%1
or
fe80::1%251
?

In Firefox apparently it's the latter, and in IE it's the former.
I see no reason to "recommend" one over the other, especially given 
that the market share (i.e. how commonly deployed) would be in favor 
of fe80::1%1 so you can't take that as an argument for the latter.

Because it's completely unpredictable without having 
browser-specific knowledge which I think is inappropriate here, I 
don't think it should recommend either one.   Making a recommendation
in this document will just increase the likelihood of interoperability
problems as people start passing URIs like "http://[fe80::1%251]/"
into APIs and files without knowing how it'll be interpreted by the
broad base of already deployed apps and libraries.   We don't want
to make the situation worse, and this sort of recommendation just
makes the current bad situation worse.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Brian E Carpenter
> Sent: Wednesday, July 11, 2012 5:30 AM
> To: 6man
> Subject: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
> 
> "Consequently this document recommends that browsers support this
> syntax in addition to the formal URI syntax defined above."
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 12 Jul 2012 15:47:46 -0400

> makes the current bad situation worse.

Suggestion:
On input, applications MUST accept the formal syntax and MAY accept 
another syntax.
On output, applications MUST use the formal syntax and MUST NOT use 
another syntax.

For example, when a user pastes "http://[fe80::1%251]", the browser 
interprets however it wants, turns it into either "http://[fe80::1-251]" 
or "http://[fe80::1-1]", and displays that in the address bar.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: SM <[email-masked]>
Date: Thu, 12 Jul 2012 15:34:48 -0700

Hi Simon,
>On output, applications MUST use the formal syntax and MUST NOT use 

As long as an implementation supports the formal syntax, there is 
interoperability.  Telling people what not to use sounds appropriate 
if there is a good reason to do so.  The requirements seem redundant to me.

Regards,
-sm

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Jul 2012 08:35:31 -0400

On 07/12/2012 06:34 PM, SM wrote:
> interoperability.  Telling people what not to use sounds appropriate if
> there is a good reason to do so.  The requirements seem redundant to me.

Have you heard of Postel's law?

(semi joking)

Simon

---

From: SM <[email-masked]>
Date: Fri, 13 Jul 2012 09:00:57 -0700

Hi Simon,
>Have you heard of Postel's law?

I try to be liberal in accepting arguments arguments from by 
implementers.  I am conservative when it comes to usage of RFC 2119 key words.

Regards,
-sm

---

From: Simon Perreault <[email-masked]>
Date: Fri, 13 Jul 2012 12:13:10 -0400

On 07/13/2012 12:00 PM, SM wrote:
> implementers.

My proposal stemmed from Dave Thaler's argument... not sure what you're 
implying.

> I am conservative when it comes to usage of RFC 2119 key
> words.

The problem with RFCs these days is definitely not that they use too 
many RFC 2119 key words!

Simon

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Jul 2012 10:25:37 -0700

Section 5 of RFC2460 states:

   "In response to an IPv6 packet that is sent to an IPv4 destination
   (i.e., a packet that undergoes translation from IPv6 to IPv4), the
   originating IPv6 node may receive an ICMP Packet Too Big message
   reporting a Next-Hop MTU less than 1280.  In that case, the IPv6 node
   is not required to reduce the size of subsequent packets to less than
   1280, but must include a Fragment header in those packets so that the
   IPv6-to-IPv4 translating router can obtain a suitable Identification
   value to use in resulting IPv4 fragments.  Note that this means the
   payload may have to be reduced to 1232 octets (1280 minus 40 for the
   IPv6 header and 8 for the Fragment header), and smaller still if
   additional extension headers are used."

RFC2460 therefore requires the IPv4 destination to be able to
reassemble at least 1280 bytes minus 28 (since the translation
from an IPv6 header plus fragment header to an IPv4 header
incurs a 28 byte size reduction). However, section 3.3.2 of
RFC1122 states:

         "We designate the largest datagram size that can be reassembled
         by EMTU_R ("Effective MTU to receive"); this is sometimes
         called the "reassembly buffer size".  EMTU_R MUST be greater
         than or equal to 576, SHOULD be either configurable or
         indefinite, and SHOULD be greater than or equal to the MTU of
         the connected network(s)."

By assuming an EMTU_R of greater than 576 bytes, RFC2460
is therefore in violation of RFC1122, which could lead to
communication failures. How do we reconcile this?

Thanks - Fred
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Sat, 14 Jul 2012 18:02:54 +1000

In message <[email-masked]
> communication failures. How do we reconcile this?

You live with it.   Nobody has said that IPv6 to IPv4 translation
will work in all circumstances.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jul 2012 09:41:56 +0100

> there is a good reason to do so.  The requirements seem redundant to me.

Also, telling browser implementers what to do has very little chance
of success. Speaking only for myself, I'm inclined to accept Dave Thaler's
line of argument. The fact that some browsers in the past accepted
a raw % and that IE today accepts an escaped % (i.e. %25) makes it very
hard to suggest a consistent use of % at all. Maybe we just have to
drop this point.

   Brian

---

From: Thomas Narten <[email-masked]>
Date: Sat, 14 Jul 2012 07:38:28 -0400

> communication failures. How do we reconcile this?

How many TCP/IP stacks exist today that cannot connect to an Ethernet,
and thus, handle 1500 byte datagrams?

I suspsect that platforms limited to accepting IP datagrams of max
size 576 are gettign to be an extreme edge case these days.

Thomas

---

From: Simon Perreault <[email-masked]>
Date: Sat, 14 Jul 2012 10:39:19 -0400

On 07/14/2012 04:41 AM, Brian E Carpenter wrote:
> of success.

So obviously browser implementers should be involved in this discussion? 
We shouldn't be "telling" them, we should be discussing with them.

> Speaking only for myself, I'm inclined to accept Dave Thaler's

It looks like my suggestion wasn't clear. I too agree with Dave Thaler's 
argument. I was building on top of it... Not sure how to explain it or 
formulate it otherwise...

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Jul 2012 18:04:33 +0100

> We shouldn't be "telling" them, we should be discussing with them.

Yes, but I think that's outside the scope of the present draft.
I understand that there is forum for such discussions over in
W3C-land.

> formulate it otherwise...

I think your suggestion was clear, just not (IMHO) a useful thing to
put in an RFC.

    Brian

---

From: Simon Perreault <[email-masked]>
Date: Sat, 14 Jul 2012 13:16:36 -0400

> I understand that there is forum for such discussions over in

Ah ok.

> I think your suggestion was clear, just not (IMHO) a useful thing to

Thanks, at least that is clear.

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Jul 2012 08:57:35 +0100

Without consulting my co-author, here's my personal suggestion for
a change to the draft. There's just time to submit an update before
the cutoff, if people respond immediately.

OLD
   In recent years, web browsers have evolved considerably and now
   accept and parse many forms of input that are not a formal URI.
   Examples of this include host names, search items, bookmarks, search
   history, etc.  For example the Google Chrome browser now calls the
   "address bar" the "omnibox" [chrome].  The authors believe it is
   feasible, and very convenient for users, if browsers also allow (in
   addition to the formal URI syntax defined in this document) a syntax
   that will enable cut and paste.  For example:

     http://[fe80::a%en1]

   It seems that modern browsers can be adapted to parse this because it
   is inside of the "[" "]"'s.  This would permit the output of commands
   like ping6 -w ff02::1%en1 to be "cut and pasted" into a browser
   address bar.  Consequently this document recommends that browsers
   support this syntax in addition to the formal URI syntax defined
   above.

NEW

   In recent years, web browsers have evolved considerably and now
   accept and parse many forms of input that are not a formal URI.
   Examples of this include host names, search items, bookmarks, search
   history, etc.  For example the Google Chrome browser now calls the
   "address bar" the "omnibox" [chrome]. Thus, it seems that browsers
   can take a pragmatic approach to literal addresses including ZoneIDs.
   Unfortunately there is no way to resolve the discrepancy between
   the two approaches mentioned above (raw "%" versus "%25") and
   therefore we recommend general implementation of the new "-" syntax
   defined by this document. This will allow simple "cut and paste"
   between tools such as "ping6" and browser address bars.

 Brian

---

From: Simon Perreault <[email-masked]>
Date: Sun, 15 Jul 2012 07:34:33 -0400

>     between tools such as "ping6" and browser address bars.

How will browser support for "-" have any impact on cut-and-pastability 
with ping6? ping6 will still be "%"-only, both on input and output, as 
far as I can see. Same for all apps that operate on addresses, not URLs.

My feeling that I'm missing something is growing...

Simon

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Jul 2012 17:19:36 +0100

> My feeling that I'm missing something is growing...

Perhaps the draft is missing something that I imagined to be there...

(pause while Brian reads the draft)

... OK, as a result of Dave's comments, we now say:

"  Section 11 of RFC 4007 is updated to allow "-" as well as "%" as the
   preceding delimiter of a ZoneID."

What we do *not* say is to recommend or suggest that all tools that
support RFC 4007 should be updated. Should we also add that?

    Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 15 Jul 2012 18:49:57 +0200

> support RFC 4007 should be updated. Should we also add that?

I believe this direction is wrong. Allowing "-" does not replace "%"
anytime soon and hence we simply make the problem worse. The "%"
separator is also embedded in other IETF standards-track specifications; I
doubt they will all be revised soon to add "-". And then there is of
course the question what the canonical format is for comparisions etc.

I believe cut'n'paste from utilities to browsers and back to utilities
is desirable (it is not just one direction). All utilities I have
understand "%". How many years will cut'n'paste be a hassle if we
allow both formats?

>From a user experience point of view, the only really sensible thing
to do for a browser is to accept %en1 literally. And apparently, this
can be done. Changing all our standards to support "-" and then
waiting years for this to be supported by all the system tools is from
a users' perspective pretty much a disaster.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jul 2012 08:03:03 +0100

Juergen,

> The "%"
> separator is also embedded in other IETF standards-track specifications;

Can you be specific about that? The context here is very specific and
I am not aware of any other standards that are relevant to IPv6 literals.

There clearly isn't consensus in the WG on a change to the draft that can be
made before today's cutoff.

More below:

On 15/07/2012 17:49, Juergen Schoenwaelder wrote:
> anytime soon and hence we simply make the problem worse. 

The problem at the moment is the lack of *uniform* support for ZoneIDs
in URIs. The cause of that problem is that the delimiter chosen some years
ago is an escape charater in URIs. IMHO that was a collective error;
we would never have chosen "$" as the delimiter because everybody knows
that's an escape character in many CLIs; we just made a mistake by
overlooking that "%" is also an escape character.

The WG has already decided to fix this by adding a second delimiter "-".

> The "%"

Correct, we have added a reference to the IAB draft on this topic, but
comparison isn't very important for this case because the URIs concerned
have no meaning outside the originating host.

> understand "%". How many years will cut'n'paste be a hassle if we

Less than infinity, which is the problem today, since most browsers simply
can't handle ZoneIDs at all.

> can be done. 

Or not, according to which browser you consider. Remember that it was
intentionally removed from Firefox because it violates the URI standard.
And IE accepts %25en1, so we have an existing incompatibility.

> Changing all our standards to support "-" and then

It is annoying, but seems better than having no solution at all.

   Brian

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jul 2012 11:58:37 +0200

> I am not aware of any other standards that are relevant to IPv6 literals.

RFC 4001 and RFC 6021. These are the ones I have edited. There may be
more. And RFC 4001 seems pretty widely used, pretty much in all more
recent IP related MIB modules:

  http://www.arkko.com/tools/allstats/citations-rfc4001.html

According to 

  http://www.arkko.com/tools/allstats/citations-rfc4007.html

RFC 4007 is used by 9 other RFCs. We could check whether any of the
other 7 RFCs may use a literal IPv6 address format with a zone
identifier.

> The WG has already decided to fix this by adding a second delimiter "-".

I am concerned that we are simply too late in the game for changing
this delimiter, in particular if we start allowing both via an update
to RFC 4007.

Also note that RFC 4001 has a DISPLAY-HINT, hence the text in section
1 may be somewhat misleading. On the wire, SNMP ships a number but it
is most likely presented as a rendered value to the user or databases.
RFC 6021 clearly uses a textual format on the wire.

> have no meaning outside the originating host.

I am not sure this is generally true. While the interpretation of the
URI is certainly host specific (or even more precise specific to the
nodes' interfaces), this does not necessarily mean those URIs are
never compared outside the host.

> can't handle ZoneIDs at all.

If it were that simple, we could simply recommend that browsers should
be lenient and accept the %en1 format. The question is really whether
Internet Explorer people would do so and whether Firefox people would
go back to support what they apparently did before. This would enable
round-trip cut'n'paste and we would be done.
 
> And IE accepts %25en1, so we have an existing incompatibility.

I understand. That is a standardization / implementation issue to
solve.  Solving it by introducing a new notation and pushing the
conversions to users for years to come seems a not very user friendly
resolution.

> It is annoying, but seems better than having no solution at all.

I am not even sure about that. The "%" notation works reasonably well
across many applications today. I would be bad if side-effects of an
attempt to settle the URI issue and the desire to support cut'n'paste
at the end causes other things to start disagreeing about the
separator.

Bottom line: I guess my concern mostly boils down to an update of RFC
4007 that allows multiple separators and the effects this might have
by system tools producing and consuming different notations.

/js

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jul 2012 11:51:13 +0100

Regards
   Brian Carpenter

>From a quick check, none of them do so.

More below...

> is most likely presented as a rendered value to the user or databases.

Yes, but of course the name/number mapping is entirely local to the
host in which it applies. At the other end of an SNMP transaction,
that mapping is lost, so the rendered value is not very significant.
I agree that the DISPLAY-HINT will generate a % delimiter (unless the
community decides to update the textual convention).

> RFC 6021 clearly uses a textual format on the wire.

Yes, but there's a problem IMHO. 6021 says:

"  The canonical format for the zone index is
   the numerical format as described in RFC 4007, Section
   11.2."

That implies that 4007 does truly define a canonical format; but it
doesn't. It says that a host SHOULD support numerical indices and
MAY support other kinds of implementation-depedent non-null strings.
That's underspecified when it comes to mapping into a strictly defined
format such as a URI or yang. And (as in the SNMP case) the ASCII string
is completely meaningless outside the originating host. "1" might not
even refer to interface 1, as far as I can see.

> never compared outside the host.

True; I just meant that it doesn't seem to matter much in practice.
These URIs are intended to be of use during testing and diagnosis,
and if they show up somewhere else in the network, they are garbage
anyway.

> round-trip cut'n'paste and we would be done.

I am not interested personally in taking that fight to the URI community;
that's why I pursued the current direction. Of course, the WG can decide
otherwise.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jul 2012 13:07:37 +0200

> even refer to interface 1, as far as I can see.

Whatever other problems there might be, the typedef uses "%" on the
wire - thats the point I was trying to make. Anyway, the intended
reading of this text was:

  The canonical format for the zone index _in this typedef_ is
  the numerical format as described in RFC 4007, Section 11.2.

That is the "canonical" applies to the YANG typedef, not to RFC 4007
(but we use the RFC 4007 SHOULD format as the canonical format.

/js

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Jul 2012 08:57:49 -0700

Thomas,

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Saturday, July 14, 2012 4:38 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: RFC2460 violation of RFC1122
> 

Others might disagree, but I don't mind assuming 1500.
But then, the size 1280 is in no way significant to IPv4
hosts so why stop there? Why not go all the way and say
that IPv4 hosts are expected to reassemble at least 1500
the same as for IPv6 hosts?

Thanks - Fred

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 Jul 2012 12:37:29 -0400

> Why not go all the way and say that IPv4 hosts are expected to
> reassemble at least 1500 the same as for IPv6 hosts?

We can say it, but how will we enforce it on the deployed base?

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Jul 2012 09:43:05 -0700

> Sent: Monday, July 16, 2012 9:37 AM
> To: Templin, Fred L
> Cc: [email-masked]

We can't enforce it, just the same as that we can't
enforce anything over 576. Once the standards are
violated, we are already living in sin - so what
does it hurt to magnify the sin ever so slightly?

Thanks - Fred

---

From: Dave Thaler <[email-masked]>
Date: Mon, 16 Jul 2012 21:56:24 +0000

I'm ok with the updated text Brian posted.

To comment on the other points others raised:

* I agree that we should define either '%' or '-' as being the canonical form.
   RFC 5952 covers issues with not having one, and defines a canonical form
   for IPv6 literals, but does not mention the zone id at all.   If we want safe
   cut-and-paste, then '-' needs to be defined as canonical (i.e., what you 
   output).   However, you won't get cut-and-paste to things that haven't
   been updated to support it.   So one conclusion you might draw is that
   you can't get cut-and-paste *everywhere* within our lifetime, and you should
   just get used to it.  And if you're one of the people who draws that conclusion
   then you might even go so far as to question the whole document, which 
   seems to be where Juergen is coming from.

* Brian writes: "What we do *not* say is to recommend or suggest that all 
   tools that support RFC 4007 should be updated. Should we also add that?"

   If we really care about cut-and-paste, then yes.   Which is why this document
   is so difficult to get benefit from, since it requires changing so many things.
   (See last paragraph of [RFC5218] section 2.1.1.)

* Juergen writes: "Changing all our standards to support "-" and then waiting
    years for this to be supported by all the system tools is from a users' 
    perspective pretty much a disaster."

   I'm actually fairly sympathetic to that point of view.

   The status quo without this document is basically that you cannot use
   zone IDs in URIs, although some apps and OSs support URI-like strings
   that do allow them but it may vary by app and OS.   With this document,
   the story is that you can use them in some (updated) applications and 
   thus sometimes you can get cut-and-paste.   That sounds like a small
   benefit to get from requiring changes to all IPv6 literal (including in URIs) 
   parsers/generators.   This doesn't seem to bode well from an RFC 5218
   analysis standpoint.

* Juergen writes: " If it were that simple, we could simply recommend that 
    browsers should be lenient and accept the %en1 format. The question is 
    really whether Internet Explorer people would do so and whether Firefox 
    people would go back to support what they apparently did before."

   As I mentioned in my original email, it's not just IE 7 and up, it's also the 
   OS APIs so it's pretty pervasive (again, not on the wire just in APIs within
   the host) so I think you mean "whether IE and Windows people would do so".
   I think it's probably safe to assume the answer is "No" because it may result 
   in breaking applications.   That's not something that's worth it just to get 
   "cut-and-paste" which is nowhere near as important as app compat.

-Dave

> Sent: Sunday, July 15, 2012 12:58 AM
> To: [email-masked]
> Subject: Re: [Fwd: I-D Action: draft-ietf-6man-uri-zoneid-02.txt]
> 
> Without consulting my co-author, here's my personal suggestion for a change to
> the draft. There's just time to submit an update before the cutoff, if people
> respond immediately.
> 
> OLD