Subject: Re: [Ietf-krb-wg] I-D Action:draft-sakane-dhc-dhcpv6-kdc-option-09.txt

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 23 May 2011 13:21:05 -0400 (EDT)

On Wed, 20 Apr 2011, Shoichi Sakane wrote:

> I found another typo as well.  all are fixed.
> To follow other option's code, "OPTION_KRB_KDC_OPTION" is changed to
> "OPTION_KRB_KDC".
> ...
> when a dhcpv6 client only knows its realm name but does not know
> the kdc address of the realm,  the client can ask dhcpv6 server
> kdc addresses by sending the realm option.
>
> I improved the text in section 3.2 and 3.3 in case.

OK, this makes things much clearer.  Go ahead and submit that, and then I 
will send the document along.

-- Jeff
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Shoichi Sakane <[email-masked]>
Date: Tue, 24 May 2011 11:13:00 +0900

Jeff,

I modified the reference of the STARTTLS and the copyright
year suggested by the id-nits.
And, I have submitted it.  Thanks a lot!

Shoichi

On 5/24/11 2:21 AM, Jeffrey Hutzelman wrote:
> OK, this makes things much clearer. Go ahead and submit that, and then I will send the document along.
>
> -- Jeff

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 May 2011 22:56:34 -0400

Section 5 re-specifies standard practice, which is unnecessary, and also error-prone.   Section 6 contains at least one error (it refers to suboptions, which I think are no longer present in this version).   Also, it is not future-proof.  What if a new message is defined?   Also, I don't see why it's necessary--what error are you trying to prevent?  Specifying individual treatment of configuration options is strongly discouraged, because it requires special-case code on the server.

I know there are a number of option specs that have slipped through with text like this despite our attempts to prevent it, but please don't use these documents as a model for the right way to define DHCP options.   DHCP options are not protocol extensions--they are just containers.

Thanks for doing this document.   I am sorry for having to propose more changes at this late date.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 May 2011 23:00:19 -0400

> Thanks for doing this document.   I am sorry for having to propose more changes at this late date.

Oh, by the way, the change I would propose is to simply delete sections 5 and 6.   Sorry for not being more specific!

---

From: Shoichi Sakane <[email-masked]>
Date: Wed, 25 May 2011 12:11:46 +0900

Ted and Jeff,

> Oh, by the way, the change I would propose is to simply delete sections 5 and 6.   Sorry for not being more specific!

I just followed past documents which defined the options.
I don't have any objection.  I agree with you, Ted.

Jeff,

could you suggest me the timing when I should remove it.
I have to remove it and submit the new version asap ?
Or, should I do it in the IESG review phase ?

Shoichi

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 May 2011 00:16:40 -0400

> Or, should I do it in the IESG review phase ?

I know you didn't ask me, but for what it's worth, less text is usually better than more.   It's easier for the IESG to get through it (they have to read a *lot* of documents), and you can't ask a question about a bit of text that isn't there.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 May 2011 00:11:33 -0400

On Mon, 2011-05-23 at 22:56 -0400, Ted Lemon wrote:
> Section 5 re-specifies standard practice, which is unnecessary, and
>  also error-prone.

Of three paragraphs in this section, the first harmlessly restates the
obvious, the second is indeed a respecification of part of DHCP, and the
third makes a specific recommendation with regard to the options defined
in the present document; specifically, that servers (which implement
this document) SHOULD provide at least a default realm.

That third paragraph is new normative text which does not duplicate
anything that's said anywhere else.  We can disagree on whether it's
appropriate, but it certainly isn't superfluous.

>  Section 6 contains at least one error (it refers
>  to suboptions, which I think are no longer present in this version).  
>  Also, it is not future-proof.  What if a new message is defined?  
>  Also, I don't see why it's necessary--what error are you trying to
>  prevent?  Specifying individual treatment of configuration options is
>  strongly discouraged, because it requires special-case code on the
>  server.

Speaking individually, I'll agree this section really does seem
inappropriate.  However, as a chair I'll note this document is post-WGLC
and has had ample opportunity for review, so a change at this point will
require some demonstration of support from the WG.  I'll set a timeout
for comments on this topic of 23:59 UTC Thu 2-Jun-2001 or the conclusion
of the discussion on the previous point, whichever is later.

-- Jeff

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 May 2011 09:57:20 -0400

> appropriate, but it certainly isn't superfluous.

It's not harmless to restate the obvious, because it's frequently the case that when one restates the obvious in a standard, one restates it slightly incorrectly.   We'd like to avoid playing telephone if at all possible.

You're right about the third paragraph--I missed that in my most recent review.   Sorry about that.

> of the discussion on the previous point, whichever is later.

It's worth noting that this option, in addition to being useful for Kerberos implementations, is also a DHCP extension.   AFAIK it hasn't passed any sort of last call in the DHC working group.   Moreover, the Kerberos working group apparently hasn't adopted it as a work item (or, if it has, the draft ought to say so, but currently does not).   So while it's definitely worth getting consensus on my proposed changes in the Kerberos working group, this is because it's a good idea to get consensus, not because it's a necessary step in some formal process.

I also noticed that the draft says it's Informational.   However, it defines a protocol extension to DHCP.   To me, this makes it pretty clearly standards track, not informational.   Sorry for not noticing this sooner--I'm afraid I have a tendency not to read the boilerplate.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 May 2011 10:43:41 -0400

On Thu, 2011-05-26 at 09:57 -0400, Ted Lemon wrote:
> It's not harmless to restate the obvious, because it's frequently the
>  case that when one restates the obvious in a standard, one restates it
>  slightly incorrectly.   We'd like to avoid playing telephone if at all
>  possible.

The text in question says:

   After the DHCPv6 server receives a message which is contained an
   Option Request Option, what information the server will provide
   depends on the policy of the server in the end.

That's descriptive and fairly well the way the world works whether we
like it or not, so it doesn't seem problematic to me.  It's not like
it's respecifying something that is part of DHCP.  That said, I'm not
taking a position on this one.  Anyone else want to chime in?

>  review.   Sorry about that.

So, what do you want to do about it?  Is a recommendation like this one
(copied below for reference) going to be problematic?  It doesn't feel
to me like it crosses into the realm of requiring special-case code on
the server, but then, my DHCP server configuration likely has more code
than most. :-)

> It's worth noting that this option, in addition to being useful for
>  Kerberos implementations, is also a DHCP extension.   AFAIK it hasn't
>  passed any sort of last call in the DHC working group.   Moreover, the
>  Kerberos working group apparently hasn't adopted it as a work item
>  (or, if it has, the draft ought to say so, but currently does not).  
>  So while it's definitely worth getting consensus on my proposed
>  changes in the Kerberos working group, this is because it's a good
>  idea to get consensus, not because it's a necessary step in some
>  formal process.

We had the choice-of-forum discussion back in November of 2008, and
agreed that since DHCP option development doesn't generally happen in
dhc, we'd take it on in krb-wg.  We actually did so some time ago, and
the datatracker already believes we own the document, though the
corresponding charter update is only now working its way through the
IESG.  If you want, I can forward you the mail that Ralph and I
exchanged on this question.

The WGLC on this document happened in March, 2010 in krb-wg, with a copy
to the dhcwg list.  You even commented on it, resulting in a fairly
large change between -08 and -09 which eliminated the use of suboptions
and any references to carrying IPv4 addresses, among other changes.
It's taken a while to get from there to here, but I do think it's
basically done, once we resolve the new issues you've raised.

> I also noticed that the draft says it's Informational.   However, it
>  defines a protocol extension to DHCP.   To me, this makes it pretty
>  clearly standards track, not informational.   Sorry for not noticing
>  this sooner--I'm afraid I have a tendency not to read the boilerplate.

Interestingly, this issue was raised during last call, and you said
something about there being some changes in the works to allow DHCPv6
option allocation under the IESG Approval policy, which would make this
question moot.  Did that never happen?

In any case, I hardly think changing the intended status is going to be
controversial.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Fri, 27 May 2011 05:46:46 -0400

Speaking as an individual, I support rapid closure on this draft.  I do
not think any of the issues Ted brings up require changes; my preference
is to make no additional changes at this point.  I do not object to
removing the first two paragraphs of section 5 and section 6 if there is
support, but I am not providing such support.  I would prefer to keep
the third paragraph regarding default realm recommendations, but again,
would more strongly prefer rapid closure.