Subject: Re: [Last-Call] [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

From: Bob Harold <[email-masked]>
Date: Mon, 11 May 2020 13:35:59 -0400

I am curious why section 3.4 does not consider the MAC Address as a
possible identifier?

-- 
Bob Harold

On Mon, May 11, 2020 at 12:56 PM The IESG <[email-masked]> wrote:

>
> The IESG has received a request from the Captive Portal Interaction WG
> (capport) to consider the following document: - 'CAPPORT Architecture'
>   <draft-ietf-capport-architecture-08.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2020-05-25. Exceptionally, comments
> may
> be sent to [email-masked] instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    This document describes a CAPPORT architecture.  DHCP or Router
>    Advertisements, an optional signaling protocol, and an HTTP API are
>    used to provide the solution.  The role of Provisioning Domains
>    (PvDs) is described.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Mon, 11 May 2020 17:50:02 +0000

Hi,
Sorry, I had sent these comments sometime back, a few are still valid.
Could you please take care of these?

Thanks,
Subash

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Thursday, April 30, 2020 at 4:19 PM
To: "[email-masked]" <[email-masked]>
Subject: AD review of draft-ietf-capport-architecture-07

Hi,
I was reviewing this AD and found a few discrepancy needing clarifications, couple of them may just be editorial in nature.
Appreciate your response on this, thanks.

Thanks,
Subash

Section 1.2
Captive Network and Captive Portal are used interchangeably, so do we define captive portal or network or both? – [Pending]

Section 2.3
At minimum, the API MUST provide: (1) the state of captivity and (2) a URI for the Captive Portal Server. – [Pending]
-          However, in draft-ietf-capport-api, section 5: API State Structure, only "captive" (boolean): is mandatory whereas "user-portal-url" (string): is optional. One of these two drafts may need an update for consistency.

Section 2.6 Component Diagram
Although the Provisioning Service, API Server, and Web Portal Server functions are shown as discrete blocks, they could of course be combined into a single element. – [Pending]
-          Here may be we can add the [Captive Portal Enforcement] as well, for eg: API Server, Web Portal Server and Enforcement can co-exist on a single WiFi Access-Point using ACLs. Also there is a feeble reference to this co-location in Section 3.4.1

Section 3 Captive Portal Signal
Is Enforcement Device defined anywhere else? Is it same as Captive Portal Enforcement(I guess so) Or does it coordinate with it? – [Resolved, Please ignore]

From: Captive-portals <[email-masked]> on behalf of Bob Harold <[email-masked]>
Date: Monday, May 11, 2020 at 10:35 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, IETF-Announce <[email-masked]>, "[email-masked]" <[email-masked]>, Martin Thomson <[email-masked]>
Subject: Re: [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

I am curious why section 3.4 does not consider the MAC Address as a possible identifier? -- Bob Harold 
External ([email-masked]<mailto:[email-masked]>)
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL3N1YmFzaC50aXJ1cGFjaHVyY29tZXJpY2FAY29tbXNjb3BlLmNvbS8zNzFmOTQzMDliODUzY2QzNTY0NmVlMjZhYWJlMWI2OS8xNTg5MjE4NjE2Ljg4#key=b689685d9a9a6794f20e6fff664abcc3>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

I am curious why section 3.4 does not consider the MAC Address as a possible identifier?

--
Bob Harold

On Mon, May 11, 2020 at 12:56 PM The IESG <[email-masked]<mailto:[email-masked]>> wrote:

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked]<mailto:[email-masked]> mailing lists by 2020-05-25. Exceptionally, comments may
be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/<https://secure-web.cisco.com/1yVzqJ3UqY3xwLQUGHinMzu-7twa12PiLIN7EN50B62FLD0cXno02n3f_Qw7DSpKpG96CA7TKBLzu9xzC6TVQejhSfGo-jrF8DNmSa3LVszDOuk89O1tF28heTpZxo-Zl4Kzk3DxQoD5Hc8fDnwaLz69x04aBTgzTGR2Tf9ZMouiJgl4PjT97QOV7tu7viXpNVyNfM-2molaELtIJWJd00DqIJTzR2Hap7yETyceSjQTihOQh7tPi056W8nOWCQ-MxwbxsGzR5V37Soo1SFiKSaR_KHKYhK_NLd4ys-MQ_bKZmZiS_YEiEQX_q0lLjmFgTrqjGvQxzlOj0gwI4zthZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F>

_______________________________________________
Captive-portals mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/captive-portals<https://secure-web.cisco.com/1luUyQqfEnnX25r5RvmYXc4O6JMe744dFK_VSJQto5cvtJVqN7Y0Ie7SkRZBkDnAUWnL8L3b4ifd7pTzCT-EsrZmZhOLnLmd_gJDefmDNmw8a8wnbkHiR12asEIcSP9COhQWmnSY75DStoZ7N9Bidi67LQuNxiFexwf8r9J6F6QHrpMpgDgnqiyNKBaJcIC6GmF8UsF3j95f2eFjpdr_0ttHQuXj_XrxTJebBxaS3EdYg8OZsH713lH0DH-VYJ0a_IXiATDxiGaA7gvKppncYKLUo1Pi-xZ7HgL6prLTkzjLEwRFRGlYdkwrDLKV6zUZcbT23_4lyApm-XMaOQo4KZEFyQOebJB-U33Nrqn2nO7w/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals>

---

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

Editors,

I've opened a few issues on the comments Subash indicated were still pending.  I think that we can take these as last call comments in the usual fashion.  I don't see a pressing reason to update the draft, but it would be nice if you could take a look at the remaining items to see if there is any action required.

On Tue, May 12, 2020, at 03:50, Tirupachur Comerica, Subash wrote:
> *From: *"Tirupachur Comerica, Subash" <[email-masked]>
> *Date: *Thursday, April 30, 2020 at 4:19 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *AD review of draft-ietf-capport-architecture-07
> 
> 
> Hi,
> 
> I was reviewing this AD and found a few discrepancy needing 
> clarifications, couple of them may just be editorial in nature.
> 
> *_Section 1.2_*
> Captive Network and Captive Portal are used interchangeably, so do we 
> define captive portal or network or both? – [Pending]
> 
> 
> *_Section 2.3_*
> 
> At minimum, the API MUST provide: (1) the state of captivity and (2) a 
> URI for the Captive Portal Server. – [Pending]
> 
> - However, in draft-ietf-capport-api, section 5: API State Structure, 
> only "captive" (boolean): is mandatory whereas "user-portal-url" 
> (string): is optional. One of these two drafts may need an update for 
> consistency.
> 
> *_ _*
> 
> *_Section 2.6 Component Diagram_*
> 
> Although the Provisioning Service, API Server, and Web Portal Server 
> functions are shown as discrete blocks, they could of course be 
> combined into a single element. – [Pending]
> 
> - Here may be we can add the [Captive Portal Enforcement] as well, for 
> eg: API Server, Web Portal Server and Enforcement can co-exist on a 
> single WiFi Access-Point using ACLs. Also there is a feeble reference 
> to this co-location in Section 3.4.1
> 
> 
> *_Section 3 Captive Portal Signal_*
> 
> Is Enforcement Device defined anywhere else? Is it same as Captive 
> Portal Enforcement(I guess so) Or does it coordinate with it? – 
> [Resolved, Please ignore]
> 
> 
> 
> *From: *Captive-portals <[email-masked]> on behalf of 
> Bob Harold <[email-masked]>
> *Date: *Monday, May 11, 2020 at 10:35 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, 
> "[email-masked]" 
> <[email-masked]>, "[email-masked]" 
> <[email-masked]>, IETF-Announce <[email-masked]>, 
> "[email-masked]" <[email-masked]>, Martin Thomson 
> <[email-masked]>
> *Subject: *Re: [Captive-portals] Last Call: 
> <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to 
> Informational RFC
> 
> 
> 
> > [email-masked] mailing lists by 2020-05-25. Exceptionally, comments may
> >  be sent to [email-masked] instead. In either case, please retain the beginning
> > https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ <https://secure-web.cisco.com/1yVzqJ3UqY3xwLQUGHinMzu-7twa12PiLIN7EN50B62FLD0cXno02n3f_Qw7DSpKpG96CA7TKBLzu9xzC6TVQejhSfGo-jrF8DNmSa3LVszDOuk89O1tF28heTpZxo-Zl4Kzk3DxQoD5Hc8fDnwaLz69x04aBTgzTGR2Tf9ZMouiJgl4PjT97QOV7tu7viXpNVyNfM-2molaELtIJWJd00DqIJTzR2Hap7yETyceSjQTihOQh7tPi056W8nOWCQ-MxwbxsGzR5V37Soo1SFiKSaR_KHKYhK_NLd4ys-MQ_bKZmZiS_YEiEQX_q0lLjmFgTrqjGvQxzlOj0gwI4zthZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F>
> > 
> > 
> > 
> > https://www.ietf.org/mailman/listinfo/captive-portals <https://secure-web.cisco.com/1luUyQqfEnnX25r5RvmYXc4O6JMe744dFK_VSJQto5cvtJVqN7Y0Ie7SkRZBkDnAUWnL8L3b4ifd7pTzCT-EsrZmZhOLnLmd_gJDefmDNmw8a8wnbkHiR12asEIcSP9COhQWmnSY75DStoZ7N9Bidi67LQuNxiFexwf8r9J6F6QHrpMpgDgnqiyNKBaJcIC6GmF8UsF3j95f2eFjpdr_0ttHQuXj_XrxTJebBxaS3EdYg8OZsH713lH0DH-VYJ0a_IXiATDxiGaA7gvKppncYKLUo1Pi-xZ7HgL6prLTkzjLEwRFRGlYdkwrDLKV6zUZcbT23_4lyApm-XMaOQo4KZEFyQOebJB-U33Nrqn2nO7w/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals>
>

---

From: "Tirupachur Comerica, Subash" <[email-masked]>
Date: Mon, 11 May 2020 23:20:37 +0000

Thanks Martin for raising the issues on git for tracking.

Thanks,
Subash

From: Martin Thomson <[email-masked]>
Date: Monday, May 11, 2020 at 3:46 PM
To: "Tirupachur Comerica, Subash" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Captive-portals] Last Call: <draft-ietf-capport-architecture-08.txt> (CAPPORT Architecture) to Informational RFC

Editors, I've opened a few issues on the comments Subash indicated were still pending. I think that we can take these as last call comments in the usual fashion. I don't see a pressing reason to upda
External ([email-masked]<mailto:[email-masked]>)
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL3N1YmFzaC50aXJ1cGFjaHVyY29tZXJpY2FAY29tbXNjb3BlLmNvbS81ODQyZDA2YjU2YWIyZmZhZTU1Y2U0NDJmMzNjMWIwYi8xNTg5MjM3MjE1Ljky#key=2b97418ab930d7396312bfa062d59323>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

Editors,

On Tue, May 12, 2020, at 03:50, Tirupachur Comerica, Subash wrote:

> > https://secure-web.cisco.com/15YygQHy-oelEGxcEL3bc0yBY6TF-VHfruXSf6FPzYwSgtjpWCr1CgRye3VNWf1t9h-rWjEyoiCxycEbzgM4E2NX6heccQhCGsh8UpqqgGoYguA10Fyv5zEaaY80-zR3SK6eFYcDZpb4FE7D-PjMtnB0PdF7JJeg-ehHQj3Bg-GVchuCNAJdJ_hgIDlcJUdmg5RokTl4EJSydiSNpHG6yfIuuR-hpfrPa64iMiOQDnAkCqg5GG092jgTsF6_hADsUFyvYISWUz7juEs-lovsptJ8dtWW2Y4IOMt5V9P6ltN99kIu9BbuE8DkobpGjYdizEJnK5BVTJB8KL9zjHNwjSg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F <https://secure-web.cisco.com/1yVzqJ3UqY3xwLQUGHinMzu-7twa12PiLIN7EN50B62FLD0cXno02n3f_Qw7DSpKpG96CA7TKBLzu9xzC6TVQejhSfGo-jrF8DNmSa3LVszDOuk89O1tF28heTpZxo-Zl4Kzk3DxQoD5Hc8fDnwaLz69x04aBTgzTGR2Tf9ZMouiJgl4PjT97QOV7tu7viXpNVyNfM-2molaELtIJWJd00DqIJTzR2Hap7yETyceSjQTihOQh7tPi056W8nOWCQ-MxwbxsGzR5V37Soo1SFiKSaR_KHKYhK_NLd4ys-MQ_bKZmZiS_YEiEQX_q0lLjmFgTrqjGvQxzlOj0gwI4zthZQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-capport-architecture%2F>

> > https://secure-web.cisco.com/19JFZdBEW3HbgyKwfA6173s7J4a8zv5vvOztdE6iJlssKD4bNLfbi87gxYkoUIM_JpR112JGLqAnoNvRQTPm_lFpjezWRmZbHWUG2W4a1rVp9pRqnmS3asoPidUlFdVnuWBehpP4bld0n-HIRQ3QKvS4L_oZEyJHQp3WjrtEhnSd9bGg65vt5vBwfsjUY1G5Ji_n7wK_ro1WD5v0G4jJdoOdjcCqgTQmAjwW0BVJLHSuBeb_2W7SCvM7_0jjZKOJu7zXXoEPGvYKjk288nQ0ipH4jU8xcvSLA_QX1BO6tAqbnL3btzMXt8UkZKuTEjAnlK73wIBUdJyacSwj5W-IUumL5GKDz-I66wHZKHqTV0ZM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals <https://secure-web.cisco.com/1luUyQqfEnnX25r5RvmYXc4O6JMe744dFK_VSJQto5cvtJVqN7Y0Ie7SkRZBkDnAUWnL8L3b4ifd7pTzCT-EsrZmZhOLnLmd_gJDefmDNmw8a8wnbkHiR12asEIcSP9COhQWmnSY75DStoZ7N9Bidi67LQuNxiFexwf8r9J6F6QHrpMpgDgnqiyNKBaJcIC6GmF8UsF3j95f2eFjpdr_0ttHQuXj_XrxTJebBxaS3EdYg8OZsH713lH0DH-VYJ0a_IXiATDxiGaA7gvKppncYKLUo1Pi-xZ7HgL6prLTkzjLEwRFRGlYdkwrDLKV6zUZcbT23_4lyApm-XMaOQo4KZEFyQOebJB-U33Nrqn2nO7w/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals>

> https://secure-web.cisco.com/19JFZdBEW3HbgyKwfA6173s7J4a8zv5vvOztdE6iJlssKD4bNLfbi87gxYkoUIM_JpR112JGLqAnoNvRQTPm_lFpjezWRmZbHWUG2W4a1rVp9pRqnmS3asoPidUlFdVnuWBehpP4bld0n-HIRQ3QKvS4L_oZEyJHQp3WjrtEhnSd9bGg65vt5vBwfsjUY1G5Ji_n7wK_ro1WD5v0G4jJdoOdjcCqgTQmAjwW0BVJLHSuBeb_2W7SCvM7_0jjZKOJu7zXXoEPGvYKjk288nQ0ipH4jU8xcvSLA_QX1BO6tAqbnL3btzMXt8UkZKuTEjAnlK73wIBUdJyacSwj5W-IUumL5GKDz-I66wHZKHqTV0ZM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcaptive-portals

---

From: Kyle Larose <[email-masked]>
Date: Tue, 12 May 2020 08:09:52 -0400

Hi Bob,

Thanks for the quick feedback.

> I am curious why section 3.4 does not consider the MAC Address as a possible identifier?

Its omission doesn't mean that the MAC Address is not a valid
identifier. One should evaluate it using the criteria provided in 3.2
and 3.3. When I wrote the skeleton of this section, I left the MAC
Address out more to keep the section short than anything, though I did
consider adding it.

Bob, do you think the MAC address needs to be considered in this
section for completeness?

How does the capport wg feel as a whole about this question?

Thanks,

Kyle

---

From: Bob Harold <[email-masked]>
Date: Tue, 12 May 2020 08:32:34 -0400

> section for completeness?

I won't argue too much if you decide to leave it out, but it seems like the
most obvious identifier, and is used by many things, so it would be good to
list its pros and cons.

> How does the capport wg feel as a whole about this question?

I am also wondering the same thing.

Thanks,