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

[Barry Leiba <[e-mail]>]

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 <[e-mail]> 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