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

[Sheng Jiang <[e-mail]>]

>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 ...
>
>   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-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).
>
>   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.)

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

>- Bernie
>
>-----Original Message-----
>From: Tomek Mrugalski [mailto:[e-mail]]
>Sent: Friday, June 26, 2015 1:59 PM
>To: dhcpv6bis issue tracker; [e-mail]; [e-mail];
>Bernie Volz (volz)
>Cc: [e-mail]
>Subject: Re: [dhcpv6bis] #86 (XML 3315): DHCPv6 authentication for
>Information request
>
>On 25.06.2015 10:31, dhcpv6bis issue tracker wrote:
>> #86: DHCPv6 authentication for Information request
>>
>> Changes (by [e-mail]):
>>
>>  * status:  new => closed
>>  * resolution:   => fixed
>>
>> Comment:
>>
>>  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