Re: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi Bernie/All,

Thanks for all the reviews. We will work on a revision to address all the comments.

Regards
Sri


From: "Bernie Volz (volz)" <[e-mail]<mailto:[e-mail]>>
Date: Sunday, April 27, 2014 7:20 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014

(This are individual comments, with my co-chair hat off.)

In addition to the comments by Hidetoshi Yokota, which were very thorough, and those from Sheng, I have the following:

In Section 3, “SSID differentiates from one network to the other” is oddly worded … perhaps “SSID differentiates one network from another.”? It would also be good to have a hyphen or something separate the term from the definition?

In section 4 (Hidetoshi comment on this as well), what does the “if added by relay/client” mean? And for Option 82, this this would not be an option but a sub-option.

   code: 8-bit code carrying Access Network Identifier sub-options,

         If added by relay agent: Relay Agent Information Option (82)

         If added by client: OPTION_ACCESS_NETWORK_ID (TBD1)
The DHCPv4 option vs the DHCPv4 Relay Agent Suboption should be completely separate numbers (the number space is managed separately). So, you will need to request a v4 OPTION_ACCESS_NETWORK_ID and a v4 Relay agent suboption (from the “DHCP Relay Agent Sub-Option Codes” table), perhaps calling it “Access Network ID Suboption”. The suboption contained with the v4 option and v4 relay agent sub-options can have the same number space.

I think this was raised in the discussion, but is allowing a client to specify this information really a good idea? Having the relay supply this is fine and much more ‘secure’.

Also, I don’t see any text in the security considerations section (11) that raises issues about the trustworthiness of the client’s information. There’s a lot about rogue relays, but that is much more complex than the client just sending fake data. I think both the section 9 and 11 need text to recommend against using the client’s information or considering it untrustworthy and thus used with care, if you continue to believe it worth allowing the client to include it.

In section 6.3, the reference to DNS wire encoding/RFC 1035 should be changed to refer to RFC 3315, Section 8. This keeps definitions of what encoding to use for Domain Names centralized and clarifies that the compressed from is not to be used.

In section 8, that a relay may overwrite these values is a bit odd and non-standard. Also as the original values aren’t recoverable when the server responds (since the giaddr isn’t overwritten the response will go back to the first relay). I don’t believe we have any RFCs for multi-relays for v4, why would we want to ‘partially’ support this here for these options? I would remove this paragraph – if there is a future specification to support this, that would be what should be used.

Section 9, “If DHCP server is unable to understand these options it MUST be ignored”. It should be they? Also, this seems an odd statement as existing servers are supposed to do this anyway, and putting a requirement on existing servers doesn’t make any sense (as they can’t be changed). I think you should just drop this sentence.

Minor issues:

-          “For e.g.” is rather odd. Replace in Introduction with “For example”. “E.g.” means “for example”.

-          Also in introduction and Terminology sections, “Dynamic Host Configuration Protocol v4” (and also v6 case) should use “Dynamic Host Configuration Protocol for IPv4”.

-          Description misspelling in several places was already pointed out.

-          “indicating that its a Access-Network-Type sub-option” … I think you want “it’s” (as in it is). Perhaps best to use “it is”. This occurs in a few other places.

-          There are a few formatting issues (missing spaces after end of sentences, odd wrapping of text – no apparently good reasons for words to be on next line instead of one same line, and apparently odd page breaks).

-          There’s also a lot of minor wording issues.
The RFC-Editor would handle fix the above, but nice to provide IESG and others a better doc to start with.


Another revision of this document will be needed.

In general, once the WGLC issues are addressed, this document should be able to advance based on the option definitions, etc. (they adhere to the option guidelines). It is difficult for me to evaluate whether these options and related server processing are needed and how widely they would be implemented once available. The techniques a server uses for detecting ‘where’ a client has connected have worked fine to date, so why and how this additional information might be required is unclear to me. This mostly means section 2, Motivation, isn’t that ‘strong’ to me, but I’m also not an expert on proxy mobile IPv6.


-          Bernie

From: dhcwg [mailto:[e-mail]] On Behalf Of Bernie Volz (volz)
Sent: Saturday, April 12, 2014 10:04 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-access-network-identifier-02 - respond by April 27, 2014


Folks, the authors of draft-ietf-dhc-access-network-identifier (http://tools.ietf.org/html/draft-ietf-dhc-access-network-identifier-02)

feel it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published.



At the time of this writing, there is no IPR reported against this draft. Please see http://www.ietf.org/mail-archive/web/dhcwg/current/msg14143.html for a reminder regarding IPR disclosure requirements.



Tomek and I will evaluate consensus after April 27, 2014.



Thanks,

Bernie & Tomek