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: > > 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" <subash.tirupachurcomerica@xxxxxxxxxxxxx> > *Date: *Thursday, April 30, 2020 at 4:19 PM > *To: *"captive-portals@xxxxxxxx" <captive-portals@xxxxxxxx> > *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 <captive-portals-bounces@xxxxxxxx> on behalf of > Bob Harold <rharolde@xxxxxxxxx> > *Date: *Monday, May 11, 2020 at 10:35 AM > *To: *"last-call@xxxxxxxx" <last-call@xxxxxxxx> > *Cc: *"capport-chairs@xxxxxxxx" <capport-chairs@xxxxxxxx>, > "draft-ietf-capport-architecture@xxxxxxxx" > <draft-ietf-capport-architecture@xxxxxxxx>, "captive-portals@xxxxxxxx" > <captive-portals@xxxxxxxx>, IETF-Announce <ietf-announce@xxxxxxxx>, > "barryleiba@xxxxxxxxx" <barryleiba@xxxxxxxxx>, Martin Thomson > <mt@xxxxxxxxxxxxxx> > *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 > > > > On Mon, May 11, 2020 at 12:56 PM The IESG <iesg-secretary@xxxxxxxx> 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 > > last-call@xxxxxxxx mailing lists by 2020-05-25. Exceptionally, comments may > > be sent to iesg@xxxxxxxx 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/ <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> > > > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@xxxxxxxx > > 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> > > _______________________________________________ > Captive-portals mailing list > Captive-portals@xxxxxxxx > https://www.ietf.org/mailman/listinfo/captive-portals > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
