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

From: Barry Leiba <[email-masked]>
Date: Mon, 11 May 2020 09:17:23 -0400

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 <[email-masked]> 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

---

From: Kyle Larose <[email-masked]>
Date: Mon, 11 May 2020 11:10:17 -0400

Hey Barry,

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

On Mon, 11 May 2020 at 09:18, Barry Leiba <[email-masked]> wrote:

> > > > that discusses how such identifiers would meet the specified criteria

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 May 2020 12:16:03 -0400

> best, but can be convinced not to have the others wait.

So you want to have:
1) API
2) architecture
3) rfc7710bis

all on the 2020-05-21 telechat?
That would be awesome!

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 May 2020 12:38:03 -0400

Yes, that's the plan.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 May 2020 12:38:59 -0400

Sorry, no... I missed the date: they would all be on the 4 June
telechat.  The last call on the architecture doc won't be finished
before 21 May.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 May 2020 12:55:45 -0400

And, correction again: there is no telechat on 4 June, so it's 11 June.

Barry

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 12 May 2020 08:39:47 +1000

Thanks for working through this everyone.  All while I was sleeping :)

On Tue, May 12, 2020, at 02:55, Barry Leiba wrote:
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>