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 _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
