Subject: Re: RE: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call ondraft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

From: Heejin Jang <[email-masked]>
Date: Wed, 04 Jul 2007 13:23:27 +0000 (GMT)

Hi, Bernie.
Thanks for your opinion.

Please see the inline.

- Regards, 
Heejin  

------- Original Message -------
Sender : Bernie Volz (volz)<[email-masked]>
Date   : 2007-06-30 01:31
Title  : RE: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call ondraft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

Regarding
http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-05.txt, David
did an excellent and thorough review.

I too have many of the same issues as David.

1. Use of 16-bit suboptions in OPTION_MIP6-RELAY and OPTION_MIP6-HNINF.
Using 8-bit suboptions just complicates implementations that must
support this and packages that decode it. For DHCPv6, we really should
stick to use 16-bit TLV data *ALL THE WAY*. And, the cost of 2 more
bytes/suboption isn&#39;t a big deal.

But, perhaps these really aren&#39;t sub-option but instead radius encoded
attributes ("This option carries the RADIUS or Diameter attributes that
are received at the NAS from the AAAH.")? In that case, shouldn&#39;t the
sub-options description clearly indicate that and be radius-attributes
or something like that. It is CRITICAL to note that for radius
attributes, the L field in the TLV *includes* the L field (which is not
the case for DHCP options!).

But, then "3.2.1.  MIP6 Relay Agent Sub-option" lists these suboptions
which clearly are not the radius encode attributes.

Heejin>>  It  cannot be assumed that a mobile node or a DHCP server have 
ability to decode radius-encoded attributes. Then the radius-encoded attributes 
(received from AAA server) need to be re-formatted into dhcp options at a NAS
(=DHCP relay/Radius client) before delivering them to the mobile node.
Therefore, the proposed sub-options are not radius-encoded attributes but 
dhcp sub-options. We'll add this description in section 4.2.

2. Do not use suboption 0. All other sub-options that I&#39;m aware of
always start numbering at 1 and you&#39;re just asking for trouble with
implementations (apparently such as ISC&#39;s) that assume 0 is not "valid".
We also have code that would break if sub-option 0 is used in our server
(though for a completely different reason than the ISC issue).

While you can argue that any suboption value should be valid, that isn&#39;t
the issue. If you want these options supported by implementations,
everything you can do to make that easy to do (by following existing
conventions) will make it that much easier for the support to be added.
If a lot of code needs to be reworked and retested, you&#39;re not as likely
to get the options deployed.

Heejin>> Right. this comment was reflected as I replied to David's mail.

[The remaining comments are probably more because of my ignorance of
this solution as I haven&#39;t kept up with the MIP6 work.]

3. Is there a need to establish a registry for id-type in these options,
or does this already exist somewhere else in the MIP6 space? If it does
exist elsewhere, how about referencing that? 

If these are newly assigned values, wouldn&#39;t using 0 for no-preference
make more sense?

Heejin>> The two options are new options and it is described in section of IANA 
consideration. About using 2 for no-preference, the reason is that 'no-preference'
was defined after the id-type 0 and 1. However, as you suggested, the use of 0 seems 
better for future extension. We'll reflect this.

4. Is there a need to establish a registry for the suboptions for these
options?

Heejin>> We'll add some description also for sub-options in IANA consideration section.

5. Home Network Identifier field:

- "In this case, the Home Network Identifier field SHOULD be set to 0."
Don&#39;t you mean that it should not be present? (IE, option length should
be 2 and just have the id-type and reserved bytes?)

- It might be useful to indicate that this Home Network Identifier field
does NOT include a null byte to terminate the string? Or, perhaps this
should always be null terminated and hence why you say "SHOULD be set to
0"?

Heejin>> No. An HN identifier field exists always, but SHOULD be initialized to 0 
(such as a reserved field) when the id-type = 0 & 2. Therefore, the 0 is not NULL 
character (ascii 0) but integer 0 (ascii 48). I think there is no ambiguity here.

Bottom line, I agree with David that we SHOULD NOT advance this draft at
this time. It still needs work.

Heejin>> Anyway, thanks for your helpful comments which will make the draft complete. :)

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 2:48 PM
To: DHC WG
Subject: Re: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call
ondraft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

On Mon, Jun 25, 2007 at 10:43:12AM -0400, Ralph Droms wrote:
> There has been no response to this WG last call, so the deadline will
be
> extended to 1700EDT, 07/02/07.

My excuse is that I was in Alaska.

http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr
ated
> -04.txt

Correction (I think?):

http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-integr
ated-dhc-04.txt

I actually don&#39;t see a lot in there for DHCWG to review.  Maybe I&#39;m
not looking hard enough?

I am a little concerned (but only a little) at the extent to which
it defines simplified RFC3315 behaviour ("summarizing" the process
in which a client is identified and configured).

   (3) The Relay Agent intercepts the Information Request from the

I think "receives" is a better word, considering that the packet is
transmitted to a multicast address.  "intercept" has more of an
insinuation that the relay would not normally receive the packet.

So I see no problem advancing this draft to the IESG.

> and http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-05.txt

ISC DHCP and others share option processing code between the v4
and v6 side of the house.  I don&#39;t know about the others, but the
net effect for ISC DHCP is that code 0 is treated as an "end tag"
(code 255, or "code all ones" for any code width, is not).  This
sounds a little weird, but that&#39;s the contrivance of the loop we
selected.

If the sub-options could be numbered from 1, then this draft would
be compatible with our currently released alpha.

If not, then it would take new code, adding more branches between
each run of the option processing loop.

I note also that the sub-option codes are 8-bit code/length pairs.
That doesn&#39;t affect ISC DHCP, but I wanted to point it out for other
implementors.

I think this is the first time we&#39;ve seen non-16-bit code/lengths
inside DHCPv6?

   If the request message carries more than one Home Network Identifier
   options, the reply message MUST contain Home Network Information
   options as many as Home Network Identifier options in the request.

I think &#39;as many&#39; wants to be moved left 4 words or so.

Second, I think MUST is too strong, since if the DHCP server is not
configured with values, it will be unable to reply.  Consider
specifically server software that does not (yet) have support for
these options - they will certainly have no code which enforces the
construction of &#39;empty&#39; options.

   The
   Home Network Information options in the reply SHOULD appear in the
   same order as Home Network Identifier options in the request and the
   matching is based on the sequential order of options.  This provides
   a way of matching for Home Network Information options with the same
   id-type.

I don&#39;t get it.  The options SHOULD ppear in the same order, which
means they might not, and the order is also used to match replies
against requests?  So the protocol stipulates that sometimes replies
will not match their requests?

I&#39;m pretty sure this doesn&#39;t work, and I&#39;m pretty certain that
we don&#39;t want to stipulate the strict ordering of the options.

So, I&#39;m not in favor of advancing this document.

If there is a requirement for mulitple instances of these options,
it would be my strong preference for the mechanism to more closely
mimic IA_* options than has been presented here.

I&#39;d also like to see the sub-option-codes numbered from 1, but that&#39;s
not a requirement.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
                 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins    "If you don&#39;t do it right the first time,
Software Engineer             you&#39;ll just have to do it again."
Internet Systems Consortium, Inc.        -- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 4 Jul 2007 09:43:38 -0400

>character (ascii 0) but integer 0 (ascii 48). I think there is no
ambiguity here. 

Wow, that better be made clear as that certainly wasn't to me. Perhaps
it is obvious if you know MIP6, but you should add this clarification.
I'd suggest:

"In this case, the Home Network Identifier field SHOULD be set to a 1
character string containing the 0 character (ASCII 48)."

Also, what is the rational behind this as I don't see "0" mentioned as
being special in RFC 4282?

I think you should provide the rational for this usage as it is a bit
atypical for DHCP -- in this case, the option length is available and
could be set to 2 to mean that no HN identifier field exists and that
would be, IMHO, much cleaner than using a magic string of "0".

---

Regarding section 3.2:

3.2.  MIP6 Relay Agent Option

   This option carries the RADIUS or Diameter attributes that are
   received at the NAS from the AAAH.  The DHCP relay agent sends this
   option to the DHCP server in the Relay-Forward message.

This option really doesn't carry RADIUS or Diameter attributes. It
carries one (or more?) of the sub-options specified in 3.2.1. Though
likely these sub-options are derived from RADIUS or Diameter attributes.

- Bernie

-----Original Message-----
From: Heejin Jang [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2007 9:23 AM
To: Bernie Volz (volz)
Cc: DHC WG; [email-masked];
[email-masked]; [email-masked]; David W.
Hankins
Subject: Re: RE: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call
ondraft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

Hi, Bernie.
Thanks for your opinion.

Please see the inline.

- Regards, 
Heejin  

------- Original Message -------
Sender : Bernie Volz (volz)<[email-masked]>
Date   : 2007-06-30 01:31
Title  : RE: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call
ondraft-ietf-mip6-bootstrapping-integrated and draft-ietf-mip6-hiopt

Regarding

But, perhaps these really aren&#39;t sub-option but instead radius
encoded
attributes ("This option carries the RADIUS or Diameter attributes that
are received at the NAS from the AAAH.")? In that case, shouldn&#39;t
the
sub-options description clearly indicate that and be radius-attributes
or something like that. It is CRITICAL to note that for radius
attributes, the L field in the TLV *includes* the L field (which is not
the case for DHCP options!).

ability to decode radius-encoded attributes. Then the radius-encoded
attributes 
(received from AAA server) need to be re-formatted into dhcp options at
a NAS
(=DHCP relay/Radius client) before delivering them to the mobile node.
Therefore, the proposed sub-options are not radius-encoded attributes
but 
dhcp sub-options. We'll add this description in section 4.2.

implementations (apparently such as ISC&#39;s) that assume 0 is not
"valid".

While you can argue that any suboption value should be valid, that
isn&#39;t
the issue. If you want these options supported by implementations,
everything you can do to make that easy to do (by following existing
conventions) will make it that much easier for the support to be added.
If a lot of code needs to be reworked and retested, you&#39;re not as
likely
to get the options deployed.

If these are newly assigned values, wouldn&#39;t using 0 for
no-preference
make more sense?

Heejin>> The two options are new options and it is described in section
of IANA 
consideration. About using 2 for no-preference, the reason is that
'no-preference'
was defined after the id-type 0 and 1. However, as you suggested, the
use of 0 seems 
better for future extension. We'll reflect this.

Heejin>> We'll add some description also for sub-options in IANA
consideration section.

- "In this case, the Home Network Identifier field SHOULD be set to 0."
Don&#39;t you mean that it should not be present? (IE, option length
should
be 2 and just have the id-type and reserved bytes?)

Heejin>> No. An HN identifier field exists always, but SHOULD be
initialized to 0 
(such as a reserved field) when the id-type = 0 & 2. Therefore, the 0 is
not NULL 
character (ascii 0) but integer 0 (ascii 48). I think there is no
ambiguity here.

Heejin>> Anyway, thanks for your helpful comments which will make the
draft complete. :)

- Bernie

-----Original Message-----
From: David W. Hankins [mailto:[email-masked]] 
Sent: Monday, June 25, 2007 2:48 PM
To: DHC WG
Subject: Re: [dhcwg] EXTENDED: Joint mip6 and dhc WG last call

be

Correction (I think?):

I actually don&#39;t see a lot in there for DHCWG to review.  Maybe
I&#39;m
not looking hard enough?

   The

I&#39;m pretty sure this doesn&#39;t work, and I&#39;m pretty certain
that
we don&#39;t want to stipulate the strict ordering of the options.

I&#39;d also like to see the sub-option-codes numbered from 1, but
that&#39;s
not a requirement.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 5 Jul 2007 11:04:07 -0700

> it is obvious if you know MIP6, but you should add this clarification.

Me as well.  Also...

My limited reading of that material gives me the impression that a
binary zero octet is, if not a proper identity on its own, definitely
a potential element included in an identity, and so validly included
at the end of the field (as an included part of its "UTF 8" identity
string, and not serving as string termination).

I'm not sure if that is the case, but if so it may be a good idea to
give more hints in draft-mip6-hiopt that the field is an opaque
sequence of octets so far as the DHCP software is concerned, and not,
eg, an NVT-ASCII string (as is usual in DHCP text strings, and which
carries quite a lot of null-termination-anyway baggage)?

> would be, IMHO, much cleaner than using a magic string of "0".

I agree.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 5 Jul 2007 16:22:16 -0700

> My limited reading of that material gives me the impression that a

Sorry, I made this unclear in editing.  My reading of RFC4282, which
defines the format of the field in at least one case.