Re: [Captive-portals] Captive-Portal Identification in DHCP / RA draft-ietf-capport-rfc7710bis-03

[Martin Thomson <[e-mail]>]

Thanks for the input.  Apparently great minds think alike as another reviewer found the exact same shortcoming just days ago.  The next revision should have these fixed.

On Tue, Apr 28, 2020, at 05:07, Tirupachur Comerica, Subash wrote:
>  
> Hi,
> 
> I was reviewing this draft and found a few missing text(sometimes 
> obvious) enumerated below(missing text in *_bold underline_*)
> 
> Section 2.1 IPv4 DHCP Option
> 
>  o Code: The Captive-Portal DHCPv4 option (TBD) (one octet).
> 
>  o Len: The length, in octets of the URI.*_(one octet)_*
> 
> Section 2.2: IPv6 DHCP Option
> 
>  o option-code: The Captive-Portal DHCPv6 option (103) (two octets).
> 
>  o option-len: The length, in octets of the URI.*_(two octets) --? 
> Please see question below_*
> 
>  o URI: The contact URI for the captive portal that the user should
> 
>  connect to (encoded following the rules in [RFC3986 
> <https://tools.ietf.org/html/rfc3986>]).
> 
> 
> - *Question on the above option-len: If this is two octets in IPv6 DHCP 
> option, then the URI can be longer then 255. Option-len-value <=255, 
> correct?*
> 
> 
> Section 2.3: The Captive-Portal IPv6 RA Option
> 
>  o Type: 37*_(one octet)_*
> 
>  o Length: 8-bit unsigned integer. The length of the option
> 
>  (including the Type and Length fields) in units of 8 bytes.(*_one octet_*)
> 
>  o URI: The contact URI for the captive portal that the user should
> 
>  connect to. For the reasons described above, the implementer
> 
>  might want to use an IP address literal instead of a DNS name.
> 
>  This should be padded with NULL (0x0) to make the total option
> 
>  length (including the Type and Length fields) a multiple of 8
> 
>  bytes.
> 
> 
> Thanks,
> 
> Subash
> 
> 
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>