Subject: Re: [dhcwg] [Ietf-krb-wg] WG Last Call: draft-sakane-dhc-dhcpv6-kdc-option-08

From: "Jeffrey Hutzelman" <[email-masked]>
Date: 06 Apr 2010 08:10:00 -0400

>1-1: Expand "DHCP"
>
>  Jeff>
>    Expand "DHCP"
>
>  Shoichi>
>    I am not sure whether it is better that the Kerberos option for both DHCPv4
>    and DHCPv6 are described in a single document.  Yes, I understand most
>    description including the introduction, the behavior of client and server,
>    are same.  But, the format of the payload is different.
>    I would like to ask to member of the group what we can do.

You misunderstand.  I'm talking about an editorial change, not a substantive one.  Acronyms such as "DHCP" must be fully expanded on first use, so that the document is readable to readers unfamiliar with the abbreviations.  So, the first time you mention DHCP, write "Dynamic Host Configuration Protocol (DHCP)" instead of just "DHCP".

>1-2: prividing an IPv4 address. section 2.2 (KDC Sub-Option)
>
>  Jeff>
>    > It is not recommended to provide an IPv4 address.
>
>    Since most Kerberos deployments are currently IPv4-only, I'm not
>    convinced this advice is appropriate.  If we believe as a WG that
>    this is appropriate, then the phrase "not recommended" should be
>    elevated to RFC2119 requirements language (i.e. uppercase), and
>    this requirement should be stated separately, rather than as an
>    aside to the description of the sub-option length.
>
>  Shoichi>
>    If my understanding is correct, it was the consensus of the krb-wg
>    meeting in Stockholm.

I will have to look into this.

>    I wanted such suggestion.  I will add a field of the address family.
>    When the field is added, the sub-option will have a 3-octet reserved
>    field since the family number is 16-bit long.  Do we accept it ?

That doesn't have to be the case.  You can reorder the fields so that all of the 16-bit fields are together:  priority, weight, AF, port, then the 8-bit transport type, then the variable-sized addresses.  Or, you could give up on the idea that bits on the wire need to be word-aligned; I'm not sure what DHC thinks of that.

>    To avoid it, another option would be that we can shorten the number
>    to 8-bit from 16-bit.  But, it is backward.

If you do that, it's too small for the size of the registry.

--Jeff

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 07 Apr 2010 17:37:25 +0900

Jeff,

> You misunderstand.  I'm talking about an editorial change, not a substantive one.  Acronyms such as "DHCP" must be fully expanded on first use, so that the document is readable to readers unfamilia…

Thanks for the clarification.  All right.  I will fix it.

>>    field since the family number is 16-bit long.  Do we accept it ?

I found a definition in section 6 of RFC 3315:

  6. Client/Server Message Formats

  Options are stored serially in the options field, with no padding
  between the options.  Options are byte-aligned but are not aligned in
  any other way such as on 2 or 4 byte boundaries.

So, I am going to take your suggestion.  The message format will be:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         SUB_OPTION_KDC        |          sub-opt-len          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           Priority            |            Weight             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Address Family       |          Port Number          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Transport Type|                                               |
  +-+-+-+-+-+-+-+-+                                               +
  :                       KDC address (variable)                  :
  :                                                               :
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Shoichi Sakane