Skip to main content

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

Yes

(Brian Haberman)
(Ron Bonica)

No Objection

(Adrian Farrel)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Robert Sparks)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

Abstain


Note: This ballot was opened for revision 05 and is now closed.

Brian Haberman Former IESG member
Yes
Yes (for -05) Unknown

                            
Ron Bonica Former IESG member
Yes
Yes (for -05) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2012-11-26 for -05) Unknown
-- 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.
Benoît Claise Former IESG member
No Objection
No Objection (2012-11-27 for -05) Unknown
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.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (2012-11-28 for -05) Unknown
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/ ?
Robert Sparks Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-11-26 for -05) Unknown
- 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
Stewart Bryant Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -05) Unknown

                            
Pete Resnick Former IESG member
Abstain
Abstain (2012-11-27 for -05) Unknown
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.