Re: [v6ops] Fwd: New Version Notification for draft-hilliard-v6ops-host-addr-update-00.txt

[Lorenzo Colitti <[e-mail]>]

Nick,

the text you mention was not "slipped in" by mistake, it was the outcome of
WG discussion.

In September 2015 (-01), the text read:

   If the network requires explicit requests
   for address space (e.g., if it requires DHCPv6 to connect), it is
   RECOMMENDED that the network assign a /64 prefix to every host (e.g.,
   via DHCPv6 PD).

Some in the WG felt that it was not correct to single out DHCPv6 PD,
because it was not in wide use. Thus, in February 2016 (-05), the text was
changed to:

   Due to the drawbacks imposed by requiring explicit requests for
   address space (see section Section 4), it is RECOMMENDED that the
   network give the host the ability to use new addresses without
   requiring explicit requests.  This can be achieved either by allowing
   the host to form new addresses autonomously (e.g., via SLAAC), or by
   providing the host with a dedicated /64 prefix.  The prefix MAY be
   provided using DHCPv6 PD, SLAAC with per-device VLANs, or any other
   means.

There were dozens or maybe hundreds on emails on this text, so I don't
think the WG was blindsided.

Cheers,
Lorenzo

On Mon, Jul 17, 2017 at 7:47 PM, Nick Hilliard <[e-mail]> wrote:

> draft-hilliard-v6ops-host-addr-update-00 has just been posted as an ID.
>
> It has recently been claimed that IETF best current practice is that
> DHCPv6 is not recommended due to the recommendations section in
> RFC7934/BCP204.
>
> The relevant text was slipped into
> draft-ietf-v6ops-host-addr-availability-05 on Feb 12, 2016, a couple of
> days before the document went into IETF LC.  There was no discussion
> about this text change either in the v6ops working group or at IETF
> review or IESG level: perhaps the modification appeared innocuous or
> maybe it just wasn't not noticed.
>
> Next thing, there's a BCP which is being interpreted as meaning that
> DHCPv6 is NOT RECOMMENDED for operational use.  Wow. :-)
>
> This presents a variety of problems, the most serious of which are 1)
> that a BCP is implying that the use of DHCPv6 was "NOT RECOMMENDED"
> without extensive discussion or debate about this particular issue at
> the relevant working group, and ignores the both the widespread use of
> the protocol and its active development at the ietf, and 2) that a
> change in the status of DHCPv6 to "NOT RECOMMENDED" leaves a huge hole
> in the IPv6 host specification.
>
> Job and I believe that this went through by mistake and that if the WG
> had noticed the change at the time, consensus would never have been
> reached on what is a serious semantic change to IETF lore.
>
> Right now, the most prudent course of action would be to roll back the
> change until a proper debate has been had.  We invite WG comments on
> this doc.
>
> Nick
>
> [e-mail] wrote:
> > A new version of I-D, draft-hilliard-v6ops-host-addr-update-00.txt
> > has been successfully submitted by Nick Hilliard and posted to the
> > IETF repository.
> >
> > Name:         draft-hilliard-v6ops-host-addr-update
> > Revision:     00
> > Title:                Update for IPv6 Host Address Availability
> Recommendations
> > Document date:        2017-07-17
> > Group:                Individual Submission
> > Pages:                4
> > URL:            https://www.ietf.org/internet-
> drafts/draft-hilliard-v6ops-host-addr-update-00.txt
> > Status:         https://datatracker.ietf.org/
> doc/draft-hilliard-v6ops-host-addr-update/
> > Htmlized:       https://tools.ietf.org/html/d
> raft-hilliard-v6ops-host-addr-update-00
> > Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-hilliard-v6ops-host-addr-update-00
> >
> >
> > Abstract:
> >    The IPv6 Host Address Availability Recommendations Best Current
> >    Practice (RFC 7934), describes why IPv6 hosts should use multiple
> >    global addresses when attaching to a network.  This document updates
> >    RFC 7934 by removing a recommendation for networks to give the host
> >    the ability to use new addresses without requiring explicit requests.
> >
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>