Kerberos Options for DHCPv6
draft-sakane-dhc-dhcpv6-kdc-option-18

Would you mind rewriting the Abstract for clarity? Something like...

   This document defines four new options for the Dynamic Host 
   Configuration Protocol for IPv6 (DHCPv6).  These options are used to
   carry coniguration information for Kerberos.

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- Section 4 --
I find the use of 2119 language a bit odd in the second and third paragraphs.  You use MUST for what the client sends to the server, and you don't use 2119 language for how the server responds.  In fact, I think it would be fine to strike the MUSTs from the client side too.  For example, this works fine for the third paragraph:

   If a client requires configuration parameters for a KDC, the client
   sends a DHCPv6 ORO specifying the Kerberos KDC Option.  The
   client MAY include a Kerberos Principal Name Option.  The client
   MAY include a Kerberos Realm Name Option.

That makes it parallel to the protocol instructions for the server.

I also find the MUST in the fifth paragraph to be odd, but it matches the 2119 language in RFC 2782, so I can't really pick any bones with it.

The MUST in Section 4.1 is stranger still:
   The
   administrator of the realm MUST define the method as part of the
   configuration of the client before the client is installed.

I don't know how that qualifies as a MUST, how it has anything to do with interoperability, nor how it could be detected or enforced.  Wouldn't it be suitable to just say that "the administrator of the realm usually defines the method [...]" ?

-- IANA Considerations --
   The assignment of future entries is by "IETF Consensus" policy as
   described in BCP 26 [RFC5226].

In RFC 5226 this is called "IETF Review", not "IETF Consensus"; please change that.

[updated, as the IANA part takes care all of stuff to be registered.]

Please reply to these comments, as they are substantial for the document:

Section 3., paragraph 7:

>    With the exception of the Kerberos KDC Option, none of these options
>    may appear more than once in a DHCPv6 message.

  Shouldn't this read 'MUST NOT appear'?


Appendix B., paragraph 1:

>    When no criteria have been specified and the client could get the
>    Kerberos information from either the DNS server or the DHCPv6 server,
>    then the information from DNS should be preferred.  The following is
>    the guideline for the client in such an environment.

  This appendix is not meant to be the standard, but rather
  informational, isn't it? If it is this way, please state it
  explicitly!

I agree with Barry's concerns. Please address them.

Updated based on email exchange with Sam.

1) a: r/defines new four/defines four new

2) s2: If you going to have the following:

 It is assumed that the readers are familiar with the terms and
 concepts described in DHCPv6 [RFC3315].

You might as well throw in [RFC2782], [RFC3315], and [RFC4120] ;)

3) s3: r/DHCP configuration parameters/DHCPv6 configuration parameters 

4) s3.3: You need to leave a marker for IANA to fill for the number it assigns:

OLD:

The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME.

NEW:

The option-code of this option is OPTION_KRB_DEFAULT_REALM_NAME (TBD by IANA).

5) s3.4: should DTLS be in the list?

6) s3.4: r/realm- name/realm-name

7) app a: It's unclear to me why you need this appendix.  The reason is clearly stated in s1.


If the app a remains:

8) app a, s1: It's probably be better to say:

  This appendix gives reasons why DHCP-based KDC discovery
  *can be* more appropriate for industrial systems
  than DNS-based KDC discovery (as described
  in RFC4120 - the "RFC4120-way").

I'm suggesting this because I'm not entirely sure it always "is" better to use DHCP over DNS in an industrial system.

and:

  *Some* Industrial systems have their own name spaces and
  naming systems which are not based on FQDN and DNS.

Do they all have their own?

9) app a, s1: What kind of server are we getting rid of if we're using DHCP-based KDC discovery over DNS-based discovery.

  DHCP-based KDC discovery is more efficient because
  reducing the number of servers reduces the number of
  messages, improves reliability and reduces management cost.

Also the above seems a bit lit marketing to me.

10) app a, s2 & s3: Not sure why these paragraphs are here.  The heart of matter is in s4 - fielded devices don't support FQDN/DNS hence you need a DHCP mechanism.  You're goal is to not replace all the currently fielded devices because it's too darn expensive.

In s2 it might be worth making the following change before the bullets:

  Field devices currently deployed where DHCP-based KDC discovery can be more
  appropriate than DNS-based KDC discovery have the following
  characteristics:

In s3: Why is this paragraph needed at all.  It doesn't fit under the heading of "Why DNS is not acceptable in some environments".  Seems like marketing to me.

11) app a, s5: How are less servers being implemented?

12) app a, s6: There's a whole 'lotta references in Appendix A that need to be added in s8.2.