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

[Kyle Larose <[e-mail]>]

Hey Barry,

I'll upload one shortly. Sorry about the delay.

On Mon, 11 May 2020 at 09:18, Barry Leiba <[e-mail]> 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 <[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