Hey Barry, I'll upload one shortly. Sorry about the delay.
On Mon, 11 May 2020 at 09:18, Barry Leiba <barryle...@computer.org> wrote: > 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
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
