Can we get a revised I-D up on this now, so I can get the last call started? The last calls on the other two documents are ending this week.
Martin, should I hold the telechat scheduling of the other two documents to make sure that architecture is on the same telechat as they are, so the IESG is reviewing them all together? I think that's best, but can be convinced not to have the others wait. Barry On Mon, Apr 27, 2020 at 10:21 AM Barry Leiba <barryle...@computer.org> wrote: > > 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
