IETF conflict review for draft-gont-dhcpv6-stable-privacy-addresses
conflict-review-gont-dhcpv6-stable-privacy-addresses-02

The following approval message was sent
From: The IESG
To: draft-gont-dhcpv6-stable-privacy-addresses@ietf.org,
    rfc-ise@rfc-editor.org,
    "Nevil Brownlee"
Cc: "The IESG" ,
    iana@iana.org,
    "IETF-Announce"
Subject: Results of IETF-conflict review for draft-gont-dhcpv6-stable-privacy-addresses-01

The IESG has completed a review of
draft-gont-dhcpv6-stable-privacy-addresses-01 consistent with RFC5742.


The IESG has no problem with the publication of 'A Method for Generating
Semantically Opaque Interface Identifiers with Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)'
as an Informational
RFC.


The IESG has concluded that this work is related to IETF work done in
the dhc WG, but this relationship does not prevent publishing.

Additionally, the IESG requests the following note be added to the
document if it is published:

A predecessor to this document [draft-ietf-dhc-stable-privacy-addresses]
was earlier a working group document in the dhc WG. The WG decided to
stop further work in this area because such work was not considered
useful.

The proposal described in this document has an unaddressed failure case
that makes it unsuitable for use as the mechanism to provide the claimed
failover features for DHCPv6 servers. Specifically, when a DHCPv6 client
DECLINEs a provided address there is no recovery mechanism described
that will result in the DHCPv6 client obtaining a working IPv6 address.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine
whether or not they merit incorporation into the document. Comments may
exist in both the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-gont-dhcpv6-stable-privacy-addresses/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-gont-dhcpv6-stable-privacy-addresses/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot discuss]

I'd like to chat about whether or not the IESG note ought say something
about the fact that this (presumably?) used to be a DHC WG document. [1]
Were the WG ok with this being sent to the ISE or were they asked if
they were ok? If the WG were asked and don't care or are happy for it
to be an ISE document, then that's fine, but in some other cases, maybe
we ought ask the ISE to say something more in the IESG note.

I see there is an "ISE writeup" [2] in the tracker, which is great
(thanks Nevil) but that text doesn't answer the above. If there
were a good answer that didn't need to be reflected in an IESG note
then perhaps that'd be a fine place to record that for posterity.

I suspect it'd also be good (for IPR reasons, if not IETF process
reasons) if the "replaced-by" had been set to show that this
submission used once be a WG document.

[1] https://tools.ietf.org/html/draft-ietf-dhc-stable-privacy-addresses
[2] https://datatracker.ietf.org/doc/draft-gont-dhcpv6-stable-privacy-addresses/shepherdwriteup/

[Ballot discuss]

I'd like to chat about whether or not the IESG note ought say something
about the fact that this (presumably?) used to be a DHC WG document. [1]
Were the WG ok with this being sent to the ISE or were they asked if
they were ok? If the WG were asked and don't care or are happy for it
to be an ISE document, then that's fine, but in some other cases, maybe
we ought ask the ISE to say something more in the IESG note.

I see there is an "ISE writeup" [2] in the tracker, which is great
(thanks Nevil) but that text doesn't answer the above. If there
were a good answer that didn't need to be reflected in an IESG note
then perhaps that'd be a fine place to record that for posterity.

I suspect it'd also be good (for IPR reasons, if not IETF process reasons)
if the "replaced-by" had been set to show that this submission used
once be a WG document.

[1] https://tools.ietf.org/html/draft-ietf-dhc-stable-privacy-addresses
[2] https://datatracker.ietf.org/doc/draft-gont-dhcpv6-stable-privacy-addresses/shepherdwriteup/

[Ballot discuss]

I'd like to chat about whether or not the IESG note ought say something
about the fact that this (presumably?) used to be a DHC WG document. [1]
Were the WG ok with this being sent to the ISE or were they asked if
they were ok? If the WG were asked and don't care or are happy for it
to be an ISE document, then that's fine, but in some other cases, maybe
we ought ask the ISE to say something more in the IESG note.

I see there is an "ISE writeup" [2] in the tracker, which is great (thanks
Nevil) but that text doesn't answer the above. If there were a good
answer that didn't need to be reflected in an IESG note then perhaps
that'd be a fine place to record that for posterity.

I suspect it'd also be good (for IPR reasons, if not IETF process reasons)
if the "replaced-by" had been set to show that this submission used
once be a WG document.

[1] https://tools.ietf.org/html/draft-ietf-dhc-stable-privacy-addresses
[2] https://datatracker.ietf.org/doc/draft-gont-dhcpv6-stable-privacy-addresses/shepherdwriteup/

[Ballot comment]
General:
The document contains instances of normative language such as

"A DHCPv6 server implementing this specification must select the IPv6 addresses to be leased with the following algorithm"

Suggest rewording to something like

"A DHCPv6 server implementing this specification selects the IPv6 addresses to be leased with the following algorithm"

Section 5: Security considerations

Suggest adding the privacy assessment RFC as a reference in addition to the anonymity profile RFC.

OLD:

Please read  [I-D.ietf-dhc-anonymity-profile] for a comprehensive assessment of the privacy implications of DHCPv6.

NEW:

Please read  [RFC7824] and [RFC7844] for a comprehensive assessment of the privacy implications of DHCPv6.