Re: [Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
Dave Your suggestion is good for me -éric -Original Message- From: David Dolson Reply-To: "ddol...@acm.org" Date: Monday, 15 June 2020 at 04:32 To: Eric Vyncke Cc: Kyle Larose , The IESG , "draft-ietf-capport-architect...@ietf.org" , "capport-cha...@ietf.org" , captive-portals , Martin Thomson Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT) One comment from me regarding this exchange: > > Typically User Equipment is permitted access to a small > number of > > services and is > > denied general network access until it satisfies the > Captive Portal > > Conditions. > > > > Perhaps we could add some language indicating that this isn't > intended > > to be a normative requirement -- the restrictions placed by > the > > captive portal depend on its use-case. > EV> you may add "(.g., local communication)" after "small number of services" ? KL> Thanks for the suggestion! We'll clarify along those lines. I don't think "local", implying physical proximity, is the correct word. There are multiple technologies for serving DHCP, DNS, user portal, API, etc. from *remote* machines. I feel that adding "e.g., local communication" would add more confusion than clarity. How about, "... permitted access to a small number of services (according to the policies of the network provider) and is denied general network access..." -Dave On 2020-06-14 11:30, Eric Vyncke (evyncke) wrote: > Thank you Kyle, I appreciate your answer and your comments. > > Good to go ;-) > > -éric > > -Original Message- > From: Kyle Larose > Date: Sunday, 14 June 2020 at 17:07 > To: Eric Vyncke > Cc: The IESG , > "draft-ietf-capport-architect...@ietf.org" > , "capport-cha...@ietf.org" > , captive-portals , > Martin Thomson > Subject: Re: Éric Vyncke's No Objection on > draft-ietf-capport-architecture-08: (with COMMENT) > > Thanks again, Eric. > > Resposnes inline. I'll take the same approach as you did, with KL> > > On Tue, 9 Jun 2020 at 17:33, Eric Vyncke (evyncke) > wrote: > > > > Hello Kyle > > > > Thank you for the prompt reply, look for EV> for any remaining > non-blocking comments of mine > > > > -eric > > > > -Original Message- > > From: Kyle Larose > > Date: Tuesday, 9 June 2020 at 14:43 > > To: Eric Vyncke > > Cc: The IESG , > "draft-ietf-capport-architect...@ietf.org" > , "capport-cha...@ietf.org" > , captive-portals , > Martin Thomson > > Subject: Re: Éric Vyncke's No Objection on > draft-ietf-capport-architecture-08: (with COMMENT) > > > > Hi Éric, > > > > Thanks for the review! > > > > Responses inline. > > > > On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker > > wrote: > > > > > > Éric Vyncke has entered the following ballot position for > > > draft-ietf-capport-architecture-08: No Objection > > > > > > > > > -- > > > COMMENT: > > > > -- > > > > > > Thank you for the work put into this document. The > document is easy to read. I > > > also appreciate the fact that "devices without user > interfaces" are not ignored > > > by this document. > > > > > > Please find below a couple on non-blocking COMMENTs. A > response/comment for > > > those COMMENT will be read with interest. > > > > > > I hope that this helps to improve the document, > > > > > > Regards, > > > > > > -éric > > > > > > == COMMENTS == > > > > > > Is there a reason why the words "captive portal" do not > appear in the abstract? > > > This would assist normal human beings (outside of the WG) > to find the document. > > > > > > > Good point! We'll fix that up. > > > > > I found no text about what happens to the traffic inside > the captive network. > > > Is it allowed even when still in captive mode ? > > > > This would be up to the network operator, I suppose -- they > define the > > extent of the walled garden. The only hosts that must be > reachable are > > any necessary
Re: [Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
One comment from me regarding this exchange: > Typically User Equipment is permitted access to a small number of > services and is > denied general network access until it satisfies the Captive Portal > Conditions. > > Perhaps we could add some language indicating that this isn't intended > to be a normative requirement -- the restrictions placed by the > captive portal depend on its use-case. > EV> you may add "(.g., local communication)" after "small number of services" ? KL> Thanks for the suggestion! We'll clarify along those lines. I don't think "local", implying physical proximity, is the correct word. There are multiple technologies for serving DHCP, DNS, user portal, API, etc. from *remote* machines. I feel that adding "e.g., local communication" would add more confusion than clarity. How about, "... permitted access to a small number of services (according to the policies of the network provider) and is denied general network access..." -Dave On 2020-06-14 11:30, Eric Vyncke (evyncke) wrote: Thank you Kyle, I appreciate your answer and your comments. Good to go ;-) -éric -Original Message- From: Kyle Larose Date: Sunday, 14 June 2020 at 17:07 To: Eric Vyncke Cc: The IESG , "draft-ietf-capport-architect...@ietf.org" , "capport-cha...@ietf.org" , captive-portals , Martin Thomson Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT) Thanks again, Eric. Resposnes inline. I'll take the same approach as you did, with KL> On Tue, 9 Jun 2020 at 17:33, Eric Vyncke (evyncke) wrote: > > Hello Kyle > > Thank you for the prompt reply, look for EV> for any remaining non-blocking comments of mine > > -eric > > -Original Message- > From: Kyle Larose > Date: Tuesday, 9 June 2020 at 14:43 > To: Eric Vyncke > Cc: The IESG , "draft-ietf-capport-architect...@ietf.org" , "capport-cha...@ietf.org" , captive-portals , Martin Thomson > Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT) > > Hi Éric, > > Thanks for the review! > > Responses inline. > > On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker > wrote: > > > > Éric Vyncke has entered the following ballot position for > > draft-ietf-capport-architecture-08: No Objection > > > > > -- > > COMMENT: > > -- > > > > Thank you for the work put into this document. The document is easy to read. I > > also appreciate the fact that "devices without user interfaces" are not ignored > > by this document. > > > > Please find below a couple on non-blocking COMMENTs. A response/comment for > > those COMMENT will be read with interest. > > > > I hope that this helps to improve the document, > > > > Regards, > > > > -éric > > > > == COMMENTS == > > > > Is there a reason why the words "captive portal" do not appear in the abstract? > > This would assist normal human beings (outside of the WG) to find the document. > > > > Good point! We'll fix that up. > > > I found no text about what happens to the traffic inside the captive network. > > Is it allowed even when still in captive mode ? > > This would be up to the network operator, I suppose -- they define the > extent of the walled garden. The only hosts that must be reachable are > any necessary to perform the workflows related to gaining access. The > document mentions those in a few places. In section 2.4, the document > states: > > Typically User Equipment is permitted access to a small number of > services and is > denied general network access until it satisfies the Captive Portal > Conditions. > > Perhaps we could add some language indicating that this isn't intended > to be a normative requirement -- the restrictions placed by the > captive portal depend on its use-case. > > EV> you may add "(.g., local communication)" after "small number of services" ? KL> Thanks for the suggestion! We'll clarify along those lines. > > > > -- Section 1.2 -- > > Even if the document support "devices without user interfaces", I wonder why > > the I-D uses "User Equipment" rather than "Client Equipment" (which is also > > more aligned with "Server"). Nothing dramatic, just curious about the reason. > > > > This is the language that evolved during our
Re: [Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
Thank you Kyle, I appreciate your answer and your comments. Good to go ;-) -éric -Original Message- From: Kyle Larose Date: Sunday, 14 June 2020 at 17:07 To: Eric Vyncke Cc: The IESG , "draft-ietf-capport-architect...@ietf.org" , "capport-cha...@ietf.org" , captive-portals , Martin Thomson Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT) Thanks again, Eric. Resposnes inline. I'll take the same approach as you did, with KL> On Tue, 9 Jun 2020 at 17:33, Eric Vyncke (evyncke) wrote: > > Hello Kyle > > Thank you for the prompt reply, look for EV> for any remaining non-blocking comments of mine > > -eric > > -Original Message- > From: Kyle Larose > Date: Tuesday, 9 June 2020 at 14:43 > To: Eric Vyncke > Cc: The IESG , "draft-ietf-capport-architect...@ietf.org" , "capport-cha...@ietf.org" , captive-portals , Martin Thomson > Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT) > > Hi Éric, > > Thanks for the review! > > Responses inline. > > On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker > wrote: > > > > Éric Vyncke has entered the following ballot position for > > draft-ietf-capport-architecture-08: No Objection > > > > > -- > > COMMENT: > > -- > > > > Thank you for the work put into this document. The document is easy to read. I > > also appreciate the fact that "devices without user interfaces" are not ignored > > by this document. > > > > Please find below a couple on non-blocking COMMENTs. A response/comment for > > those COMMENT will be read with interest. > > > > I hope that this helps to improve the document, > > > > Regards, > > > > -éric > > > > == COMMENTS == > > > > Is there a reason why the words "captive portal" do not appear in the abstract? > > This would assist normal human beings (outside of the WG) to find the document. > > > > Good point! We'll fix that up. > > > I found no text about what happens to the traffic inside the captive network. > > Is it allowed even when still in captive mode ? > > This would be up to the network operator, I suppose -- they define the > extent of the walled garden. The only hosts that must be reachable are > any necessary to perform the workflows related to gaining access. The > document mentions those in a few places. In section 2.4, the document > states: > > Typically User Equipment is permitted access to a small number of > services and is > denied general network access until it satisfies the Captive Portal > Conditions. > > Perhaps we could add some language indicating that this isn't intended > to be a normative requirement -- the restrictions placed by the > captive portal depend on its use-case. > > EV> you may add "(.g., local communication)" after "small number of services" ? KL> Thanks for the suggestion! We'll clarify along those lines. > > > > -- Section 1.2 -- > > Even if the document support "devices without user interfaces", I wonder why > > the I-D uses "User Equipment" rather than "Client Equipment" (which is also > > more aligned with "Server"). Nothing dramatic, just curious about the reason. > > > > This is the language that evolved during our discussions. I can't > recall any particular reason we chose this. > > Does anyone with a better memory than me remember why we chose User > Equipment over Client Equipment? > > EV> nothing critical and possibly impacting too many other documents to be changed now > > > -- Section 2.1 -- > > "At this time we consider only devices with web browsers" while the previous > > text was about "devices without user interfaces". Finally, is this document for > > devices with or without human interface ? > > When we first set out to tackle the architecture, we were hoping to > solve the problem for devices without user interfaces. However, the > working group aligned on solving it for the simpler use-case of > devices with user interfaces. > > To ensure we're talking about the same thing, the earlier text you're > referring to is this, correct? > > EV> correct > > -- Section 1 -- > >A side-benefit of the architecture described in
Re: [Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
Thanks again, Eric. Resposnes inline. I'll take the same approach as you did, with KL> On Tue, 9 Jun 2020 at 17:33, Eric Vyncke (evyncke) wrote: > > Hello Kyle > > Thank you for the prompt reply, look for EV> for any remaining non-blocking > comments of mine > > -eric > > -Original Message- > From: Kyle Larose > Date: Tuesday, 9 June 2020 at 14:43 > To: Eric Vyncke > Cc: The IESG , "draft-ietf-capport-architect...@ietf.org" > , "capport-cha...@ietf.org" > , captive-portals , Martin > Thomson > Subject: Re: Éric Vyncke's No Objection on > draft-ietf-capport-architecture-08: (with COMMENT) > > Hi Éric, > > Thanks for the review! > > Responses inline. > > On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker > wrote: > > > > Éric Vyncke has entered the following ballot position for > > draft-ietf-capport-architecture-08: No Objection > > > > > -- > > COMMENT: > > -- > > > > Thank you for the work put into this document. The document is easy to > read. I > > also appreciate the fact that "devices without user interfaces" are not > ignored > > by this document. > > > > Please find below a couple on non-blocking COMMENTs. A response/comment > for > > those COMMENT will be read with interest. > > > > I hope that this helps to improve the document, > > > > Regards, > > > > -éric > > > > == COMMENTS == > > > > Is there a reason why the words "captive portal" do not appear in the > abstract? > > This would assist normal human beings (outside of the WG) to find the > document. > > > > Good point! We'll fix that up. > > > I found no text about what happens to the traffic inside the captive > network. > > Is it allowed even when still in captive mode ? > > This would be up to the network operator, I suppose -- they define the > extent of the walled garden. The only hosts that must be reachable are > any necessary to perform the workflows related to gaining access. The > document mentions those in a few places. In section 2.4, the document > states: > > Typically User Equipment is permitted access to a small number of > services and is > denied general network access until it satisfies the Captive Portal > Conditions. > > Perhaps we could add some language indicating that this isn't intended > to be a normative requirement -- the restrictions placed by the > captive portal depend on its use-case. > > EV> you may add "(.g., local communication)" after "small number of services" > ? KL> Thanks for the suggestion! We'll clarify along those lines. > > > > -- Section 1.2 -- > > Even if the document support "devices without user interfaces", I > wonder why > > the I-D uses "User Equipment" rather than "Client Equipment" (which is > also > > more aligned with "Server"). Nothing dramatic, just curious about the > reason. > > > > This is the language that evolved during our discussions. I can't > recall any particular reason we chose this. > > Does anyone with a better memory than me remember why we chose User > Equipment over Client Equipment? > > EV> nothing critical and possibly impacting too many other documents to be > changed now > > > -- Section 2.1 -- > > "At this time we consider only devices with web browsers" while the > previous > > text was about "devices without user interfaces". Finally, is this > document for > > devices with or without human interface ? > > When we first set out to tackle the architecture, we were hoping to > solve the problem for devices without user interfaces. However, the > working group aligned on solving it for the simpler use-case of > devices with user interfaces. > > To ensure we're talking about the same thing, the earlier text you're > referring to is this, correct? > > EV> correct > > -- Section 1 -- > >A side-benefit of the architecture described in this document is that >devices without user interfaces are able to identify parameters of >captivity. However, this document does not yet describe a mechanism >for such devices to escape captivity. > > Our intent was to point out that solutions for devices without user > interfaces could be developed using the mechanisms provided by the > architecture, but that those solutions were out of scope for the > document. > > Which text do you think conflicts with that? Perhaps we should > rephrase it to be less confusing. > > EV> I would suggest that at the first mention of " devices without user > interfaces", the text mention "for future version" or something in the same > line. The focus on user-interface devices is written a little too deep in
Re: [Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
Hello Kyle Thank you for the prompt reply, look for EV> for any remaining non-blocking comments of mine -eric -Original Message- From: Kyle Larose Date: Tuesday, 9 June 2020 at 14:43 To: Eric Vyncke Cc: The IESG , "draft-ietf-capport-architect...@ietf.org" , "capport-cha...@ietf.org" , captive-portals , Martin Thomson Subject: Re: Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT) Hi Éric, Thanks for the review! Responses inline. On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-capport-architecture-08: No Objection > > -- > COMMENT: > -- > > Thank you for the work put into this document. The document is easy to read. I > also appreciate the fact that "devices without user interfaces" are not ignored > by this document. > > Please find below a couple on non-blocking COMMENTs. A response/comment for > those COMMENT will be read with interest. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > Is there a reason why the words "captive portal" do not appear in the abstract? > This would assist normal human beings (outside of the WG) to find the document. > Good point! We'll fix that up. > I found no text about what happens to the traffic inside the captive network. > Is it allowed even when still in captive mode ? This would be up to the network operator, I suppose -- they define the extent of the walled garden. The only hosts that must be reachable are any necessary to perform the workflows related to gaining access. The document mentions those in a few places. In section 2.4, the document states: Typically User Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions. Perhaps we could add some language indicating that this isn't intended to be a normative requirement -- the restrictions placed by the captive portal depend on its use-case. EV> you may add "(.g., local communication)" after "small number of services" ? > > -- Section 1.2 -- > Even if the document support "devices without user interfaces", I wonder why > the I-D uses "User Equipment" rather than "Client Equipment" (which is also > more aligned with "Server"). Nothing dramatic, just curious about the reason. > This is the language that evolved during our discussions. I can't recall any particular reason we chose this. Does anyone with a better memory than me remember why we chose User Equipment over Client Equipment? EV> nothing critical and possibly impacting too many other documents to be changed now > -- Section 2.1 -- > "At this time we consider only devices with web browsers" while the previous > text was about "devices without user interfaces". Finally, is this document for > devices with or without human interface ? When we first set out to tackle the architecture, we were hoping to solve the problem for devices without user interfaces. However, the working group aligned on solving it for the simpler use-case of devices with user interfaces. To ensure we're talking about the same thing, the earlier text you're referring to is this, correct? EV> correct -- Section 1 -- A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of captivity. However, this document does not yet describe a mechanism for such devices to escape captivity. Our intent was to point out that solutions for devices without user interfaces could be developed using the mechanisms provided by the architecture, but that those solutions were out of scope for the document. Which text do you think conflicts with that? Perhaps we should rephrase it to be less confusing. EV> I would suggest that at the first mention of " devices without user interfaces", the text mention "for future version" or something in the same line. The focus on user-interface devices is written a little too deep in the document, should come earlier in the text to avoid confusion. > > -- Section 2.6 -- > While the components are described as being optional collocated, what about > resiliency ? I.e., having two different instances on one component. > That's a good point (and one I was thinking about the other day!) We should add some text pointing that out. Let's mention scale for good measure as well. > -- Section 3.4.2 --- >
Re: [Captive-portals] Éric Vyncke's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)
Hi Éric, Thanks for the review! Responses inline. On Mon, 8 Jun 2020 at 10:07, Éric Vyncke via Datatracker wrote: > > Éric Vyncke has entered the following ballot position for > draft-ietf-capport-architecture-08: No Objection > > -- > COMMENT: > -- > > Thank you for the work put into this document. The document is easy to read. I > also appreciate the fact that "devices without user interfaces" are not > ignored > by this document. > > Please find below a couple on non-blocking COMMENTs. A response/comment for > those COMMENT will be read with interest. > > I hope that this helps to improve the document, > > Regards, > > -éric > > == COMMENTS == > > Is there a reason why the words "captive portal" do not appear in the > abstract? > This would assist normal human beings (outside of the WG) to find the > document. > Good point! We'll fix that up. > I found no text about what happens to the traffic inside the captive network. > Is it allowed even when still in captive mode ? This would be up to the network operator, I suppose -- they define the extent of the walled garden. The only hosts that must be reachable are any necessary to perform the workflows related to gaining access. The document mentions those in a few places. In section 2.4, the document states: Typically User Equipment is permitted access to a small number of services and is denied general network access until it satisfies the Captive Portal Conditions. Perhaps we could add some language indicating that this isn't intended to be a normative requirement -- the restrictions placed by the captive portal depend on its use-case. > > -- Section 1.2 -- > Even if the document support "devices without user interfaces", I wonder why > the I-D uses "User Equipment" rather than "Client Equipment" (which is also > more aligned with "Server"). Nothing dramatic, just curious about the reason. > This is the language that evolved during our discussions. I can't recall any particular reason we chose this. Does anyone with a better memory than me remember why we chose User Equipment over Client Equipment? > -- Section 2.1 -- > "At this time we consider only devices with web browsers" while the previous > text was about "devices without user interfaces". Finally, is this document > for > devices with or without human interface ? When we first set out to tackle the architecture, we were hoping to solve the problem for devices without user interfaces. However, the working group aligned on solving it for the simpler use-case of devices with user interfaces. To ensure we're talking about the same thing, the earlier text you're referring to is this, correct? -- Section 1 -- A side-benefit of the architecture described in this document is that devices without user interfaces are able to identify parameters of captivity. However, this document does not yet describe a mechanism for such devices to escape captivity. Our intent was to point out that solutions for devices without user interfaces could be developed using the mechanisms provided by the architecture, but that those solutions were out of scope for the document. Which text do you think conflicts with that? Perhaps we should rephrase it to be less confusing. > > -- Section 2.6 -- > While the components are described as being optional collocated, what about > resiliency ? I.e., having two different instances on one component. > That's a good point (and one I was thinking about the other day!) We should add some text pointing that out. Let's mention scale for good measure as well. > -- Section 3.4.2 --- > While I appreciate that the section contains text about multiple IPv6 > addresses, I suggest to mention the dual-stack use case explicitly. > I.e. something like "Further attention should be paid to a device using dual-stack [rfc4213]: it could have both an IPv4 and an IPv6 address at the same time. There could be no properties in common between the two addresses, meaning that some form of mapping solution could be required to form a single identity from the two address" > -- Section 3.4 -- > I was expecting to see the MAC address also used as identifier. Is there any > reason why it is not mentioned? If so, may I suggest to document the absence > of > a MAC address section in the examples? > This was also raised during an earlier last call. The primary reason to leave it out was brevity, but there were some concerns about its security as well. Perhaps we can leave a simple note along the lines of the following since it is likely others will ask the same question: "The MAC address of a device is often used as an identity in existing implementations. A discussion of it has been omitted for brevity, but the MAC address could be used subject to the criteria in section 3.2" > > Thanks! Kyle
