Subject: Re: [Dhcpv6bis] [dhcpv6bis] #86 (XML 3315): DHCPv6 authentication for Information request

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 03 Jun 2015 12:14:48 -0000

#86: DHCPv6 authentication for Information request

Changes (by [email-masked]):

 * owner:  [email-masked] => [email-masked]
 * status:  assigned => new

Comment:

 Changed assignment to Sheng as discussed 6/3/2015 co-author discussion.

-- 
-------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task               |      Status:  new
 Priority:  P3 major           |   Milestone:  C awaiting consensus
Component:  XML 3315           |  Resolution:
 Keywords:                     |    Due Date:
-------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/86#comment:7>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Thu, 25 Jun 2015 08:31:02 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Remove the Delayed Auth Protocol and its dependent text

-- 
-------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task               |      Status:  closed
 Priority:  P3 major           |   Milestone:  C awaiting consensus
Component:  XML 3315           |  Resolution:  fixed
 Keywords:                     |    Due Date:
-------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/86#comment:8>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 26 Jun 2015 19:58:43 +0200

>  Remove the Delayed Auth Protocol and its dependent text
Do we want to do anything extra here? Two things we may consider are:

1. Put a short text that delayed auth protocol is obsolete. Implementers
may look at this draft, don't find it and be confused.

2. Do we want to put a note in IANA section to mark any values as
deprecated? There are no protocol and algorithm registries, so no need
to do any update on those. Anything else that was removed and is in the
IANA registry?

Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 26 Jun 2015 18:40:32 +0000

I'm definitely in favor of making a statement that it is obsolete.

I'm not sure there is much to deprecate and I don't see that having much value? And there's nothing in any IANA registry for the AUTH field values anyway. Ah ...

   This document also references three name spaces in section 21 that
   are associated with the Authentication Option (section 22.11).  These
   name spaces are defined by the authentication mechanism for DHCPv4 in
   RFC 3118 [4].

   The authentication name spaces currently registered by IANA will
   apply to both DHCPv6 and DHCPv4.  In the future, specifications that
   define new Protocol, Algorithm and RDM mechanisms will explicitly
   define whether the new mechanisms are used with DHCPv4, DHCPv6 or
   both.

See http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#authentication-algorithm-id (and the next table for RDM). It looks like the protocol field was never enumerated in the IANA tables? Which is kind of odd as RFC 3118 asked for it. So, perhaps we should contact IANA to add this table? And, add v6 Delay Auth (which is 2).

   Initial values assigned from the Protocol name space are 0 (for the
   configuration token Protocol in section 4) and 1 (for the delayed
   authentication Protocol in section 5).  Additional values from the
   Protocol name space will be assigned through IETF Consensus, as
   defined in RFC 2434 [8].

So this table would be:
	0	v4 Configuration Token (RFC 3118, Section 4)
	1	v4 Delayed Auth (RFC 3118, Section 5)
	2	v6 Delayed Auth (RFC 3315, Section 21.4 - pending deprecation by draft-ietf-dhc-rfc3315bis)
	3	v6 Reconfigure Key Auth (RFC 3315, Section 21.5)

I'll send an email to IANA asking about this and seeing if they can add it. (They may not want to add that part about deprecation just yet.)

- Bernie

-----Original Message-----
From: Tomek Mrugalski [mailto:[email-masked]] 
Sent: Friday, June 26, 2015 1:59 PM
To: dhcpv6bis issue tracker; [email-masked]; [email-masked]; Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcpv6bis] #86 (XML 3315): DHCPv6 authentication for Information request

1. Put a short text that delayed auth protocol is obsolete. Implementers may look at this draft, don't find it and be confused.

2. Do we want to put a note in IANA section to mark any values as deprecated? There are no protocol and algorithm registries, so no need to do any update on those. Anything else that was removed and is in the IANA registry?

Tomek

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 29 Jun 2015 03:56:13 +0000

>I'm definitely in favor of making a statement that it is obsolete.

If you cannot do it very soon, it should be added as a new ticket. I may be able to take it next month.

>I'm not sure there is much to deprecate and I don't see that having much
>value? And there's nothing in any IANA registry for the AUTH field values
>anyway.

That's exactly my conclusion after careful examination.

>Ah ...
>See
>http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-para
>meters.xhtml#authentication-algorithm-id (and the next table for RDM). It
>looks like the protocol field was never enumerated in the IANA tables? Which
>is kind of odd as RFC 3118 asked for it. So, perhaps we should contact IANA to
>add this table? And, add v6 Delay Auth (which is 2).
>
>I'll send an email to IANA asking about this and seeing if they can add it. (They
>may not want to add that part about deprecation just yet.)

If they agreed on this, you just created another new additional work for our 3315bis. :P I may be able to take the follow-up.

Regards,

Sheng

>1. Put a short text that delayed auth protocol is obsolete. Implementers may
>look at this draft, don't find it and be confused.
>
>2. Do we want to put a note in IANA section to mark any values as deprecated?
>There are no protocol and algorithm registries, so no need to do any update
>on those. Anything else that was removed and is in the IANA registry?
>
>Tomek