Skip to main content

Registering Self-generated IPv6 Addresses using DHCPv6
draft-ietf-dhc-addr-notification-13

Revision differences

Document history

Date Rev. By Action
2024-06-06
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-06-06
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-06-06
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-06-03
13 (System) IANA Action state changed to Waiting on Authors
2024-05-24
13 (System) RFC Editor state changed to EDIT
2024-05-24
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-05-24
13 (System) Announcement was received by RFC Editor
2024-05-23
13 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-05-23
13 Cindy Morgan IESG has approved the document
2024-05-23
13 Cindy Morgan Closed "Approve" ballot
2024-05-23
13 Cindy Morgan Ballot approval text was generated
2024-05-23
13 Éric Vyncke
Thanks to the authors for updating their I-D based on the IESG reviews (even if I would have preferred fixing Gunter's "option-len 0" comment as …
Thanks to the authors for updating their I-D based on the IESG reviews (even if I would have preferred fixing Gunter's "option-len 0" comment as well).
2024-05-23
13 (System) Removed all action holders (IESG state changed)
2024-05-23
13 Éric Vyncke IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2024-05-16
13 Murray Kucherawy [Ballot comment]
Thanks for addressing my DISCUSS question and BCP 14 issues.
2024-05-16
13 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2024-05-16
13 Jenny Bui IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2024-05-16
13 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-05-16
13 Timothy Winters This document now replaces draft-ietf-dhc-addr-registration, draft-wkumari-dhc-addr-notification instead of draft-wkumari-dhc-addr-notification
2024-05-16
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-05-16
13 Jen Linkova New version available: draft-ietf-dhc-addr-notification-13.txt
2024-05-16
13 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-05-16
13 Jen Linkova Uploaded new revision
2024-05-15
12 Murray Kucherawy
[Ballot discuss]
Why the SHOULD in Section 3?  This seems to me to be the key to the entire idea, but compliant implementations have a …
[Ballot discuss]
Why the SHOULD in Section 3?  This seems to me to be the key to the entire idea, but compliant implementations have a choice not to do so?  When would you not?

Unless I'm reading this wrong, you probably want something like "clients implementing this specification will multicast ..." or "clients implementing this specification MUST multicast ...".
2024-05-15
12 Murray Kucherawy
[Ballot comment]
Just checking: Are we sure exceeding the usual limit on author count is justified here?

I found the majority of the SHOULD [NOT] …
[Ballot comment]
Just checking: Are we sure exceeding the usual limit on author count is justified here?

I found the majority of the SHOULD [NOT] instances in here to be unsupported.  Why aren't they MUSTs?  Do they need to be SHOULD [NOT]?  What's the impact if I deviate?  What advice can we offer to implementers when confronted with these choices?  I note that a couple of the other IESG members had similar questions in a few cases.
2024-05-15
12 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2024-05-15
12 John Scudder
[Ballot comment]
Thanks for this very readable document. I have a few comments I hope may be helpful.

### Section 4.2.1, Otherwise

```
If the …
[Ballot comment]
Thanks for this very readable document. I have a few comments I hope may be helpful.

### Section 4.2.1, Otherwise

```
If the message is not discarded, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by [RFC8415] or within a prefix delegated to the client via DHCPv6-PD (see Section 6.3 of [RFC8415]). Otherwise, it MUST drop the message, and SHOULD log this fact.
```

Because the first sentence is SHOULD, the “otherwise” is ambiguous – it could mean that the address registration server disregarded the SHOULD and didn’t do the verification, or it could mean what I expect you intended, which is that the address being registered is not appropriate to the link.

The easiest fix I see is to replace “otherwise” with “if the address being registered fails this verification”, as in,

NEW:
If the message is not discarded, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by [RFC8415] or within a prefix delegated to the client via DHCPv6-PD (see Section 6.3 of [RFC8415]). If the address being registered fails this verification, it MUST drop the message, and SHOULD log this fact.

This change would also have the felicitous side effect of not having two consecutive sentences begin with “otherwise“. (I didn't quote the second one, but it comes next.)

### Section 4.6.1, needs forward reference

“AddrRegRefreshCoalesce allows battery-powered hosts to wake up less often.”

I suggest adding a forward reference as in, “AddrRegRefreshCoalesce (Section 4.6.3) allows battery-powered hosts to wake up less often.”

### Acknowledgements

I thought it was weird that the document both credits a previous document ("borrows heavily”), listing the authors of that document, AND also adds the authors of that document as front-page authors/contributors of the present document. So, you are acknowledging... yourselves. ("Good job, me!" ;-)

I mean, it's not a big deal, whatever. But given that the justification for six authors is "because the previous document", isn't being listed on the front page acknowledgment enough? On the other hand, if the goal is to retain the information that draft-ietf-dhc-addr-registration is a predecessor document, why not put that in the replaces/replaced-by metadata instead? It's arguably both more visible and more useful that way. It *is* possible, I'm pretty sure, to have multiple documents in the replaced-by.
2024-05-15
12 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-05-15
12 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-05-15
12 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-05-15
12 Paul Wouters
[Ballot comment]
This is very useful!

I was going to be all smug and say you should only allow these from the IP itself and …
[Ballot comment]
This is very useful!

I was going to be all smug and say you should only allow these from the IP itself and not link-local, and then that text was already in there! :-)
2024-05-15
12 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2024-05-14
12 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-dhc-addr-notification-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-dhc-addr-notification-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3

* "After successfully assigning...configured IPv6 address" ->
  "After successfully assigning...configured valid IPv6 address"

  This would match the RFC 4862 "valid addresses" specificity used in S4.2.

## Nits

### S3

* "the client MUST NOT register any addresses" ->
  "the client MUST NOT register any addresses using the mechanism in this
  specification"
2024-05-14
12 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2024-05-14
12 Jim Reid Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Jim Reid. Sent review to list.
2024-05-14
12 Jim Reid Request for Telechat review by DNSDIR is assigned to Jim Reid
2024-05-13
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-05-13
12 Jen Linkova New version available: draft-ietf-dhc-addr-notification-12.txt
2024-05-13
12 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-05-13
12 Jen Linkova Uploaded new revision
2024-05-13
11 Deb Cooley
[Ballot comment]
Thanks to Peter Yee for doing the secdir review. 

Assuming that the comments he made lead to changes that were agreed on the …
[Ballot comment]
Thanks to Peter Yee for doing the secdir review. 

Assuming that the comments he made lead to changes that were agreed on the list, then I have no further comments.
2024-05-13
11 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2024-05-12
11 Roman Danyliw
[Ballot comment]
Thank you to Mallory Knodel for the GENART review.

** Section 4.2.1

  *  SHOULD log the address registration information (as is done …
[Ballot comment]
Thank you to Mallory Knodel for the GENART review.

** Section 4.2.1

  *  SHOULD log the address registration information (as is done
      normally for clients to which it has assigned an address), unless
      configured not to do so.  The server SHOULD log the client DUID
      and the link-layer address, if available.  The server MAY log any
      other information.

Section 1 elaborated on forensic and security use cases as key motivations for this protocol feature.  If a log entry is not made for the registration as allowed by this SHOULD, most of the value of this feature seems to be lost.

** Section 7. Editorial.

  *  one new DHCPv6 option, described in Section 4.1 which requires an
      allocation out of the registry of DHCPv6 Option Codes:

Technically, the registry name is “Option Codes”

** Section 7:  Editorial. Please state the obvious that the reference column is this document for the two mentioned registries.
2024-05-12
11 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-05-09
11 Carlos Jesús Bernardos Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Jesús Bernardos. Sent review to list.
2024-05-08
11 Jim Guichard
[Ballot comment]
# Jim Guichard, RTG AD, comments for draft-ietf-dhc-addr-notication

COMMENTS:

141   address registration.  It can do this by including the Address
142   …
[Ballot comment]
# Jim Guichard, RTG AD, comments for draft-ietf-dhc-addr-notication

COMMENTS:

141   address registration.  It can do this by including the Address
142   Registration option code the Option Request option (see Section 21.7
143   of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or

Jim> I find the above text a little confusing. RFC 8415 defines the ‘Option Request’ option with ‘option-code’. I think the above is saying that an ‘Address Registration’ option-code should be included in the ‘Option Request’ option (?). If so, I suggest saying ‘It can do this by including the Address Registration option-code within the Option Request option (see Section 21.7 of [RFC8415]’

147   option in its Reply message.  If the network does not support (or is
148   not willing to receive) any address registration information, the
149   client MUST NOT register any addresses.  Otherwise, the client
150   registers addresses as described below.

Jim> What happens if the client ignores the MUST NOT?

153   its interfaces, a client implementing this specification SHOULD
154   multicast an ADDR-REG-INFORM message in order to inform the DHCPv6

Jim> Using which multicast address? It looks like you specify it in section 4.2 so I would suggest referencing that here.
2024-05-08
11 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-05-07
11 Mallory Knodel Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Mallory Knodel. Sent review to list.
2024-05-06
11 Gunter Van de Velde
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-dhc-addr-notification-11

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================
## well …
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-dhc-addr-notification-11

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================
## well written draft edited in a nice reading style. Fun to read, especially the motivation for this work. Fully support this very relevant functionality.

## It is unclear what actions to take when the option-len is set to  value different as zero, eventhough the document prescribes that the value MUST be 0 (line211)

## In the abstract is written that statically assigned addresses can be reported. However later in the document only SLAAC seems discussed. For some reason CGA (RFC3972) type addresses is not mentioned. Not sure that was intentional or by accident.

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

117   The lack of this parity with IPv4 is one of the reasons that may be
118   hindering IPv6 deployment, especially in enterprise networks.

[minor] WHile potentially true, i am not convinced that this phrase adds
value for the document. The first paragraph already details well enough
the problem space without the procedure outlined in this draft.

141   address registration.  It can do this by including the Address
142   Registration option code the Option Request option (see Section 21.7
143   of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or
144   Rebind messages it sends to the server as part of the regular

[minor] i am wondering if adding 'within'
s/Registration option code the Option Request/Registration option code within the Option Request/
would make sense from readability perspective?

147   option in its Reply message.  If the network does not support (or is
148   not willing to receive) any address registration information, the
149   client MUST NOT register any addresses.  Otherwise, the client
150   registers addresses as described below.

[minor] I assume that it is the DHCP server and not the network that may
not support (or i snot willing) to process such information.

152   After successfully assigning a self-generated IPv6 address on one of
153   its interfaces, a client implementing this specification SHOULD

[minor] or statical configured

211     option-len            0

[major] what to do if its not zero?

215   If a client has the address registration mechanism enabled, it SHOULD
216   include this option in all Option Request options that it sends.

[minor] Would a stronger MUST not be justified? Why would a client, which
supports the functionality AND has it enabled not advertise this?

218   A server which is configured to support the address registration
219   mechanism MUST include this option in Reply messages.

[minor] as a response when receiving such option from a client? or
simply always add this option?

223   The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an
224   IPv6 address is in use.  The format of the ADDR-REG-INFORM message is
225   described as follows:

[minor] Is it intended that the address is 'in use' or 'allocated and assigned
by the device on an interface'?

284   The client MUST only send the ADDR-REG-INFORM message for valid
285   ([RFC4862]) addresses of global scope ([RFC4007]).  This includes ULA
286   addresses, which are defined in [RFC4193] to have global scope.  The
287   client MUST NOT send the ADDR-REG-INFORM message for addresses
288   configured by DHCPv6.

[major] In the abstract is written "or statically configured addresses" which
is more then RFC4862 addresses. The text should include the statically
addresses. What about Cryptographically Generated Addresses (CGAs) defined in RFC 3972?

290   The client SHOULD NOT send the ADDR-REG-INFORM message if it has not
291   received any Router Advertisement message with either M or O flags
292   set to 1.

[minor] This reads difficult because it is a double negative. What about following rewrite:
"The client SHOULD NOT send the ADDR-REG-INFORM message if it has
received no Router Advertisement message with either the M or
O flags set to 1"

298   Servers MUST discard any ADDR-REG-INFORM messages that meet any of
299   the following conditions:

[major] What abot receiving such with length =! 0?

314   If the message is not discarded, the address registration server
315   SHOULD verify that the address being registered is "appropriate to
316   the link" as defined by [RFC8415] or within a prefix delegated to the
317   client.  Otherwise, it MUST drop the message, and SHOULD log this
318   fact.  Otherwise, the server:

[minor] i got thrown offguard with the the construct 'prefix delegated'.
Is this RFC 3633 (IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version 6)? i asusme it is not, but in that case maybe
explain what 'prefix delegated' means? if it is RFC3633, maybe add reference.

320   *  SHOULD register or update a binding between the provided Client
321       Identifier and IPv6 address in its database.  The lifetime of the
322       binding is equal to the Valid Lifetime of the address reported by
323       the client.  If there is already a binding between the registered
324       address and another client, the server SHOULD log the fact and
325       update the binding.

[minor] is there any thoughts about managing misbahaving clients
sending 1000000000's of these by accident?

472   We define a function AddrRegRefreshInterval(address) as min(4 hours,
473   80% of the address's current Valid Lifetime).  When calculating this

[minor] who is 'we'? the WG, the authors? the IETF community?
2024-05-06
11 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-05-03
11 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to Recuse from Abstain
2024-05-03
11 Warren Kumari [Ballot comment]
'm-a-norther
2024-05-03
11 Warren Kumari [Ballot Position Update] New position, Abstain, has been recorded for Warren Kumari
2024-04-30
11 Peter Yee Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.
2024-04-30
11 Peter Yee Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Peter Yee.
2024-04-30
11 Niclas Comstedt Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Niclas Comstedt. Sent review to list.
2024-04-30
11 Jim Reid Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: Jim Reid. Sent review to list.
2024-04-30
11 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Carlos Jesús Bernardos
2024-04-30
11 Éric Vyncke Requested Telechat review by INTDIR
2024-04-30
11 Éric Vyncke Placed on agenda for telechat - 2024-05-16
2024-04-30
11 Éric Vyncke Ballot has been issued
2024-04-30
11 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2024-04-30
11 Éric Vyncke Created "Approve" ballot
2024-04-30
11 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-04-30
11 Éric Vyncke Ballot writeup was changed
2024-04-30
11 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-04-29
11 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2024-04-29
11 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dhc-addr-notification-11. If any part of this review is inaccurate, please let us know.

The …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dhc-addr-notification-11. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the Option Codes registry in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry group located at:

https://www.iana.org/assignments/dhcpv6-parameters/

a single new Option Code is to be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_ADDR_REG_ENABLE
Client ORO: Yes
Singleton Option: Yes
Reference: [ RFC-to-be; Section 4.1 ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the Message Types registry also in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry group located at:

https://www.iana.org/assignments/dhcpv6-parameters/

two new Message Types are to be registered as follows:

Value: [ TBD-at-Registration ]
Description: ADDR-REG-INFORM
Reference: [ RFC-to-be; Section 4.2 ]

Value: [ TBD-at-Registration ]
Description: ADDR-REG-REPLY
Reference: [ RFC-to-be; Section 4.3 ]

We understand that these two actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-04-20
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Peter Yee
2024-04-19
11 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Niclas Comstedt
2024-04-19
11 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2024-04-18
11 Carl Wallace Assignment of request for Last Call review by SECDIR to Carl Wallace was rejected
2024-04-18
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2024-04-18
11 Jean Mahoney Request for Last Call review by GENART is assigned to Mallory Knodel
2024-04-17
11 David Dong IANA Experts State changed to Reviews assigned
2024-04-17
11 Jim Reid Request for Last Call review by DNSDIR is assigned to Jim Reid
2024-04-16
11 Jenny Bui IANA Review state changed to IANA - Review Needed
2024-04-16
11 Jenny Bui
The following Last Call announcement was sent out (ends 2024-04-30):

From: The IESG
To: IETF-Announce
CC: dhc-chairs@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-addr-notification@ietf.org, evyncke@cisco.com, tim@qacafe.com …
The following Last Call announcement was sent out (ends 2024-04-30):

From: The IESG
To: IETF-Announce
CC: dhc-chairs@ietf.org, dhcwg@ietf.org, draft-ietf-dhc-addr-notification@ietf.org, evyncke@cisco.com, tim@qacafe.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Registering Self-generated IPv6 Addresses using DHCPv6) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG (dhc)
to consider the following document: - 'Registering Self-generated IPv6
Addresses using DHCPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-04-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a method to inform a DHCPv6 server that a
  device has one or more self-generated or statically configured
  addresses.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-notification/



No IPR declarations have been submitted directly on this I-D.




2024-04-16
11 Jenny Bui IESG state changed to In Last Call from Last Call Requested
2024-04-16
11 Éric Vyncke Last call was requested
2024-04-16
11 Éric Vyncke Ballot approval text was generated
2024-04-16
11 Éric Vyncke Ballot writeup was generated
2024-04-16
11 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation
2024-04-16
11 Éric Vyncke Last call announcement was generated
2024-04-16
11 Timothy Winters
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  This document seemed to reach consensus of the DHC working group.  Review was
  done by several members of the group during it's life cycle.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No, this document went thru a normal working group process.  It had good discussion
  during meetings and on the mailing list.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  An implementation is in progress on Android at https://r.android.com/2709341 .

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  This is a document did get an DNSDIR review, but as the reviewer noted there is little
  actual DNS in the document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  As document shepherd, I reviewed this document to assure that it is following
  the WG consensus and discussions and is of good quality. In my opinion, the
  document is ready for publication.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    This document was reviewed by the DHC working group with no impact on other working groups.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The RFC requested is Proposed Standard. This is appropriate for this
    document as it defines a method for informing DHCPv6 Servers of self-generated or
    configured addresses.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
 
    Yes all the authors responded that they aren't aware of any IPR issues.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
 
    Yes, all the authors responded that they are willing to respond.
   
    This document borrows heavily from a previous document, draft-ietf-dhc-addr-registration, which defined "a mechanism to register          self-generated and statically configured addresses in DNS through a DHCPv6 server", which was abandoned after WGLC. The authors                of draft-ietf-dhc-addr-notification felt that it was appropriate to acknowledge the primary authors of this previous document by                keeping them as authors on the new document. 

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I reviewed the document and found a NIT using MUST not instead of MUST NOT.  It has been
    reported to the authors.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    Yes, every reference that I located had a valid reference.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are publicly available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    There are two different IANA request in this document.  A request for two new DHCPv6 messages and one new DHCPv6 option.

    DHCP message types require standard action, which the DHC working group reviewed.

      DHCP options require expect review from Bernie Volz, Ted Lemon, Tomek Mrugalski.  Bernie
      is the working group chair for DHC and commented on the draft several times.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    This document only impacts existing IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2024-04-15
11 Éric Vyncke Waiting for a revised shepherd write-up that includes a justification for 6 authors (question 13).
2024-04-15
11 Éric Vyncke IESG state changed to AD Evaluation from AD Evaluation::AD Followup
2024-04-12
11 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-04-12
11 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-04-12
11 Warren Kumari New version available: draft-ietf-dhc-addr-notification-11.txt
2024-04-12
11 Warren Kumari New version approved
2024-04-12
11 (System) Request for posting confirmation emailed to previous authors: Jen Linkova , Lorenzo Colitti , Rajiv Asati , Sheng Jiang , Suresh Krishnan , Warren Kumari
2024-04-12
11 Warren Kumari Uploaded new revision
2024-04-08
10 Éric Vyncke AD review done: https://mailarchive.ietf.org/arch/msg/dhcwg/jo-1kXhSntzL1n4_SPqXQ0yqFRE/
Already in contact with one author, Warren Kumari.
2024-04-08
10 (System) Changed action holders to Éric Vyncke, Warren Kumari, Suresh Krishnan, Rajiv Asati, Lorenzo Colitti, Jen Linkova, Sheng Jiang (IESG state changed)
2024-04-08
10 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2024-03-26
10 Timothy Winters
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  This document seemed to reach consensus of the DHC working group.  Review was
  done by several members of the group during it's life cycle.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No, this document went thru a normal working group process.  It had good discussion
  during meetings and on the mailing list.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  An implementation is in progress on Android at https://r.android.com/2709341 .

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  This is a document did get an DNSDIR review, but as the reviewer noted there is little
  actual DNS in the document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  As document shepherd, I reviewed this document to assure that it is following
  the WG consensus and discussions and is of good quality. In my opinion, the
  document is ready for publication.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    This document was reviewed by the DHC working group with no impact on other working groups.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The RFC requested is Proposed Standard. This is appropriate for this
    document as it defines a method for informing DHCPv6 Servers of self-generated or
    configured addresses.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
 
    Yes all the authors responded that they aren't aware of any IPR issues.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
 
    Yes, all the authors responded that they are willing to respond

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I reviewed the document and found a NIT using MUST not instead of MUST NOT.  It has been
    reported to the authors.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    Yes, every reference that I located had a valid reference.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are publicly available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    There are two different IANA request in this document.  A request for two new DHCPv6 messages and one new DHCPv6 option.

    DHCP message types require standard action, which the DHC working group reviewed.

      DHCP options require expect review from Bernie Volz, Ted Lemon, Tomek Mrugalski.  Bernie
      is the working group chair for DHC and commented on the draft several times.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    This document only impacts existing IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2024-03-26
10 Timothy Winters IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-03-26
10 Timothy Winters IESG state changed to Publication Requested from I-D Exists
2024-03-26
10 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-03-26
10 Timothy Winters Responsible AD changed to Éric Vyncke
2024-03-26
10 Timothy Winters Document is now in IESG state Publication Requested
2024-03-25
10 Jen Linkova New version available: draft-ietf-dhc-addr-notification-10.txt
2024-03-25
10 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-03-25
10 Jen Linkova Uploaded new revision
2024-03-25
09 Timothy Winters
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the …
# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  This document seemed to reach consensus of the DHC working group.  Review was
  done by several members of the group during it's life cycle.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No, this document went thru a normal working group process.  It had good discussion
  during meetings and on the mailing list.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  An implementation is in progress on Android at https://r.android.com/2709341 .

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  This is a document did get an DNSDIR review, but as the reviewer noted there is little
  actual DNS in the document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  As document shepherd, I reviewed this document to assure that it is following
  the WG consensus and discussions and is of good quality. In my opinion, the
  document is ready for publication.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    This document was reviewed by the DHC working group with no impact on other working groups.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    The RFC requested is Proposed Standard. This is appropriate for this
    document as it defines a method for informing DHCPv6 Servers of self-generated or
    configured addresses.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
 
    Yes all the authors responded that they aren't aware of any IPR issues.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
 
    Yes, all the authors responded that they are willing to respond

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I reviewed the document and found a NIT using MUST not instead of MUST NOT.  It has been
    reported to the authors.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    Yes, every reference that I located had a valid reference.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are publicly available

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    There are no downward references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    N/A

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    There are two different IANA request in this document.  A request for two new DHCPv6 messages and one new DHCPv6 option.

    DHCP message types require standard action, which the DHC working group reviewed.

      DHCP options require expect review from Bernie Volz, Ted Lemon, Tomek Mrugalski.  Bernie
      is the working group chair for DHC and commented on the draft several times.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    This document only impacts existing IANA registries.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

2024-03-04
09 Timothy Winters IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2024-01-30
09 Timothy Winters IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2024-01-26
09 Jen Linkova New version available: draft-ietf-dhc-addr-notification-09.txt
2024-01-26
09 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-01-26
09 Jen Linkova Uploaded new revision
2024-01-16
08 Jen Linkova New version available: draft-ietf-dhc-addr-notification-08.txt
2024-01-16
08 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2024-01-16
08 Jen Linkova Uploaded new revision
2023-12-04
07 Jen Linkova New version available: draft-ietf-dhc-addr-notification-07.txt
2023-12-04
07 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-12-04
07 Jen Linkova Uploaded new revision
2023-11-27
06 Timothy Winters Second Working Group Last CAll for this document.
2023-11-27
06 Timothy Winters IETF WG state changed to In WG Last Call from WG Document
2023-11-11
06 Jen Linkova New version available: draft-ietf-dhc-addr-notification-06.txt
2023-11-11
06 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-11-11
06 Jen Linkova Uploaded new revision
2023-10-23
05 Jen Linkova New version available: draft-ietf-dhc-addr-notification-05.txt
2023-10-23
05 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-10-23
05 Jen Linkova Uploaded new revision
2023-10-16
04 Bernie Volz Added to session: IETF-118: dhc  Wed-1200
2023-08-29
04 Warren Kumari New version available: draft-ietf-dhc-addr-notification-04.txt
2023-08-29
04 Warren Kumari New version approved
2023-08-29
04 (System) Request for posting confirmation emailed to previous authors: Jen Linkova , Lorenzo Colitti , Rajiv Asati , Sheng Jiang , Suresh Krishnan , Warren Kumari
2023-08-29
04 Warren Kumari Uploaded new revision
2023-08-16
03 Jen Linkova New version available: draft-ietf-dhc-addr-notification-03.txt
2023-08-16
03 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-08-16
03 Jen Linkova Uploaded new revision
2023-08-15
02 Jen Linkova New version available: draft-ietf-dhc-addr-notification-02.txt
2023-08-15
02 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-08-15
02 Jen Linkova Uploaded new revision
2023-08-01
01 Jen Linkova New version available: draft-ietf-dhc-addr-notification-01.txt
2023-08-01
01 Jen Linkova New version accepted (logged-in submitter: Jen Linkova)
2023-08-01
01 Jen Linkova Uploaded new revision
2023-06-29
00 Bernie Volz Changed consensus to Yes from Unknown
2023-06-29
00 Bernie Volz Intended Status changed to Proposed Standard from None
2023-06-29
00 Bernie Volz Notification list changed to tim@qacafe.com because the document shepherd was set
2023-06-29
00 Bernie Volz Document shepherd changed to Timothy Winters
2023-06-27
00 Bernie Volz Added to session: IETF-117: dhc  Tue-0030
2023-06-23
00 Timothy Winters This document now replaces draft-wkumari-dhc-addr-notification instead of None
2023-06-23
00 Jen Linkova New version available: draft-ietf-dhc-addr-notification-00.txt
2023-06-23
00 Timothy Winters WG -00 approved
2023-06-23
00 Jen Linkova Set submitter to "Jen Linkova ", replaces to draft-wkumari-dhc-addr-notification and sent approval email to group chairs: dhc-chairs@ietf.org
2023-06-23
00 Jen Linkova Uploaded new revision