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

> On Apr 27, 2020, at 7:21 AM, Barry Leiba <barryleiba@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.

FWIW, the API document uses “URI” everywhere other than in its JSON keys. I’d agree that the architecture document should use URI as well.

Thanks,
Tommy
> 
> ---
> 
> 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