Skip to main content

DHCPv6 Options for Home Network Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-24

Revision differences

Document history

Date Rev. By Action
2024-01-28
(System)
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-homenet-naming-architecture-dhc-options and RFC 9527, changed IESG state to RFC …
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-homenet-naming-architecture-dhc-options and RFC 9527, changed IESG state to RFC Published)
2024-01-18
24 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-12-18
24 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2023-12-18
24 (System) RFC Editor state changed to RFC-EDITOR
2023-11-21
24 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-08-15
24 (System) RFC Editor state changed to EDIT from MISSREF
2023-04-11
24 Carlos Jesús Bernardos Request closed, assignment withdrawn: Ron Bonica Last Call INTDIR review
2023-04-11
24 Carlos Jesús Bernardos Closed request for Last Call review by INTDIR with state 'Overtaken by Events'
2023-03-07
24 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2023-02-16
24 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2023-02-16
24 (System) IANA Action state changed to In Progress from Waiting on Authors
2023-02-02
24 (System) IANA Action state changed to Waiting on Authors from In Progress
2023-02-01
24 (System) RFC Editor state changed to MISSREF
2023-02-01
24 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-02-01
24 (System) Announcement was received by RFC Editor
2023-02-01
24 (System) IANA Action state changed to In Progress
2023-02-01
24 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-02-01
24 Cindy Morgan IESG has approved the document
2023-02-01
24 Cindy Morgan Closed "Approve" ballot
2023-02-01
24 Éric Vyncke Ballot approval text was changed
2023-02-01
24 Éric Vyncke Ballot approval text was generated
2023-02-01
24 Éric Vyncke Ballot approval text was generated
2023-02-01
24 Éric Vyncke
This document was put on hold until draft-ietf-homenet-front-end-naming-delegation was approved by the IESG. The downref to draft-ietf-homenet-front-end-naming-delegation was also approved by the IESG during the …
This document was put on hold until draft-ietf-homenet-front-end-naming-delegation was approved by the IESG. The downref to draft-ietf-homenet-front-end-naming-delegation was also approved by the IESG during the IESG telechat of 2023-01-26.
2023-02-01
24 (System) Removed all action holders (IESG state changed)
2023-02-01
24 Éric Vyncke IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2023-01-26
24 Amy Vezza Ballot approval text was generated
2023-01-16
24 Stephen Farrell

# Document Shepherd Writeup

*This version is dated 16 January 2023. Only change is to intended status.*

The most important thing to note about these …

# Document Shepherd Writeup

*This version is dated 16 January 2023. Only change is to intended status.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## 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?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

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

No particular controversy.

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

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

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?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

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

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

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

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

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.

No.

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][12]).

All good.

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.

N/A.


2023-01-16
24 Stephen Farrell Intended Status changed to Proposed Standard from Experimental
2023-01-16
24 Stephen Farrell

# Document Shepherd Writeup

*This version is dated 16 January 2023. Only change is to intended status.*

The most important thing to note about these …

# Document Shepherd Writeup

*This version is dated 16 January 2023. Only change is to intended status.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## 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?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

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

No particular controversy.

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

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

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?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

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

Experimental. (Following IETF LC and IEST discussion.)

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

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

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

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.

No.

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][12]).

All good.

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.

N/A.


2023-01-16
24 Stephen Farrell Intended Status changed to Experimental from Proposed Standard
2022-11-18
24 Paul Wouters
[Ballot comment]
My DISCUSS was resolved. There is AXFR using mutual TLS.

OLD DISCUSS:

This might be my misunderstanding of homenet, so hopefully easy to …
[Ballot comment]
My DISCUSS was resolved. There is AXFR using mutual TLS.

OLD DISCUSS:

This might be my misunderstanding of homenet, so hopefully easy to resolve.

The HNA (hidden primary?) to DM (primary) DNS communication using DNS Update needs some kind of authentication, TSIG or SIG0 ? While TLS gives you privacy, the DNS Update cannot be done with only TLS (as far as I understand it). I don't see any DHCP options to relay authentication information for automatic deployment? So I don't understand how this would startup and be able to setup a secure DNS update channel ?

There was also talk about using ACME for TLS certificates, but wouldn't that require that the HNA already has a provisioned and working homenet domain ? (possibly more a question for the other draft, but just adding it here in case the hidden primary to primary is an "almost DNS Update" protocol that uses TLS instead f TSIG/SIG0.
2022-11-18
24 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss
2022-10-31
24 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-24.txt
2022-10-31
24 Jenny Bui Forced post of submission
2022-10-31
24 (System) Request for posting confirmation emailed to previous authors: Daniel Migault , Ralf Weber , Tomek Mrugalski
2022-10-31
24 Daniel Migault Uploaded new revision
2022-10-24
23 Lars Eggert
[Ballot comment]
# GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY …
[Ballot comment]
# GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY).

## Comments

I still think it is shortsighted to not include port numbers in the
Supported Transport field, but the current text at least makes it clear
that out-of-band agreement is needed because of this limitation.

### IANA

The IANA review of this document seems to not have concluded yet.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `her`; alternatives might be `they`, `them`, `their`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2, paragraph 3
```
-    to.  ISPs may leverage such infrastructure and provide the homenet
+    to.  ISPs may leverage such infrastructure and provide the home network
+                                                                  +  ++++
```

### Outdated references

Document references `draft-sury-dnsext-cname-dname-00`, but `-01` is the latest
available revision.

### Grammar/style

#### Paragraph 1
```
s document defines DHCPv6 options so an Homenet Naming Authority (HNA) can a
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 3, paragraph 4
```
6 options provide the necessary non optional parameters described in Appendi
                                ^^^^^^^^^^^^
```
This expression is usually spelled with a hyphen.

#### Section 4.3, paragraph 2
```
represents a supported transport, and a RDM MAY indicate the support of multi
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.3, paragraph 6
```
FC8415] govern server operation in regards to option assignment. As a conveni
                                ^^^^^^^^^^^^^
```
Use "in regard to", "with regard to", or more simply "regarding".

#### "A.3.", paragraph 4
```
cribed in Appendix A.2, the HNA is expect to be able to handle multiple Home
                                  ^^^^^^
```
Consider using either the past participle "expected" or the present participle
"expecting" here.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2022-10-24
23 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2022-10-23
23 (System) Changed action holders to Éric Vyncke (IESG state changed)
2022-10-23
23 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-10-23
23 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-10-23
23 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-23.txt
2022-10-23
23 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-10-23
23 Daniel Migault Uploaded new revision
2022-10-20
22 (System) Changed action holders to Éric Vyncke, Daniel Migault, Ralf Weber, Tomek Mrugalski (IESG state changed)
2022-10-20
22 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-10-20
22 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-10-20
22 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this document. I am supporting Lars's discuss to clarify the implication of a non standard port usage.

I also …
[Ballot comment]
Thanks for working on this document. I am supporting Lars's discuss to clarify the implication of a non standard port usage.

I also think this paragraph

  It is worth noticing that the Supported Transport field does not enable to specify a port and the used port is defined by a standard. In the case of DNS over TLS [RFC7858], the port is defined by [RFC7858] to be 853. The need for such flexibility has been balanced with the difficulty of handling a list of tuples ( transport, port ) as well as the possibility to use a dedicated IP address for the DM.

should be moved to section 4.4 if this consideration is also true for section 4.3.
2022-10-20
22 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-10-20
22 Lars Eggert
[Ballot discuss]
# GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY …
[Ballot discuss]
# GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY).

## Discuss

### Section 4.2, paragraph 8
```
    It is worth noticing that the Supported Transport field does not
    enable to specify a port and the used port is defined by a standard.
    In the case of DNS over TLS [RFC7858], the port is defined by
    [RFC7858] to be 853.  The need for such flexibility has been balanced
    with the difficulty of handling a list of tuples ( transport, port )
    as well as the possibility to use a dedicated IP address for the DM.
```
7858 actually says

  By default, a DNS server that supports DNS over TLS MUST listen for
  and accept TCP connections on port 853, unless it has mutual
  agreement with its clients to use a port other than 853 for DNS over
  TLS.

So it is fully permissible for a DoT server to run on a different port under
such a mutual agreement. In general, for other possible transports, just because
a port is assigned for use does not mean a deployment is obligated to run on it.
2022-10-20
22 Lars Eggert
[Ballot comment]
## Comments

### IANA

The IANA review of this document seems to not have concluded yet.

### Inclusive language

Found terminology that should …
[Ballot comment]
## Comments

### IANA

The IANA review of this document seems to not have concluded yet.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `her`; alternatives might be `they`, `them`, `their`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2, paragraph 3
```
-    to.  ISPs may leverage such infrastructure and provide the homenet
+    to.  ISPs may leverage such infrastructure and provide the home network
+                                                                  +  ++++
```

### Outdated references

Document references `draft-sury-dnsext-cname-dname-00`, but `-01` is the latest
available revision.

### Grammar/style

#### Paragraph 1
```
s document defines DHCPv6 options so an Homenet Naming Authority (HNA) can a
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 3, paragraph 4
```
6 options provide the necessary non optional parameters described in Appendi
                                ^^^^^^^^^^^^
```
This expression is usually spelled with a hyphen.

#### Section 4.3, paragraph 2
```
represents a supported transport, and a RDM MAY indicate the support of multi
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.3, paragraph 6
```
FC8415] govern server operation in regards to option assignment. As a conveni
                                ^^^^^^^^^^^^^
```
Use "in regard to", "with regard to", or more simply "regarding".

#### "A.3.", paragraph 4
```
cribed in Appendix A.2, the HNA is expect to be able to handle multiple Home
                                  ^^^^^^
```
Consider using either the past participle "expected" or the present participle
"expecting" here.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool
2022-10-20
22 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to Discuss from No Record
2022-10-20
22 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-10-20
22 John Scudder [Ballot comment]
Thanks for addressing my DISCUSS and comments.

https://mailarchive.ietf.org/arch/msg/homenet/-VwL5Qzxn-nc2_Tf70vAjjUuOtM/
2022-10-20
22 John Scudder [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss
2022-10-20
22 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Record from Abstain
2022-10-20
22 Lars Eggert
[Ballot comment]
I agree with the Discusses and Comments on this document - this simply isn't implementable as described.

My main reason for abstaining is …
[Ballot comment]
I agree with the Discusses and Comments on this document - this simply isn't implementable as described.

My main reason for abstaining is something else though. This document has been worked on for almost ten years. While in the beginning, we might have expected or at least hoped that a solution in the shape that this document tries to describe would see adoption, it's become very clear that dynamic DNS services as described in Section 4 have won out here. These services are far from perfect, but at least some of the limitations in Section 4 have been addressed, and others are arguably a feature and not a limitation.
2022-10-20
22 Lars Eggert [Ballot Position Update] New position, Abstain, has been recorded for Lars Eggert
2022-10-20
22 Erik Kline
[Ballot comment]
# Internet AD comments for {draft-ietf-homenet-naming-architecture-dhc-options-22}
CC @ekline

## Comments

* I wonder if it's possible to include some mention that …
[Ballot comment]
# Internet AD comments for {draft-ietf-homenet-naming-architecture-dhc-options-22}
CC @ekline

## Comments

* I wonder if it's possible to include some mention that when a prefix
  (IA_PD) is changed and the OPTION_REVERSE_DIST_MANAGER has changed (perhaps
  because a region is being split into smaller units and the infrastructure
  is shifting) that the OPTION_REVERSE_DIST_MANAGER option SHOULD be sent
  along with the new IA_PD.
2022-10-20
22 Erik Kline [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss
2022-10-19
22 Erik Kline
[Ballot discuss]
# Internet AD comments for {draft-ietf-homenet-naming-architecture-dhc-options-22}
CC @ekline

## Discuss

* I'll go one further than John and just hold a …
[Ballot discuss]
# Internet AD comments for {draft-ietf-homenet-naming-architecture-dhc-options-22}
CC @ekline

## Discuss

* I'll go one further than John and just hold a DISCUSS until DISCUSSes on
  I-D.ietf-homenet-front-end-naming-delegation are all cleared.
2022-10-19
22 Erik Kline [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline
2022-10-19
22 Murray Kucherawy [Ballot comment]
Thanks to Bron Gondwana for his ARTART review.
2022-10-19
22 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-10-19
22 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-10-19
22 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-22.txt
2022-10-19
22 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-10-19
22 Daniel Migault Uploaded new revision
2022-10-19
21 Paul Wouters
[Ballot discuss]
This might be my misunderstanding of homenet, so hopefully easy to resolve.

The HNA (hidden primary?) to DM (primary) DNS communication using DNS …
[Ballot discuss]
This might be my misunderstanding of homenet, so hopefully easy to resolve.

The HNA (hidden primary?) to DM (primary) DNS communication using DNS Update needs some kind of authentication, TSIG or SIG0 ? While TLS gives you privacy, the DNS Update cannot be done with only TLS (as far as I understand it). I don't see any DHCP options to relay authentication information for automatic deployment? So I don't understand how this would startup and be able to setup a secure DNS update channel ?

There was also talk about using ACME for TLS certificates, but wouldn't that require that the HNA already has a provisioned and working homenet domain ? (possibly more a question for the other draft, but just adding it here in case the hidden primary to primary is an "almost DNS Update" protocol that uses TLS instead f TSIG/SIG0.
2022-10-19
21 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2022-10-19
21 Roman Danyliw
[Ballot comment]
Thank you to Hilarie Orman for the SECDIR review.  This review has a list of actionable comments the authors should consider.  In particular, …
[Ballot comment]
Thank you to Hilarie Orman for the SECDIR review.  This review has a list of actionable comments the authors should consider.  In particular, see the feedback on the framing of the Security Considerations language.

** Section 2.
  In addition, ISPs often identify the line of the home network with a
  name. 

Is the referenced “line” here talking about the physical cable?  Should this language generalized to capture fixed wireless technology?

** Section 2.

  Such name is used for their internal network management
  operations and is not a name the home network owner has registered
  to. 

Could this be rephrased to explain the idea of a name “that the home network owner hasn’t registered.”

** Section 3.

Note also that this is not
  mandatory and the DHCPv6 client may instruct remotely the HNA and the
  DHCPv6 either with a proprietary protocol or a protocol that will be
  defined in the future.

I had trouble parsing this sentence.  What is the proprietary protocol related to DHCPv6?

** Section 3.

  This scenario is believed to be the most popular scenario

Is this statement based on deployment experience or speculative about how deployments will be configured?  If the latter, this text should likely read: “This scenario is believe to be the most popular scenario”?

** Section 3.  The steps in the scenario are numbered 1, 2, 1.  Is that an error?  Maybe, 1, 2, 3.

** Section 3.
The HNA is authenticated (see Section 4.6 of
      [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the
      RDM. 

As pointed out in the draft-ietf-homenet-front-end-naming-delegation ballot, this authentication is not mandatory.

** Section 4.2.  Editorial.  Sentence doesn’t parse.

OLD
  It is worth noticing that the Supported Transport field does not
  enable to specify a port and the used port is defined by standard.
  In the case of DNS over TLS [RFC7858], the port is defined by
  [RFC7858] to be 853. 

NEW
Note that the Supported Transport field does not enable the specification of a port. The default port for the protocol identified by the Supported Transport field is assumed.  In the case of DNS over TLS [RFC7858], the default port is 853 [RFC7858].
2022-10-19
21 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-10-18
21 John Scudder
[Ballot comment]
# John Scudder, RTG AD comments for draft-ietf-homenet-naming-architecture-dhc-options-21

CC @jgscudder

## COMMENTS

Thanks for your work on this document. I had difficulty making …
[Ballot comment]
# John Scudder, RTG AD comments for draft-ietf-homenet-naming-architecture-dhc-options-21

CC @jgscudder

## COMMENTS

Thanks for your work on this document. I had difficulty making sense out of some parts of it, but mostly with explanatory text and not with the normative parts, so I'm content to let these be comments and not part of my DISCUSS. I hope they help.

### Section 3

~~~
  Note also that this is not
  mandatory and the DHCPv6 client may instruct remotely the HNA and the
  DHCPv6 either with a proprietary protocol or a protocol that will be
  defined in the future.
~~~

This didn't scan right for me, for several reasons. First, a "protocol that will be defined in the future" could easily enough be a proprietary one, so the two things aren't actually non-overlapping -- maybe you meant "a protocol that will be standardized in the future" or something. But really, I think if you want to say the protocol to do this is beyond the scope of this document, you should say exactly that, and no more (no need to go into guessing about whether it will be proprietary or not).

But after I started writing this comment, I realized I have a bigger problem with the quoted text, which is I don't actually know what it means. :-( What does it mean for the DHCPv6 client to "instruct remotely the DHCPv6"? AFAICT "DHCPv6" is either an adjective (as when applied to "client" or "server") or it's a noun that names the abstract entity which is the DHCPv6 protocol. But the client isn't instructing the abstract protocol definition, and it's not instructing an adjective either. So I'm just confused. Maybe the words "and the DHCPv6" just need to be removed??

I think this needs a rewrite.

### Section 3

Continuing immediately after the previous, we have

~~~
  In addition, this section assumes the
  responsible entity for the DHCPv6 server is configured with the DM
  and RDM.
~~~

By any chance did you mean "colocated" where you wrote "configured"? If not, then I don't understand what you're getting at here.

### Section 3

And again continuing on, we have

~~~
  This means a Registered Homenet Domain can be associated to
  the DHCPv6 client.
~~~

I think you probably mean "associated with" and aren't using "associated to" in some technical way? If so I would say to use the more idiomatic "associated with" (and the same in your later use of "associated to" in Section 4.1)... except maybe "identified with" might be more accurate here, in the sense of there existing a 1:1 mapping between a Registered Homenet Domain and the DHCPv6 client?

### Section 3

~~~
  2.  The DHCPv6 server responds to the HNA with the requested DHCPv6
      options based on the identified homenet.  The DHCPv6 client
      passes the information to the HNA.
~~~

Wouldn't it be more accurate to say "... responds to the DHCPv6 client with the requested ..."? I get the point (I think) but as written it doesn't follow cleanly.

### Section 3

Later in the section we have

~~~
  1.  The HNA is authenticated (see Section 4.6 of
      [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the
      RDM.  The HNA builds the Homenet Zone (or the Homenet Reverse
      Zone) and proceed as described in
      [I-D.ietf-homenet-front-end-naming-delegation].  The DHCPv6
      options provide the necessary non optional parameters described
      in Appendix B of [I-D.ietf-homenet-front-end-naming-delegation].
      The HNA may complement the configurations with additional
      parameters via means not yet defined.  Appendix B of
      [I-D.ietf-homenet-front-end-naming-delegation] describes such
      parameters that MAY take some specific non default value.
~~~

(As an aside, this is the third item in the list but is numbered 1, I guess a glitch in the document source.)

The final sentence has an RFC 2119 "MAY", this seems out of place since you're describing a requirement imposed in a different specification, not imposing the requirement yourself. I think you should use the common lower-case "may" here, or "can", or similar. Or you could say "... describes optional parameters that can take some..."

Also a question, are the "means not yet defined" going to be additional DHCPv6 options? If so, maybe say that specifically? Or are you intentionally leaving it completely open?

### Section 4.1

As mentioned earlier, I suggest the more idiomatic "associated with" rather than "associated to".

### Section 4.2

I don't understand this text:

~~~
  Then the FQDN can reasonably be seen as a more stable identifier as
  well as a pointer to additional information than the IP addresses may
  be useful to in the future to establish the communication between the
  HNA and the DM.
~~~

I can take some guesses, but I can't unambiguously parse it. I think it needs a rewrite for grammar and clarity. (Or remove, if you don't feel it's needed -- I can't tell.)

### Section 4.4

Please be explicit about bit positions -- are you counting from the left, or right? Please also update Section 6 with this information.

### Section 5.2

I'm not a DHCPv6 (or DHCP) expert so please help me out -- am I correct that there's no concept of a lease that applies to the options defined in this document? 

My concern comes from musing about whether there's a need to talk about what must happen if a client retrieves a set of parameters, does things based on them, later retrieves the parameters again and the new ones don't match the old ones. If the parameters were subject to lease expiration, this would be an expected part of the lifecycle of the protocol and would probably merit discussion. But, if they aren't subject to expiration, then I think it's OK as it stands.

## NITS

### Appendix B

It looks like this should really be A.1, not a new major heading/appendix of its own, probably a glitch in your document source?

### Appendix B.2

Where you say "CE router" do you really mean "CPE router"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2022-10-18
21 John Scudder Ballot comment text updated for John Scudder
2022-10-18
21 John Scudder
[Ballot discuss]
I have one blocking DISCUSS point, which should be easily taken care of -- it seems like [I-D.ietf-homenet-front-end-naming-delegation] needs to be …
[Ballot discuss]
I have one blocking DISCUSS point, which should be easily taken care of -- it seems like [I-D.ietf-homenet-front-end-naming-delegation] needs to be Normative, not Informative.  (For one thing, Section 1 tells us that "The reader should be familiar with [I-D.ietf-homenet-front-end-naming-delegation]".)
2022-10-18
21 John Scudder
[Ballot comment]
# John Scudder, RTG AD comments for draft-ietf-homenet-naming-architecture-dhc-options-21
CC @jgscudder

## COMMENTS

Thanks for your work on this document. I had difficulty making …
[Ballot comment]
# John Scudder, RTG AD comments for draft-ietf-homenet-naming-architecture-dhc-options-21
CC @jgscudder

## COMMENTS

Thanks for your work on this document. I had difficulty making sense out of some parts of it, but mostly with explanatory text and not with the normative parts, so I'm content to let these be comments and not part of my DISCUSS. I hope they help.

### Section 3

~~~
  Note also that this is not
  mandatory and the DHCPv6 client may instruct remotely the HNA and the
  DHCPv6 either with a proprietary protocol or a protocol that will be
  defined in the future.
~~~

This didn't scan right for me, for several reasons. First, a "protocol that will be defined in the future" could easily enough be a proprietary one, so the two things aren't actually non-overlapping -- maybe you meant "a protocol that will be standardized in the future" or something. But really, I think if you want to say the protocol to do this is beyond the scope of this document, you should say exactly that, and no more (no need to go into guessing about whether it will be proprietary or not).

But after I started writing this comment, I realized I have a bigger problem with the quoted text, which is I don't actually know what it means. :-( What does it mean for the DHCPv6 client to "instruct remotely the DHCPv6"? AFAICT "DHCPv6" is either an adjective (as when applied to "client" or "server") or it's a noun that names the abstract entity which is the DHCPv6 protocol. But the client isn't instructing the abstract protocol definition, and it's not instructing an adjective either. So I'm just confused. Maybe the words "and the DHCPv6" just need to be removed??

I think this needs a rewrite.

### Section 3

Continuing immediately after the previous, we have

~~~
  In addition, this section assumes the
  responsible entity for the DHCPv6 server is configured with the DM
  and RDM.
~~~

By any chance did you mean "colocated" where you wrote "configured"? If not, then I don't understand what you're getting at here.

### Section 3

And again continuing on, we have

~~~
  This means a Registered Homenet Domain can be associated to
  the DHCPv6 client.
~~~

I think you probably mean "associated with" and aren't using "associated to" in some technical way? If so I would say to use the more idiomatic "associated with" (and the same in your later use of "associated to" in Section 4.1)... except maybe "identified with" might be more accurate here, in the sense of there existing a 1:1 mapping between a Registered Homenet Domain and the DHCPv6 client?

### Section 3

~~~
  2.  The DHCPv6 server responds to the HNA with the requested DHCPv6
      options based on the identified homenet.  The DHCPv6 client
      passes the information to the HNA.
~~~

Wouldn't it be more accurate to say "... responds to the DHCPv6 client with the requested ..."? I get the point (I think) but as written it doesn't follow cleanly.

### Section 3

Later in the section we have

~~~
  1.  The HNA is authenticated (see Section 4.6 of
      [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the
      RDM.  The HNA builds the Homenet Zone (or the Homenet Reverse
      Zone) and proceed as described in
      [I-D.ietf-homenet-front-end-naming-delegation].  The DHCPv6
      options provide the necessary non optional parameters described
      in Appendix B of [I-D.ietf-homenet-front-end-naming-delegation].
      The HNA may complement the configurations with additional
      parameters via means not yet defined.  Appendix B of
      [I-D.ietf-homenet-front-end-naming-delegation] describes such
      parameters that MAY take some specific non default value.
~~~

(As an aside, this is the third item in the list but is numbered 1, I guess a glitch in the document source.)

The final sentence has an RFC 2119 "MAY", this seems out of place since you're describing a requirement imposed in a different specification, not imposing the requirement yourself. I think you should use the common lower-case "may" here, or "can", or similar. Or you could say "... describes optional parameters that can take some..."

Also a question, are the "means not yet defined" going to be additional DHCPv6 options? If so, maybe say that specifically? Or are you intentionally leaving it completely open?

### Section 4.1

As mentioned earlier, I suggest the more idiomatic "associated with" rather than "associated to".

### Section 4.2

I don't understand this text:

~~~
  Then the FQDN can reasonably be seen as a more stable identifier as
  well as a pointer to additional information than the IP addresses may
  be useful to in the future to establish the communication between the
  HNA and the DM.
~~~

I can take some guesses, but I can't unambiguously parse it. I think it needs a rewrite for grammar and clarity. (Or remove, if you don't feel it's needed -- I can't tell.)

### Section 4.4

Please be explicit about bit positions -- are you counting from the left, or right? Please also update Section 6 with this information.

### Section 5.2

I'm not a DHCPv6 (or DHCP) expert so please help me out -- am I correct that there's no concept of a lease that applies to the options defined in this document? 

My concern comes from musing about whether there's a need to talk about what must happen if a client retrieves a set of parameters, does things based on them, later retrieves the parameters again and the new ones don't match the old ones. If the parameters were subject to lease expiration, this would be an expected part of the lifecycle of the protocol and would probably merit discussion. But, if they aren't subject to expiration, then I think it's OK as it stands.

## NITS

### Appendix B

It looks like this should really be A.1, not a new major heading/appendix of its own, probably a glitch in your document source?

### Appendix B.2

Where you say "CE router" do you really mean "CPE router"?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2022-10-18
21 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2022-10-17
21 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-10-14
21 R. Gieben Request for Telechat review by DNSDIR Completed: Ready with Nits. Reviewer: R. Gieben. Sent review to list.
2022-10-13
21 Tero Kivinen Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Hilarie Orman. Submission of review completed at an earlier date.
2022-10-12
21 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-10-10
21 Jim Reid Request for Telechat review by DNSDIR is assigned to R. Gieben
2022-10-10
21 Jim Reid Request for Telechat review by DNSDIR is assigned to R. Gieben
2022-10-08
21 Tero Kivinen Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Hilarie Orman.
2022-10-06
21 Al Morton Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Al Morton. Sent review to list.
2022-10-06
21 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Al Morton
2022-10-06
21 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Al Morton
2022-10-05
21 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2022-10-04
21 Bron Gondwana Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. Sent review to list.
2022-10-04
21 Ines Robles Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Ines Robles. Sent review to list.
2022-10-04
21 Éric Vyncke Placed on agenda for telechat - 2022-10-20
2022-10-04
21 Éric Vyncke Ballot has been issued
2022-10-04
21 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2022-10-04
21 Éric Vyncke Created "Approve" ballot
2022-10-04
21 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for Writeup
2022-10-04
21 Éric Vyncke Ballot writeup was changed
2022-10-04
21 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-10-03
21 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2022-10-03
21 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-21.txt
2022-10-03
21 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-10-03
21 Daniel Migault Uploaded new revision
2022-10-03
20 David Dong IANA Experts State changed to Reviews assigned
2022-10-03
20 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2022-10-03
20 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-homenet-naming-architecture-dhc-options-20. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-homenet-naming-architecture-dhc-options-20. If any part of this review is inaccurate, please let us know.

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

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

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

three new option codes will be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_REGISTERED_DOMAIN
Client ORO: Yes
Singleton Option: No
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_FORWARD_DIST_MANAGER
Client ORO: Yes
Singleton Option: Yes
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_REVERSE_DIST_MANAGER
Client ORO: Yes
Singleton Option: Yes
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (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, a new registry is to be created called the Supported Transport parameter registry.

NOTE: In accordance with current practice, IANA prefers to leave the string "Parameters" out of the name of a new registry grouping, unless doing so will cause confusion. Please let us know if there will be any issues with using the term "Supported Transport" instead of "Supported Transport Parameters."

The new registry will be located on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

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

The description for the new registry will be:

"The Supported Transport field of the DHCPv6 option is a two byte field that indicates the supported transport protocols. Each bit represents a specific transport mechanism."

The registration policy for the new registry is RFC Required as defined in RFC 8126. There is an initial registration in the new registry as follows:

Bit Position | Transport Protocol Description | Mnemonic | Reference
-------------+--------------------------------+-----------+--------------
0 | DNS over TLS | DoT | [ RFC-to-be ]
1-15 | unallocated | - | -

The IANA Functions Operator understands that these are the only actions 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 Specialist
2022-09-28
20 Al Morton Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Al Morton. Sent review to list.
2022-09-24
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2022-09-24
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2022-09-24
20 Adam Montville Assignment of request for Last Call review by SECDIR to Adam Montville was rejected
2022-09-23
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2022-09-23
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Adam Montville
2022-09-22
20 Barry Leiba Request for Last Call review by ARTART is assigned to Bron Gondwana
2022-09-22
20 Barry Leiba Request for Last Call review by ARTART is assigned to Bron Gondwana
2022-09-21
20 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2022-09-21
20 Jean Mahoney Request for Last Call review by GENART is assigned to Ines Robles
2022-09-21
20 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2022-09-21
20 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2022-09-20
20 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-20.txt
2022-09-20
20 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-09-20
20 Daniel Migault Uploaded new revision
2022-09-20
19 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Ron Bonica
2022-09-20
19 Carlos Jesús Bernardos Request for Last Call review by INTDIR is assigned to Ron Bonica
2022-09-20
19 Éric Vyncke Requested Last Call review by INTDIR
2022-09-20
19 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-09-20
19 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-10-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-homenet-naming-architecture-dhc-options@ietf.org, evyncke@cisco.com, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie …
The following Last Call announcement was sent out (ends 2022-10-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-homenet-naming-architecture-dhc-options@ietf.org, evyncke@cisco.com, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DHCPv6 Options for Home Network Naming Authority) to Proposed Standard


The IESG has received a request from the Home Networking WG (homenet) to
consider the following document: - 'DHCPv6 Options for Home Network Naming
Authority'
  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 2022-10-04. 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 DHCPv6 options so an Homenet Naming Authority
  (HNA) can automatically proceed to the appropriate configuration and
  outsource the authoritative naming service for the home network.  In
  most cases, the outsourcing mechanism is transparent for the end
  user.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/



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




2022-09-20
19 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-09-20
19 Éric Vyncke Last call was requested
2022-09-20
19 Éric Vyncke Last call announcement was generated
2022-09-20
19 Éric Vyncke Ballot writeup was generated
2022-09-20
19 Éric Vyncke (Note to be sent with the IETF Last Call)

The suggested reading order is:
- draft-ietf-homenet-front-end-naming-delegation
- draft-ietf-homenet-naming-architecture-dhc-options
2022-09-20
19 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2022-09-20
19 Éric Vyncke Ballot approval text was generated
2022-09-20
19 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-19.txt
2022-09-20
19 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-09-20
19 Daniel Migault Uploaded new revision
2022-09-20
18 (System) Changed action holders to Éric Vyncke (IESG state changed)
2022-09-20
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-09-20
18 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-18.txt
2022-09-20
18 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-09-20
18 Daniel Migault Uploaded new revision
2022-09-20
17 Éric Vyncke Minor fix to IANA section to be done https://mailarchive.ietf.org/arch/msg/homenet/TrTrF5-yhH7eKpcikNSIvHIYT3c/
2022-09-20
17 (System) Changed action holders to Éric Vyncke, Daniel Migault, Ralf Weber, Tomek Mrugalski (IESG state changed)
2022-09-20
17 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2022-09-16
17 (System) Changed action holders to Éric Vyncke (IESG state changed)
2022-09-16
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-09-16
17 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-17.txt
2022-09-16
17 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-09-16
17 Daniel Migault Uploaded new revision
2022-08-08
16 Éric Vyncke AD review sent as https://mailarchive.ietf.org/arch/msg/homenet/jM1oxFsXmcnkVj3ziMS5v6A1dqY/
2022-08-08
16 (System) Changed action holders to Éric Vyncke, Daniel Migault, Ralf Weber, Tomek Mrugalski (IESG state changed)
2022-08-08
16 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2022-07-28
16 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-16.txt
2022-07-28
16 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-07-28
16 Daniel Migault Uploaded new revision
2022-07-11
15 Éric Vyncke
Stephen, as the doc shepherd, can you check whether Tomek still agrees to be listed as author ? Can you also justify the intended status …
Stephen, as the doc shepherd, can you check whether Tomek still agrees to be listed as author ? Can you also justify the intended status of "PS" ? The IANA section should also mention the expert review required by https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2
;-)
Thank you
-éric
2022-07-11
15 Éric Vyncke IESG state changed to AD Evaluation from Publication Requested
2022-07-11
15 Kiran Makhijani

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) …

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## 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?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

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

No particular controversy.

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

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

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?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

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

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

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

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

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.

No.

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][12]).

All good.

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.

N/A.


2022-07-11
15 Kiran Makhijani IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2022-07-11
15 Kiran Makhijani IESG state changed to Publication Requested from I-D Exists
2022-07-11
15 (System) Changed action holders to Éric Vyncke (IESG state changed)
2022-07-11
15 Kiran Makhijani IESG process started in state Publication Requested
2022-07-11
15 Kiran Makhijani Tag Doc Shepherd Follow-up Underway cleared.
2022-07-11
15 Stephen Farrell

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) …

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## 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?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

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

No particular controversy.

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

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

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?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

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

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

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

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

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.

No.

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][12]).

All good.

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.

N/A.


2022-07-11
15 Stephen Farrell

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) …

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## 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?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

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

No particular controversy.

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

No. (but CHECK)

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

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?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

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

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

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

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

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.

No.

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][12]).

All good.

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.

N/A.


2022-07-04
15 Stephen Farrell Changed consensus to Yes from Unknown
2022-07-04
15 Stephen Farrell Intended Status changed to Proposed Standard from None
2022-07-04
15 Stephen Farrell Notification list changed to stephen.farrell@cs.tcd.ie because the document shepherd was set
2022-07-04
15 Stephen Farrell Document shepherd changed to Stephen Farrell
2022-06-29
15 Kiran Makhijani Tag Doc Shepherd Follow-up Underway set.
2022-06-29
15 Kiran Makhijani IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2022-06-13
15 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-15.txt
2022-06-13
15 Daniel Migault New version accepted (logged-in submitter: Daniel Migault)
2022-06-13
15 Daniel Migault Uploaded new revision
2021-11-14
14 (System) Document has expired
2021-05-13
14 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-14.txt
2021-05-13
14 (System) New version accepted (logged-in submitter: Daniel Migault)
2021-05-13
14 Daniel Migault Uploaded new revision
2021-05-13
13 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-13.txt
2021-05-13
13 (System) New version accepted (logged-in submitter: Daniel Migault)
2021-05-13
13 Daniel Migault Uploaded new revision
2021-05-04
12 Barbara Stark IETF WG state changed to In WG Last Call from WG Document
2021-04-28
12 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-12.txt
2021-04-28
12 (System) New version accepted (logged-in submitter: Daniel Migault)
2021-04-28
12 Daniel Migault Uploaded new revision
2021-04-13
11 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-11.txt
2021-04-13
11 (System) New version accepted (logged-in submitter: Daniel Migault)
2021-04-13
11 Daniel Migault Uploaded new revision
2021-04-01
10 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-10.txt
2021-04-01
10 (System) New version approved
2021-04-01
10 (System) Request for posting confirmation emailed to previous authors: Chris Griffiths , Daniel Migault , Ralf Weber , Tomek Mrugalski , Wouter Cloetens
2021-04-01
10 Daniel Migault Uploaded new revision
2021-03-12
09 Barbara Stark Added to session: IETF-110: homenet  Fri-1300
2021-03-10
09 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-09.txt
2021-03-10
09 (System) New version accepted (logged-in submitter: Daniel Migault)
2021-03-10
09 Daniel Migault Uploaded new revision
2020-10-22
08 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-08.txt
2020-10-22
08 (System) New version accepted (logged-in submitter: Daniel Migault)
2020-10-22
08 Daniel Migault Uploaded new revision
2020-10-22
07 (System) Document has expired
2020-05-23
07 Éric Vyncke Shepherding AD changed to Éric Vyncke
2020-04-19
07 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-07.txt
2020-04-19
07 (System) New version accepted (logged-in submitter: Daniel Migault)
2020-04-19
07 Daniel Migault Uploaded new revision
2019-03-25
06 Stephen Farrell Added to session: IETF-104: homenet  Tue-0900
2018-12-28
06 (System) Document has expired
2018-07-14
06 Barbara Stark Added to session: IETF-102: homenet  Wed-1520
2018-06-26
06 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-06.txt
2018-06-26
06 (System) New version approved
2018-06-26
06 (System) Request for posting confirmation emailed to previous authors: Daniel Migault , Chris Griffiths , Ralf Weber , Tomek Mrugalski , Wouter Cloetens
2018-06-26
06 Daniel Migault Uploaded new revision
2018-04-30
05 (System) Document has expired
2017-10-27
05 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-05.txt
2017-10-27
05 (System) New version approved
2017-10-27
05 (System) Request for posting confirmation emailed to previous authors: Daniel Migault , Chris Griffiths , Ralf Weber , Tomek Mrugalski , Wouter Cloetens
2017-10-27
05 Daniel Migault Uploaded new revision
2017-02-16
04 (System) Document has expired
2016-08-15
04 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-04.txt
2015-10-19
03 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-03.txt
2015-05-19
02 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-02.txt
2015-02-17
01 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-01.txt
2014-09-19
00 Ray Bellis This document now replaces draft-mglt-homenet-naming-architecture-dhc-options instead of None
2014-09-19
00 Daniel Migault New version available: draft-ietf-homenet-naming-architecture-dhc-options-00.txt