Subject: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05

From: Radia Perlman <[email-masked]>
Date: Thu, 22 Nov 2012 22:29:28 -0800

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document provides syntax for specifying a port within a URI for an
IPv6 link-local address.
I find no security-specific issues with this draft, but I do think the
clarity of the draft
could be improved a lot, and also, I think that the draft allows options of
what is or is not allowed,
which could cause confusion for a human using this, since some strings will
work sometimes.  I think it would
be better to lock down what is and is not allowed.

I'm not fond of the term "zone identifier" (I had to do some Internet
searching to figure out what it was). It would
only take a sentence to explain it in this draft.  Admittedly, not many
people will be reading this draft out of
context (like me).

An example of where the wording is needlessly hard to read, and where I
think the rule should be a MUST:

" A <zone_id> SHOULD contain only ASCII characters classified
   in RFC 3986 <http://tools.ietf.org/html/rfc3986> as "unreserved", which
conveniently excludes "]" in order
   to simplify parsing."

That wording could mean that ] is reserved or it could mean that it is not
reserved.
Turns out (by referring to RFC 3986) "]" is actually reserved.
And also, with my preference for specifying mandatory behavior rather than
recommendation...
perhaps saying something like

" A <zone_id> MUST NOT contain ASCII characters classified
   in RFC 3986 <http://tools.ietf.org/html/rfc3986> as "reserved".  The
character  "]" is reserved, so MUST NOT
  be used in the zone ID.

---------
Again,
    "The rules in [RFC5952 <http://tools.ietf.org/html/rfc5952>] SHOULD be
applied in producing URIs."
Why not MUST be applied?

----------
"we recommend that URI parsers accept bare "%" signs...make it easy for a
user to copy and
paste a string..."

again, I'd think it would be better to specify what parsers MUST do, rather
than saying some parsers
can be more lenient, so that the same string will create the same behavior
regardless of the implementation
parsing it.

---------
similarly

"To limit this risk, implementations SHOULD NOT allow use of this
   format except for well-defined usages such as sending to link local
   addresses under prefix fe80::/10."

I'd think it would be better to say MUST NOT, and also, to specify what it
should
do if it receives such a thing.

Radia

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Nov 2012 07:50:22 +0000

Thanks Radia.

The WG reached consensus on a SHOULD-based version. The whole issue
of browser behaviour is contentious, so changing to MUST would be
a WG issue, above my pay grade as a document editor. I will wait
for instructions.

Thnaks for the readability comments, we can work those in.

Regards
   Brian

---

From: Barry Leiba <[email-masked]>
Date: Fri, 23 Nov 2012 09:26:23 -0500

> a WG issue, above my pay grade as a document editor. I will wait

Could you

1: give us some background on the discussion that resulted in SHOULD
instead of MUST, and

2: consider adding explanations of when it would be appropriate to not do a
SHOULD?

For 2, above, there's a great difference between "SHOULD do x unless
there's some reason that it's impossible in this implementation" and
"SHOULD do x unless you don't happen to agree with it."  I'd like to try to
tease those apart.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Nov 2012 14:50:42 +0000

> 1: give us some background on the discussion that resulted in SHOULD

I don't recall it being explicitly discussed - what I meant is that
this is the text that got through WG last call and post-last-call
discussion, without dissent.

> 2: consider adding explanations of when it would be appropriate to not do a

Yes, this is one of the things I look for when reviewing documents, too ;-)

> "SHOULD do x unless you don't happen to agree with it."  I'd like to try to

I'm not a browser implementor, but as far as I can tell, there is a strong
tendency in that community to respect the law of least user astonishment,
so my very personal interpretation is "you SHOULD do this unless experience
shows that it will confuse the user." However, I think the real interpretation
in this case is closer to your first one - do this, because it helps the
user, unless your implementation makes this unreasonable.

Very much IMHO.

    Brian

---

From: Radia Perlman <[email-masked]>
Date: Tue, 27 Nov 2012 16:14:53 -0800

> discussion, without dissent.

Often, in my observation, lack of discussion doesn't necessarily mean
people are happy with the idea.  It often (usually?) means they haven't
read it.

I think it would be good to have an explicit discussion in the WG, not on
the entire draft, but on specifically, whether the syntax should be
standardized so that the same syntax works the same on all implementations,
or whether there is some reason why it's important for implementers to have
flexibility in how they interpret the string, and it's not so important
that URIs work differently with different implementations.  I'd be more
convinced that people want it this way if there was discussion on the
mailing list, focusing people exactly on this issue.  (and I'm also curious
about why the flexibility is important).

Radia

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Nov 2012 07:50:50 +0000

> about why the flexibility is important).

I honestly think that discussing that in 6man is pointless. The issue is
the one I already raised on the IETF list: the user input box on a browser
is one thing, the URI on the wire is another, and in between there is
a heuristic. I don't see what a single IETF WG can do about this other
than bemoaning it, because each browser implementer comes up with their
own heuristic. (I certainly didn't realise how annoying this is before
working on this draft.)

   Brian