Re: [Captive-portals] AD review of draft-ietf-capport-architecture-07

[Barry Leiba <[e-mail]>]

Thanks for the reply, Dave, and I think we're OK to start last call on
the document after you post a revised I-D with the changes so far --
most unresolved things are not at a blocking level.  Just one thing
I'd like to push on before you revise the I-D, though:

> > Please be consistent about using “URI”, and not “URL”.
>
> Changed all URI to URL in commit
> https://github.com/capport-wg/architecture/commit/a9c87ba48aa64564bd9d0e1f21bd82906a2714f4

But that's backward: the IETF formally defines "URI" [RFC3986], not
"URL", and that document says [Section 1.1.3]:

   Future specifications and related documentation should
   use the general term "URI" rather than the more restrictive terms
   "URL" and "URN"

(Additionally, we should probably include an informative reference to
3986 on first use of the term.)

If the working group really wants "URL" here I won't block it further,
but I would strongly prefer that we use "URI", consistent with IETF
usage.

---

Collecting the other points that aren't resolved, but that need not
block last call:

> > General:
> > Expect comments during IESG Evaluation about the extensive use of BCP
> > 14 key words in an Informational document.  I don’t object to it here,
> > though I do find all the “MAY”s odd (example: “A device MAY query this
> > API at any time”, rather than “A device may query this API at any
> > time”), but I do expect some ADs to comment on it.
>
> I've reviewed all upper-case "MAY", and I believe they are used as
> intended.  We've allowed the user equipment to participate or not in various ways.

OK, then no more to do here.  This was mostly just a note that I
expect to see comments, and not an expectation of any changes to the
document.  Thanks for checking.

> > — Section 2.3 —
> >
> >    The API SHOULD provide evidence
> >    to the caller that it supports the present architecture.
> >
> > I don’t understand what this means; can you explain?
>
> To me, this means that User Equipment can determine from the
> interaction that the API is implementing this architecture vs.
> being some random API. I imagine that a version number or content-
> type could achieve this.
>
> I've opened https://github.com/capport-wg/architecture/issues/61
> to track the issue.

OK.  A small wording tweak will be good at some point, but let's see
if anyone else raises this point in reviews.

> > — Section 3.3 —
> > Are we really talking about evaluating individual identifiers here?
> > Or does this really mean to discuss *methods* of generating or
> > choosing identifiers?
>
> I believe this is about choice of identifier in a solution/standard.
>
> Opened issue https://github.com/capport-wg/architecture/issues/62

Great; again, a small wording tweak will do it.

> > — Section 3.4.3 —
> > Is this section talking about using a context-free URI as a UEe
> > identifier?  It should be clearer about that, if so (and if that’s not
> > what it’s about, the section is misplaced).  There’s nothing in here
> > that discusses how such identifiers would meet the specified criteria.
>
> I think this is trying to say the server should not be looking at
> Ethernet addresses, for example, because the server is probably not
> on the same subnet as the User Equipment. So the info needs to be
> in the URL.
>
> I hope others can weigh in on this. Created issue
> https://github.com/capport-wg/architecture/issues/63

To be clear here, I'm not concerned about the content of the section
as such, only about how it fits into the topic of identifier
selection.  So I think it's just a matter of clarifying that, and it
should be easy to deal with by the time last call ends.

Barry