Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS
draft-ietf-pim-ipv6-zeroconf-assignment-13

[Ballot discuss]
** Section 6.1.  The answers to the template questions #1-5 don’t appear to provide unambiguous answers?

    1. Because this mapping is closely-related
      to the local network, users SHOULD be aware that these names are
      likely to yield different results on different networks.

  2.  Application software SHOULD recognize these names as a reverse
      mapping domain and MAY associate them with the protocol described
      in this document.

  3.  Name resolution APIs and libraries SHOULD recognize these names
      as being used exclusively with mDNS, and so SHOULD NOT send
      queries for these names to their configured unicast DNS
      server(s).

  4.  Caching DNS servers SHOULD recognize these names as being used
      exclusively with mDNS, SHOULD NOT attempt to look up resource
      records associated with these names, and SHOULD respond to any
      query with NXDOMAIN.

  5.  Authoritative DNS servers SHOULD recognize these names as being
      used exclusively with mDNS and SHOULD respond to any query with
      NXDOMAIN.

Because questions #1-5 are answered with a SHOULD, the guidance to users, application software, APIs and DNS servers is unclear.  The template questions roughly are whether “ are expected to recognize these names as special and treat them differently?  If so, how?”  It isn’t clear when these names would not need to be recognized as special as it isn’t mandatory.

[Ballot discuss]
Section 2.4, Record Construction, PTRDNAME composition and A/AAAA note:

226 >    Once the domain name is assembled, the application SHALL construct a
227 >    unique PTR record using that domain name.  The PTRDNAME field of this
228 >    record SHALL consist of a unique application identifier, in the form
229 >    of one or more DNS labels, followed by the device's host name (for
230 >    example, "application.example.local.").  Integrating a unique
231 >    identifier in this manner allows for multiple applications to be on
232 >    the same host.
233 >
234 >    Note that A/AAAA records may also be published for this same host
235 >    name (for example, "example.local."), though this is not a
236 >    requirement for this design.

Collision detection in this protocol only works if two different senders
can never produce byte-identical PTR records. RFC 6762, Section 9 is
explicit that identical rdata is not a conflict:

>    What may be considered
>    inconsistent is context sensitive, except that resource records with
>    identical rdata are never considered inconsistent, even if they
>    originate from different hosts.

and Section 8.2.1 says the same for simultaneous probes ("there is, in
fact, no conflict"). So if two devices pick the same group ID and publish
the same PTRDNAME, neither probing, announcing, nor the continuous query
in Section 2.7 will ever flag it. Both will transmit on the same group.

As I read Section 2.4, the application identifier is unique only within
the host ("allows for multiple applications to be on the same host"), so
network-wide uniqueness of PTRDNAME rests entirely on the host name being
unique on the link. Nothing in the document ensures that. Host names
become unique in mDNS because the host probes for its address records and
renames on conflict, and the note above says publishing A/AAAA records
isn't required. Two identical devices running the same software with the
same default hostname, which is exactly what you'd expect on a vessel
with two or three of the same display model, would produce identical
PTRDNAMEs. The chance of them also choosing the same group ID is small,
but when it happens the failure is silent, and the mechanism that exists
to catch it is the thing that's defeated.

The fix looks easy. Either require that the host name used in PTRDNAME be
one the host has claimed as unique on the link via mDNS probing (RFC 6762,
Section 8.1), or require that the PTRDNAME as a whole be unique on the
link and say how an implementation achieves that (e.g., by including a
per-device identifier??). Could the authors pick one? Or a third method
that I cannot think of.

---

I support Ketan's DISCUSS on Section 4. A MUST to use an RFC 3306
address with no procedure for forming it or establishing its uniqueness
off-link isn't something an implementer can conform to, and from an
operations standpoint, it leaves the multi-subnet deployment that CONS-1
claims support for undefined.

[Ballot comment]
Section 1, Introduction, scalability and implicit availability paragraphs:

114 >    Scalability of mDNS is an area of ongoing research and improvement
115 >    ([RFC7558]).  The protocol described in this document is subject to
116 >    similar constraints.  Under normal operating conditions, mDNS traffic
117 >    is expected to grow linearly with the number of multicast streams.

Building on Med's COMMENT about a dedicated Operational Considerations
section: I'd gently suggest the authors look at
draft-ietf-opsawg-rfc5706bis for structure. In the shepherding AD review
thread, Nate said RFC 5706 Section 2 didn't have much that applied to a
zero-configuration protocol. I'd argue a few things do, and they're cheap
to write down:

- Visibility. Allocations are self-describing: an operator or diagnostic
  tool can browse "9.3.3.3.3.eth-addr.arpa" over mDNS and see every group
  ID in use and which application/host holds it. That's a useful property
  and worth saying.

- Fault reporting. RFC 6762, Section 9 (steps 4 and 5) recommends telling
  the user or operator when a name changes, and logging if no unique name
  can be found after a minute. The equivalent here would be logging group
  ID changes and, in particular, repeated vetoes or repeated conflicts for
  the same stream, which is the signature of either a misbehaving
  infrastructure component or the attack in Section 8.

- Persistent state. Section 2.9 makes stored group IDs part of the
  protocol. What happens on factory reset, on a device image cloned to
  many units, or when a unit moves to a different network, is
  operationally relevant. (Med's DISCUSS on binding the stored value to the
  network attachment touches the same thing.)

- Group changes. When a conflict or veto forces a sender onto a new group
  ID, receivers lose the stream until they rediscover the new address.
  How they do that is out of scope per CONS-6, but noting the disruption
  belongs with the rest of the operational picture.

- No YANG module. That's a reasonable choice for an application-level
  zeroconf mechanism, but rfc5706bis asks that it be a stated decision
  rather than an omission. One sentence would do.

---

Section 2.4 / Section 3, PTR and veto record TTL:

338 >    If an application transmitting a veto record determines that the PTR
339 >    record for the address causing the conflict has become invalid
340 >    (either due to receiving a goodbye packet or to record expiry), then

The document never says what TTL to use for the PTR record or the veto
record. Both Section 5.1 (how long detection takes after a partition is
repaired) and the veto-withdrawal logic above depend on it. RFC 6762,
Section 10 would give 120 seconds here, since the rdata contains a host
name, but an implementer has to work that out. Stating the expected TTL,
or explicitly pointing to RFC 6762, Section 10, would remove the
guesswork.

---

Section 3, Veto Records, withdrawal procedure:

338 >    If an application transmitting a veto record determines that the PTR
339 >    record for the address causing the conflict has become invalid
340 >    (either due to receiving a goodbye packet or to record expiry), then
341 >    it SHALL query the network for the PTR record.  If the application
342 >    does not receive a query response containing the PTR record after 5
343 >    seconds, then the application SHALL delay a random amount of time in
344 >    the range 20-120 ms and then send a goodbye packet that invalidates
345 >    the veto record.

Two things. First, the rest of Section 3 says veto records are published
by "network infrastructure components", not applications; this paragraph
switches to "an application transmitting a veto record". I assume the
same entity is meant, but the inconsistency matters because the
requirements on each are different. Second, where do the 5 seconds come
from? RFC 6762, Section 10.4 uses ten seconds for the analogous
reconfirmation. A short rationale for the values would help.

Related, and following Peter Yee's GENART question: Nate's answer on the
list was that switches doing multicast snooping are managed and have their
own host stack. That's fair, but it means veto support is an optional
capability of some infrastructure, and the protocol degrades to "no veto"
on switches that lack it. It's worth one sentence in Section 3 so nobody
reads CONS-7 as unconditional.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

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.

Section 2.4, label length:

238 >    To allow for the creation of veto records (Section 3), the first DNS
239 >    label of the application identifier SHALL NOT exceed 58 octets in
240 >    length.  This reflects the 63-byte limit specified in [RFC1035],
241 >    Section 2.3.4 while also reserving space for a 5-byte suffix.

s/63-byte limit/63-octet limit/ and s/5-byte suffix/5-octet suffix/ for
consistency with "58 octets".

Section 2.7, second paragraph:

276 >    The host network stack may optionally monitor the network for traffic

s/may optionally monitor/may monitor/

Section 3, first paragraph:

311 >    Veto records are used to address collisions that occur in the network
312 >    infrastructure (for example, the address table in a switch is
313 >    discussed in [RFC10019], Section 2).

s/(for example, the address table in a switch is discussed in/(for
example, in the address table of a switch, as discussed in/

Section 3, second paragraph:

326 >    larger value).  In turn, this causes the veto record to always win
327 >    the conflict resolution described in [RFC6762], Section 9.

The lexicographic comparison itself is defined in RFC 6762, Section 8.2;
Section 9 only sends both parties back to probing. Suggest citing both:
s/[RFC6762], Section 9/[RFC6762], Sections 8.2 and 9/

Section 6.1, item 1:

491 >      mapping domain.  Because this mapping is closely-related

s/closely-related/closely related/

[Ballot discuss]
Thanks to the authors and the WG for their work on this document.

My review has been mostly from the routing perspective and I've left the
mDNS aspects for the relevant experts or provided some comments based on my
(limited) understanding.

The review is inline in the idnits output of v13 of this document. The end of
the review is marked by the tag .

Unspecified multi-subnet procedure (Section 4)

354   Multicast streams forwarded to other subnets MUST use a unicast-
355   prefix based IPv6 multicast address ([RFC3306]), as the link-scoped
356   IPv6 multicast address created in Address Generation (Section 2.2) is
357   scoped to the local link.

Section 4 requires a unicast-prefix-based address for streams forwarded beyond
the link, but Section 2 only generates the link-scoped address of Section 2.2,
and nothing says how the RFC 3306 address is formed or how its uniqueness is
established on the links the stream reaches: the prefix and plen, the scope
(bounded by RFC 3306 Section 4), whether the group ID is the one probed under
"9.3.3.3.3.eth-addr.arpa", and the multicast routing assumed (a non-zero plen
falls outside the FF3x::/32 SSM range, so it would be ASM? I am not sure how
implementations would arrive at how they can conform to that MUST.

Could the document either specify that procedure, or scope multi-subnet
forwarding out and make Section 4 descriptive? If you pick the latter,
perhaps:

CURRENT
  Multicast streams forwarded to other subnets MUST use a unicast-
  prefix based IPv6 multicast address ([RFC3306]), as the link-scoped
  IPv6 multicast address created in Address Generation (Section 2.2) is
  scoped to the local link.
SUGGEST
  The link-scoped IPv6 multicast address created in Address Generation
  (Section 2.2) cannot be forwarded beyond the local link.  Forwarding
  a multicast stream to other subnets requires a unicast-prefix based
  IPv6 multicast address ([RFC3306]) and multicast routing; procedures
  for doing so are outside the scope of this document.

[Ballot comment]
I also have some comments to offer.

The first one is at the document level and has got to do about adding
a reference to BCP 52 (RFC 3172) for all the procedures related to the
registration of an "arpa" sub-domain under its rules (see also
the comment on Administration of eth-addr.arpa at line 472).

The rest of the comments are inline in the idnits output:

20   satisfies all of the criteria listed in RFC 10019.

The Abstract says the protocol satisfies all of the RFC 10019
criteria, but Section 5 itself says CONS-6 is not prescribed, and Section 5.1
leaves detection after partition repair (the note under REQ-8 in RFC 10019
Section 3) to future work. CONS-1 depends on how discus-1 is resolved.
Perhaps:

CURRENT
  satisfies all of the criteria listed in RFC 10019.
SUGGEST
  addresses the requirements listed in RFC 10019, with the exceptions
  noted in Section 5.


186   1.  IPv6 Multicast Address
187       This is a link-scoped IPv6 multicast address, calculated by
188       combining the multicast group ID with the Interface Identifier
189       (IID) of the intended source address for the multicast stream,
190       according to the format given in [RFC4489], Section 3.

RFC 4489 Section 3 requires the embedded IID to come from the
link-local unicast address of the interface; "the intended source address"
could be read as a global or temporary address with a different IID.
Suggest:

CURRENT
      combining the multicast group ID with the Interface Identifier
      (IID) of the intended source address for the multicast stream,
SUGGEST
      combining the multicast group ID with the Interface Identifier
      (IID) of the link-local unicast address of the interface used to
      transmit the multicast stream,


467   IANA manages two registries that contain entries used for mapping
468   addresses to names.  This document introduces "eth-addr.arpa" for use
469   in a similar capacity and so requests that it be added to these
470   registries as well.

This paragraph does not name the two registries, and the next two
paragraphs register different names in different registries, so it reads as
asking for "eth-addr.arpa" in both. Perhaps:

DELETE
  IANA manages two registries that contain entries used for mapping
  addresses to names.  This document introduces "eth-addr.arpa" for use
  in a similar capacity and so requests that it be added to these
  registries as well.

472   The domain "eth-addr.arpa" should be registered in the .arpa registry
473   (https://www.iana.org/domains/arpa).  The usage should be "For
474   mapping Ethernet addresses to local domain names for Zero-
475   Configuration Assignment of IPv6 Multicast Addresses" and the
476   reference should be [I-D.draft-ietf-pim-ipv6-zeroconf-assignment].

478   The special-use domain "9.3.3.3.3.eth-addr.arpa." should be
479   registered in the "Special-Use Domain Names" registry
480   (https://www.iana.org/assignments/special-use-domain-names).  This
481   domain should not be delegated.

RFC 3172 Section 3 asks the IANA Considerations of a document creating
an "arpa" sub-domain to include the rules for how it is administered and the
criteria for entries within it. Section 6 gives the name and usage of
"eth-addr.arpa" but not these: for example, whether "eth-addr.arpa" is
delegated (and, if so, how a signed delegation interacts with names answered
only by mDNS), and whether any names other than those under
"9.3.3.3.3.eth-addr.arpa" are expected. I am not a DNS expert and leave the
content to the authors and DNS reviewers; perhaps, after the paragraph
registering "eth-addr.arpa":

NEW
  In accordance with [RFC3172], Section 3, "eth-addr.arpa" is
  administered as follows: .  The only names
  defined under "eth-addr.arpa" are those under
  "9.3.3.3.3.eth-addr.arpa" (below); .

475   Configuration Assignment of IPv6 Multicast Addresses" and the
476   reference should be [I-D.draft-ietf-pim-ipv6-zeroconf-assignment].

s/[I-D.draft-ietf-pim-ipv6-zeroconf-assignment]/this document/

579   The protocol's use of implicit availability means that a bad actor
580   that is able to filter mDNS traffic could neutralize the ability of
581   applications to use mDNS to prevent collisions.  In most networks,
582   the probability of a collision is already so low that this does not
583   result in a practical way to attack the network.

Section 8 might say a little more. Perhaps consider forged goodbye
packets (which could expire a PTR or veto record and reopen a collision), a
sender that uses an in-use group ID without participating in the protocol, and
the wider exposure when records are reflected between subnets (Section 4); and
point to the protections RFC 6762 Section 21 describes rather than discounting
the risk. For example:

CURRENT
  the probability of a collision is already so low that this does not
  result in a practical way to attack the network.
SUGGEST
  the probability of a random collision is low.  Where hosts cannot
  rule out non-cooperating participants, the protections described in
  [RFC6762], Section 21 apply.

[Ballot discuss]
Hi Nate, Dino, and Mike,

Thank you for the effort put into this specification.

Thanks Geoff Huston for the DNSDIR review.

Please find below some few few points for discussion:

# Coordination

CURRENT:
  mDNS implementations used with this protocol MUST coordinate with all
  applications using the same mDNS implementation, as well as with
  other mDNS implementations running on the same host. 

What this MUST concretely imply? How to detect implems that don’t adhere to it?

Can we please characterize a bit more the expected behavior?

# Optimization or core functionality?

Section 2.1

  If the application has previously transmitted the multicast stream,
  then the selected multicast group ID should have been retained in
  persistent storage (Optimization, Section 2.9).  The application
  SHALL proceed using the stored value.

Section 2.9

  The application SHALL retain the group ID value in persistent storage
  and use it the next time the multicast stream is transmitted.  This
  allows the network to quickly settle on a configuration and reduces
  the likelihood of future collisions, as long as the network is
  unchanged.

## The wording in Section 2.1 suggests that the value may not have been retained (“should have been”), while 2.9 is more affirmative (SHALL). Please make sure these two part are consistent?

## Also, given this is an optimization, is SHALL justified?

## Storing the ID alone may not be sufficient as it should be bound to the interface/network attachment. If so, shouldn’t that be clarified in the text?

[Ballot comment]
# Hidden Operational Consideration

CURRENT:
  Scalability of mDNS is an area of ongoing research and improvement
  ([RFC7558]).  The protocol described in this document is subject to
  similar constraints.  Under normal operating conditions, mDNS traffic
  is expected to grow linearly with the number of multicast streams.

  The protocol uses implicit availability: if an application does not
  receive any indication that an address is in use, then it assumes
  that the address is available for its own use.  Because this
  coordination occurs using mDNS, any filtering of mDNS traffic by the
  host or network would prevent applications from coordinating use of
  multicast addresses.  This may result in address collisions.

## These are good points that I’m afraid warrant being highlighted in a dedicated Operational Considerations Section for better exposure to those who will deplopy.

## Some of the discovery/conflict messages may be subject to rate-limiting. Similar effects as above would apply as well. Maybe consider mentioning that as well.

# mDNS Multicast address

CURRENT:
  applications MUST send and receive mDNS messages
  using the IPv6 multicast address for mDNS.  In order to be compatible
  with existing mDNS implementations that require IPv4, applications
  MAY also send and receive mDNS messages using the IPv4 multicast
  address for mDNS.

Consider adding the addresses assigned to mDNS, for readers convenience.

# Mix IANA cons and normative behavior

CURRENT:
  If the application is either 1) transmitting a multicast stream for
  the first time or 2) responding to an address collision, then the
  application SHALL select a random multicast group ID value from the
  range 0x90000000-0x9FFFFFFF.  IANA is REQUESTED to assign this range
  from the "Dynamic Multicast Group IDs" registry (Section 6).

The last sentence duplicates IANA cons actions. Consider deleting at least “REQUESTED”. You may consider:

OLD:
  IANA is REQUESTED to assign this range
  from the "Dynamic Multicast Group IDs" registry (Section 6).

NEW:
  Refer to Section 6 for “Dynamic Multicast Group IDs" IANA registry assignments (Section 6).

# I would move the "criteria evaluation" to an appendix.

Cheers,
Med

[Ballot comment]
Thank you for providing a clear and direct document, and thank you to Tommy Pauly for providing a TSV-ART review.

I don't see concerns from a transport area perspective, but do have some non-blocking comments:

1. This text is not a RFC2119 statment: "IANA is REQUESTED to assign this range from the "Dynamic Multicast Group IDs registry (Section 6)."
- I’d suggest this could be more appropriate as: “Section 6 details the the request to assign this range from the "Dynamic Multicast Group IDs" registry.”

2. I suggest it would be useful to expand the block of text that starts:
"The host network stack may optionally monitor the network for traffic
  that uses the same destination multicast Ethernet address, but a
  different destination multicast IPv6 address"

I expect this method is likely to be very useful in many deployments, but I agree this is not a necessarily needed, optimisation. It would be especially useful when the conflicting L2 address conflict carries significant traffic. However, such overlap can also be a result of the layer 2 filtering, what is expected? Please explain more about this.

3. Concerning the same block of text. I also suggest the following sentence ought to provide more background to help explain when this is useful and note that many NICs can only support a finite set of address filters.

4. Also: "Only one application need respond in this manner to resolve the collision, but both may do so.'
This seems a little odd, and there could be more than one host generating an overall. The word “need” seems an over-statement!  I’d suggest rewriting this.

5. As noted in the TSV-ART review:
It would be nice to provide some examples of the records being exchanged,
particularly in the section for veto records. Providing examples of records and
their corresponding veto records, and the order of operations, would help make
it very clear exactly how things play out (for requirements like "appending the
string "-veto" to the first DNS label that appears in the PTRDNAME field of the
PTR record that caused the address collision")

6. Minor editorial comments:

Section 2.4 "first DNS label of the application identifier SHALL NOT exceed" -> "the first DNS label of the application identifier SHALL NOT exceed" -

Section 5.1 "signficant" -> "significant"

Best wishes,
Gorry

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pim-ipv6-zeroconf-assignment-12. If any part of this review is inaccurate, please let us know.

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

First, in accordance with the rules in [RFC10028], a block of group IDs from the Dynamic Multicast Group IDs registry in the "IPv6 Multicast Address Space" registry group located at:

https://www.iana.org/assignments/ipv6-multicast-addresses

will be registered as follows:

Range: 0x90000000-0x9FFFFFFF
Description: Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS
Reference: [ RFC-to-be ]

Second, a second level domain is to be registered in the .ARPA Zone Management registry located at:

https://www.iana.org/domains/arpa

as follows:

Domain: eth-addr.arpa
Usage: For mapping Ethernet addresses to local domain names for Zero-Configuration Assignment of IPv6 Multicast Addresses
Reference: [ RFC-to-be ]

Third, in the Special-Use Domain Names registry located at:

https://www.iana.org/assignments/special-use-domain-names

the domain name:

9.3.3.3.3.eth-addr.arpa.

will be added to the registry according to the requirements provided by [RFC6761]. The justification for the addition, as required by Section 5 of [RFC6761], are provided in Section 6.1 of the current document.

We understand 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 Sr. Specialist

Request for IETF Last Call review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-10-06):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pim-ipv6-zeroconf-assignment@ietf.org, gunter@vandevelde.cc, pim-chairs@ietf.org, pim@ietf.org, stig@venaas.com
Reply-To: last-call@ietf.org, pim@ietf.org
Sender:
Subject: Last Call:  (Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS) to Proposed Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document:
  'Zero-Configuration Assignment of IPv6 Multicast Addresses Using mDNS'
  as Proposed Standard

The IESG plans to make a decision on this document in the coming weeks, and
solicits last-call comments. Please send substantive comments to the
last-call@ietf.org mailing list, with pim@ietf.org copied, no later than
2026-10-06.  Please retain the beginning of the Subject line to facilitate
automated sorting.

Abstract

  This document describes a zero-configuration protocol for dynamically
  assigning IPv6 multicast addresses that are unique at the link-layer.
  Applications randomly assign multicast group IDs from a specified
  range and prevent collisions by using Multicast DNS (mDNS) to publish
  resource records under a new "eth-addr.arpa" domain.  This protocol
  satisfies all of the criteria listed in RFC 10019.



The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-ipv6-zeroconf-assignment/


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

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

I think there is broad agreement, but also a lot of silent people.

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

No

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

A prototype for Linux using Avahi is available at
.  The main
program in this repository allocates a single IPv6 multicast address
from a specified group ID.  The repository also contains a README
with instructions on how to simulate a network partition.

This technology has been implemented in production in Garmin's GPSMAP
9000 series of marine multifunction displays.

https://www8.garmin.com/marine/PDF/MarineSoftwareUpdate/2026/April2026.pdf

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

It closely interacts with DNS. Got a review from DNS dir. A lot of comments, I
believe they were addressed in the latest revision. Also Rtg and Int dirs have
reviewed and comments addressed in the draft.

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?

Yes I believe it is ready.

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?

No such issues.

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?

Proposed Standard. Yes I think they reflect it.

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 authors confirmed not aware of any IPR.

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.

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

No nits, except for an IPv6 address not being the documentation address. But
this is a link-local address and RFC 3849 does not cover that.

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

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?

All freely 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.

No.

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.

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

All clearly identified.

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.

No new 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/

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

I think there is broad agreement, but also a lot of silent people.

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

No

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

Proof of concept:
https://github.com/nkarstens/mdns-zeroconf-mcast

Used in
https://www8.garmin.com/marine/PDF/MarineSoftwareUpdate/2026/April2026.pdf

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

It closely interacts with DNS. Got a review from DNS dir. A lot of comments, I
believe they were addressed in the latest revision. Also Rtg and Int dirs have
reviewed and comments addressed in the draft.

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?

Yes I believe it is ready.

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?

No such issues.

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?

Proposed Standard. Yes I think they reflect it.

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 authors confirmed not aware of any IPR.

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.

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

No nits, except for an IPv6 address not being the documentation address. But
this is a link-local address and RFC 3849 does not cover that.

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

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?

All freely 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.

No.

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.

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

All clearly identified.

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.

No new 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/

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

I think there is broad agreement, but also a lot of silent people.

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

No

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

Proof of concept:
https://github.com/nkarstens/mdns-zeroconf-mcast

Used in
https://www8.garmin.com/marine/PDF/MarineSoftwareUpdate/2026/April2026.pdf

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

It closely interacts with DNS. Got a review from DNS dir. A lot of comments, I
believe they were addressed in the latest revision. Also Rtg and Int dirs have
reviewed and comments addressed in the draft.

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?

Yes I believe it is ready.

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?

No such issues.

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?

Proposed Standard. Yes I think they reflect it.

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 authors confirmed not aware of any IPR.

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.

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

No nits, except for an IPv6 address not being the documentation address. But
this is a link-local address and RFC 3849 does not cover that.

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

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?

All freely 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.

No.

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.

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

All clearly identified.

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.

No new 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/

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

I think there is broad agreement, but also a lot of silent people.

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

No

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

TBD

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

It closely interacts with DNS. Got a review from DNS dir. A lot of comments, I
believe they were addressed in the latest revision. Also Rtg and Int dirs have
reviewed and comments addressed in the draft.

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?

Yes I believe it is ready.

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?

No such issues.

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?

Proposed Standard. Yes I think they reflect it.

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 authors confirmed not aware of any IPR.

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.

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

No nits, except for an IPv6 address not being the documentation address. But
this is a link-local address and RFC 3849 does not cover that.

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

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?

All freely 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.

No.

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.

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

All clearly identified.

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.

No new 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/