Thanks for the feedback and PR Gurshabad!
I've replied to Martin's reply regarding the signal section.
As for the privacy considerations, it's probably a good idea. Did you
have some suggestions for content?
Thanks,
Kyle
On Mon, 23 Mar 2020 at 22:52, Gurshabad Grover wrote:
>
> On 3/5/20 12:2
Thanks Martin,
It's unfortunate that we weren't able to better expand on the signals
section, but if the section is confusing or misleading, we probably
should reduce it to something like you've suggested. I think that text
captures the essence of the signal. I'll submit an issue to change it.
On
Thanks for doing this Gurshabad.
I think we've debated the removal of the signaling section on a number of
occasions. Could this text perhaps be reduced to something simpler, especially
in light of our decision not to specify anything?
Perhaps:
--->8--
When User Equipment first connects to a
On 3/5/20 12:25 PM, Martin Thomson wrote:> This starts a joint working
group last call on these documents. Please respond this mail with your
views regarding the suitability of these documents for publication (as
Informational RFC and Proposed Standard RFC respectively) before 2020-03-23.
>
Thank
> On Mar 7, 2020, at 1:54 PM, ddol...@golden.net wrote:
>
> Regarding capport-api, in the section 4.1.1 Server Authentication, is this
> advice different than the authentication done by any other HTTPS client? It
> seems like this section should just be referencing another document (but I
> d
Hi Kyle,
Thanks for the review! I’ve made some editorial fixes in this commit:
https://github.com/capport-wg/api/commit/fabc5994e3d7945140dd379a8b81a28b5b668bb4
> On Mar 14, 2020, at 9:21 AM, Kyle Larose
> wrote:
>
> Hello,
>
> I support publication of capport-api. Thanks for all the hard wo
Hello,
I support publication of capport-api. Thanks for all the hard work!
I have a bunch of minor comments:
Regarding Section 4.1.1:
> If the certificates do
> require the use of AIA, the captive network will need to allow client
> access to the host specified in the URI.
Should this b
Regarding capport-api, in the section 4.1.1 Server Authentication, is
this advice different than the authentication done by any other HTTPS
client? It seems like this section should just be referencing another
document (but I don't know).
Also, I think the API document should give some guidanc
Hi folks,
Our fine editor teams have contributed updates to these drafts.
https://tools.ietf.org/html/draft-ietf-capport-architecture-06
https://tools.ietf.org/html/draft-ietf-capport-api-05
This starts a joint working group last call on these documents. Please respond
this mail with your view
