Re: [dhcwg] AD sponsoring - draft-wkumari-dhc-capport-07

[Ole Troan <[e-mail]>]

>> After some dicussion last year, I have agreed to sponsor
>> draft-wkumari-dhc-capport
>> (https://tools.ietf.org/html/draft-wkumari-dhc-capport-07). what I'm
>> looking for feeback on right now is feedback from potential
>> implementors, either of client implementations of captive portal
>> detection or captive portals as to:
>> 
>> * Whether or not this represents a reasonable optimization,
>> 
>> * Have we gotten the security considerations right?
>> 
>> * Would you use it if there was general consensus to the approach.
> 
> I haven't seen any responses to this.  I don't expect you'll see any "we would use this responses," and you shouldn't predicate this work on seeing any.   I think the idea is fine, although I think the requirement that the URI use an address literal is unnecessary.   If the implementor wants to do that, they can, or they can just only answer DNS queries for the local domain until the user authenticates.   They'd have to do that to support the redirect anyway.
> 
> I think the document has way too much explanatory text.   It's good that it's there for now so that people can understand the problem that this draft purports to solve, but it should not be in the final version.   Just explain how to use DHCP and ND to send this option (I think supporting it in ND is worthwhile, because DHCP isn't really very useful in an IPv6 hotspot environment).
> 
> It would be nice to talk about ways to authenticate this, e.g. PKI or DNSSEC certs.
> 
> I think you should run it by some people with HTTP fu to make sure that you haven't missed any obvious gaps, and of course run it by somebody with HTTP security fu to make sure there aren't any security flaws that need to be addressed.
> 
> I would not object to you AD-sponsoring this.   It's not in-charter for DHC, nor for 6man.   You should get it reviewed in both places, not just in DHC.
> 
> You may find section 5.7 of RFC 7227 useful: it would be good to make sure that your use of the DHCP URI option format meshes with what RFC 7227 does.   I didn't notice a problem, but didn't look all that carefully.

is this needed when you have 802.11u?

does it conflict or should it be integrated with the prefix properties in http://tools.ietf.org/html/draft-lepape-6man-prefix-metadata-00

what's this proposals relationship with MIF's PVDs?

cheers,
Ole