Re: RA extension review requested for draft-wkumari-dhc-capport

[Ted Lemon <[e-mail]>]

On Mar 16, 2015, at 8:41 PM, Mark ZZZ Smith <[e-mail]> wrote:
> I raised the same issue with multiple interfaces in my doc shepherd review, and the new version addresses that point; I'd be curious to know if you have additional text to suggest, or if you are satisfied with the changes.
> 
> 
> / That wasn't obvious to me, and I find that the abstract and introduction, which set the context for the rest of the document, implied to me that the device was single homed by using the term "behind" (I'd even interpret that a multihomed device being described as "behind" a captive portal means that all of its interfaces are downstream of the captive portal).

Can you suggest a clarification that makes sense to you?

> 
>> o the protocol being used for the reachability status and Captive Portal is HTTP (hence supplying a URI)
> 
> URIs are not http-only, although I tend to agree that http is the likely transport.
> 
> / My first concern was that encoding URIs in RAs means that this option could be pretty large.

OK.   The RA I'm getting from Comcast at the moment is 96 bytes, so I think there's enough headroom to accommodate a short captive portal URI.   Maybe you could explain how this is going to be a problem in practice?   Remember that we're talking specifically about the captive portal use case, so it's not the case that this is going to be a network with a large number of prefixes or that is going to offer a long domain name search list.

> / I'm also of the view that RAs should only contain subnet specific network layer configuration information, as I described in section 2, "Internet Transparency and Application Configuration" of "IPv6 CE Device DHCPv6 Option Transparency" (https://tools.ietf.org/html/draft-smith-v6ops-ce-dhcpv6-transparency-00#section-2). I think describing a limited network reachability prefix via RA options to a host, and then letting the host decide what to do with that information is consistent with using RAs to describe subnet specific network layer configuration information.
> 
> / More basically, I think encoding application or application class parameters in RAs is a layer violation.
> / I think DHCPv6 is a better place for larger options that are application specific or application-class specific (i.e., layer 4+ options), such as URIs.

I don't think you are making a meaningful distinction.   Both DHCP and ND are layer 7 protocols, and ND provides configuration information such as DNS server IP addresses and domain name search lists, to which your objection would also apply.   So we are not treading new ground here, as far as I can tell.   And the information being provided is specific to the link to which the host is attached.

>> o that the receiving device provides a quite capable interactive user interface where text/numbers can be entered (e.g., computer screen/a web browser). 
> 
> I think the answer here is that the receiving device will likely only be able to authenticate to the captive portal if it has a UI or else if some new mechanism is provided that supports automatic authentication.   However, the target for this particular document is devices with user interfaces, not IoT devices, so I think within that realm we are okay.   Perhaps the document should be clearer on this point.
> 
> I think that the amount of work that would be required to define a mechanism for automatic authentication is really substantial, and would have limited value: we don't even know if captive portal folks will implement this very simple mechanism.   So I think that should be out of scope for this document.   The presence of the URI option already indicates that a captive portal is present, so IoT devices that recognize this option can avoid using the captive interface.
> 
> / It seems to me that solutions to problems should be made as general as possible. In this case, I think there are really two problems (a) indicating to a device that one of its interfaces has limited reachability (which may be its only external interface) and (b) indicating to the device operator that their is limited reachability and possibly providing methods of resolving that if desired. They seem to me to be separate problems that are occurring at different layers in the stack.

I think that if you want to propose a solution to the larger problem, that's great, but you haven't proposed a competing solution.   The problem this document addresses causes serious operational issues that have nothing to do with, e.g., IoT devices.   E.g., my mom is in a nursing home undergoing rehab for a knee operation right now, and every time she has to authenticate to their captive portal, she has to click through several warnings in her browser because the captive portal has to lie to capture her browser.   This proposal eliminates that problem.   This is a big deal.

So while you certainly have a point that there is a larger problem to solve here, given that no proposal to solve it has, as yet, surfaced, I don't think you've actually given a reason why we shouldn't proceed with address the more restricted use case that we actually can address.

So the main action item I'm taking away from this review, with respect specifically to Warren's document, is that we should tweak the abstract to be more clear.   If you have text to suggest that would be great.   Otherwise I'll confer with Warren and see if we can come up with something.   Thanks very much for the thorough review!