Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers
draft-ietf-6man-uri-zoneid-06

[Ballot discuss]

  The Gen-ART Review by Martin Thomson on 16-Nov-2012 raised some
  concerns, and the authors have agreed that changes are needed.
  However, these changes have not appeared yet.  At least one person
  believes that the changes need to be reviewed by the WG.

[Ballot comment]
A very small nit in section 2:

  Note that the behaviour of an IPv6
  stack if passed a non-zero zone index for an address other than link-
  local is undefined.

s/non-zero/non-null/ ?

[Ballot comment]
This is a user interface hack for a completely local matter. It is not related to interoperability over the Internet. It uses error-prone mechanism ("%", which must be escaped, and will end up being double-escaped by accident), and is bound to leak onto the Internet in not great ways. It's not worthy of a standards track document. But it's also not going to improve significantly by using some other mechanism, it's better documented than not, and I don't have the energy to argue about whether it should be other than standards track. "Blech" I say, but I'm not going to stand in its way if that's what the community wants to do.

[Ballot comment]
I've been really confused by the the appendix, which mentions: Appendix A. Alternatives Considered
However, the solution 3 is the selected solution AFAIT

  3.  Escaping the escape character as allowed by RFC 3986:

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

      Advantage: allows use of browser, consistent with general URI
      syntax.

      Disadvantage: somewhat ugly and confusing, doesn't allow simple
      cut and paste.

However, the word "alternative" forced me to re-read the draft to see if I missed something...


Editorial:
OLD
  The MIB textual convention [RFC4001] and the socket
  interface [RFC3493] define this as a 32 bit unsigned integer.

NEW
  The MIB textual convention InetZoneIndex [RFC4001] and the socket
  interface [RFC3493] define this as a 32 bit unsigned integer.

[Ballot comment]
-- Section 3, first paragraph --
The use of "older versions" and "recent versions" will be meaningless after this RFC has been published for a while.  I suggest "some versions" instead, for both.

-- Section 3, second paragraph --
As discussed in the AppsDir review thread, maybe it would help to add something like this at the end of the paragraph?:

  Such bare "%" signs are for user interface convenience, and must be
  turned into properly escaped characters ("%25" encodes "%" in URIs)
  before the URI is used in any protocol.

I think it would be useful to also say something about what happens if, say, instead of "en1", there's a ZoneID called "ee1".  A URI parser encountering "fe80::a%ee1" would have to decide whether to interpret the "%" as "%25", or whether to interpret "%ee" as a percent-escaped 0xEE character.  Advice would be useful; lacking useful advice, a warning that this could happen would at least help a little.

-- Section 4, last paragraph --
Brian's having a conversation with Yves about this on the AppsDir review thread, with a suggestion that the document recommend stripping the ZoneID before sending the URI out on the wire.  Recording that here for the record.

IANA has reviewed draft-ietf-6man-uri-zoneid-05, which is currently in
Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

[Ballot comment]

- 2nd para of section 3 says that browsers "should" accept a
bare % as input. I don't know if you mean that "should" as a
2119 SHOULD or not. 

- Same place: Do you need to say that the browser MUST properly
escape that if it sends the URI anywhere, that is, that the URI
emitted MUST conform to this spec and include e.g., "%25eth0"
and not just "%eth0"?

- Idle curiosity: anyone know if its possible to use a %
character in an interface name on any common OS? If it were,
then maybe worth mentioning that that'd also need to be
escaped? On ubuntu "ifconfig 25% up" at least gives the same
error as "ifconfig foo up" so seems like if I were in a playful
mood, I could muck with udev and call an interface "25%". So
for the nittiest-nitty folks you could, if you wanted, say that
an interface called "25%" might result in a URI containing
"[fe80::a%2525%25]" :-)

- The secdir review [1] has a number of suggestions that the
authors seem happy to take on board.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03638.html

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'Representing IPv6 Zone Identifiers in Address Literals and Uniform
  Resource Identifiers'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


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




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-uri-zoneid/ballot/


No IPR declarations have been submitted directly on this I-D.