Skip to main content

DNS Resolver Information
draft-ietf-add-resolver-info-13

Revision differences

Document history

Date Rev. By Action
2024-07-15
13 Carlos Pignataro Closed request for Last Call review by OPSDIR with state 'Team Will not Review Document'
2024-07-15
13 Carlos Pignataro Assignment of request for Last Call review by OPSDIR to Nagendra Nainar was marked no-response
2024-06-28
(System)
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-add-resolver-info and RFC 9606, changed IESG state to RFC …
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-add-resolver-info and RFC 9606, changed IESG state to RFC Published)
2024-06-26
13 (System) RFC Editor state changed to AUTH48
2024-06-06
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-06-05
13 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-06-05
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-06-04
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-06-04
13 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-06-03
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-05-25
13 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2024-05-25
13 Tero Kivinen Assignment of request for Last Call review by SECDIR to Steve Hanna was marked no-response
2024-05-24
13 (System) RFC Editor state changed to EDIT
2024-05-24
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-05-24
13 (System) Announcement was received by RFC Editor
2024-05-23
13 (System) IANA Action state changed to In Progress
2024-05-23
13 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2024-05-23
13 Cindy Morgan IESG has approved the document
2024-05-23
13 Cindy Morgan Closed "Approve" ballot
2024-05-23
13 Cindy Morgan Ballot approval text was generated
2024-05-23
13 Éric Vyncke
Thanks to the authors for replying/implementing the changes suggested by the IESG ballots.
Thanks as well to Paul Wouters to clear his DISCUSS into an …
Thanks to the authors for replying/implementing the changes suggested by the IESG ballots.
Thanks as well to Paul Wouters to clear his DISCUSS into an ABSTAIN (I agree that the EDE 'censored' of RFC 8914 is rather vague) and the DNS server reputation is probably an unreachable goal.
2024-05-23
13 (System) Removed all action holders (IESG state changed)
2024-05-23
13 Éric Vyncke IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2024-05-22
13 Paul Wouters
[Ballot comment]
I have updated by ballot from DISCUSS to ABSTAIN.

The document still suffers from not specifying client security policies,
making the entire security …
[Ballot comment]
I have updated by ballot from DISCUSS to ABSTAIN.

The document still suffers from not specifying client security policies,
making the entire security basis incomplete, leaving my security questions
with "that is out of scope" answers.

One argument is that one could select or prefer resolvers offered
by the network based on EDE, but it seems unlikely the network would
supply different DNS resolvers, so this really becomes another case of
"preconfigured vs network assigned". Also, the EDE option support without
knowing the kind of filtering that is selected is not very meaningful.
(while kind is "censored" you don't know if this is censored for adult
content, political content, or just malware, so the option itself without
knowing the policy is not very useful.

From a security point of view, a DNS server conveying "I am going to
withhold DNS answers" cannot be distinguished from beneficial vs an
attack, and so this comes down again to "reputation" of the DNS servers.

Other options conveyed are also on a trust basis, and can
therefor not really be used by DNS clients in a secure way without
pre-trust/pre-configuration.

The document (and discussion we had via email) seems to think this is a
tool for the client to choose between "preconfigured TRR DNS servers"
versus "network supplied ones", but I don't see how the network's
advertised (unverifiable) claims of how it will do DNS can ever be
evaluated or trusted by the client. Really, "reputation" is another word
for "preconfigured non-network supplied DNS servers", which then defeats
the whole purpose of this document's protocol. And will lead to further
DNS centralization.
2024-05-22
13 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to Abstain from Discuss
2024-04-26
13 Warren Kumari [Ballot comment]
Thank you for addressing my DISCUSS position; I have updated my Ballot to NoObj.
2024-04-26
13 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2024-04-26
13 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-04-26
13 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-04-26
13 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-04-26
13 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-13.txt
2024-04-26
13 Mohamed Boucadair New version approved
2024-04-26
13 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2024-04-26
13 Tirumaleswar Reddy.K Uploaded new revision
2024-04-04
12 (System) Changed action holders to Mohamed Boucadair, Tirumaleswar Reddy.K (IESG state changed)
2024-04-04
12 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2024-04-04
12 Zaheduzzaman Sarker [Ballot comment]
Thanks for working of this specification, no objection from me regarding transport layer considerations.
2024-04-04
12 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-04-04
12 Murray Kucherawy
[Ballot comment]
Thanks for the quick IANA Considerations fix, clearing my DISCUSS.  I've left the rest of my original comment here:

In Section 5:

  …
[Ballot comment]
Thanks for the quick IANA Considerations fix, clearing my DISCUSS.  I've left the rest of my original comment here:

In Section 5:

  "Note that, as per the rules for the keys defined in Section 6.4 of [RFC6763], if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value."

I don't know what it means for a Boolean value to be "present".  Do you mean that its presence in the record indicates the value is "true"?

The last few sentences of the description of "infourl" seem awfully hand-wavy.  You might want to simplify this by saying it's a URI referring to content that may be useful for debugging, and just leave it at that.  And I don't understand the SHOULD here; what's the alternative you're trying to discourage?

Once the list of registered RESINFO keywords is big enough, it's possible to pack enough of them into one of these records to cause truncation and a switch to TCP.  Should we be encouraging registration of shorter names wherever possible to forestall this?
2024-04-04
12 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2024-04-04
12 Murray Kucherawy
[Ballot comment]
Thanks for the quick IANA Considerations fix.

In Section 5:

  "Note that, as per the rules for the keys defined in Section …
[Ballot comment]
Thanks for the quick IANA Considerations fix.

In Section 5:

  "Note that, as per the rules for the keys defined in Section 6.4 of [RFC6763], if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value."

I don't know what it means for a Boolean value to be "present".  Do you mean that its presence in the record indicates the value is "true"?

The last few sentences of the description of "infourl" seem awfully hand-wavy.  You might want to simplify this by saying it's a URI referring to content that may be useful for debugging, and just leave it at that.  And I don't understand the SHOULD here; what's the alternative you're trying to discourage?

Once the list of registered RESINFO keywords is big enough, it's possible to pack enough of them into one of these records to cause truncation and a switch to TCP.  Should we be encouraging registration of shorter names wherever possible to forestall this?
2024-04-04
12 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss
2024-04-04
12 Murray Kucherawy
[Ballot discuss]
In Section 8.2, we're creating an IANA registry with Specification Required rules.  You correctly cite Section 4.6 of BCP 26, but that …
[Ballot discuss]
In Section 8.2, we're creating an IANA registry with Specification Required rules.  You correctly cite Section 4.6 of BCP 26, but that section also says:

  As with Expert Review (Section 4.5), clear guidance to the designated
  expert should be provided when defining the registry, and thorough
  understanding of Section 5 is important.

Such guidance appears to be absent here.  What do you have in mind?
2024-04-04
12 Murray Kucherawy Ballot discuss text updated for Murray Kucherawy
2024-04-04
12 Murray Kucherawy
[Ballot discuss]
In Section 8.2, we're creating an IANA registry with Specification Required rules.  You correctly cite Section 4.6 of BCP 26, but that …
[Ballot discuss]
In Section 8.2, we're creating an IANA registry with Specification Required rules.  You correctly cite Section 4.6 of BCP 26, but that section also says:

  As with Expert Review (Section 4.5), clear guidance to the designated
  expert should be provided when defining the registry, and thorough
  understanding of Section 5 is important.

Such guidance appears to be absent here.
2024-04-04
12 Murray Kucherawy
[Ballot comment]
In Section 5:

  "Note that, as per the rules for the keys defined in Section 6.4 of [RFC6763], if there …
[Ballot comment]
In Section 5:

  "Note that, as per the rules for the keys defined in Section 6.4 of [RFC6763], if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value."

I don't know what it means for a Boolean value to be "present".  Do you mean that its presence in the record indicates the value is "true"?

The last few sentences of the description of "infourl" seem awfully hand-wavy.  You might want to simplify this by saying it's a URI referring to content that may be useful for debugging, and just leave it at that.  And I don't understand the SHOULD here; what's the alternative you're trying to discourage?

Once the list of registered RESINFO keywords is big enough, it's possible to pack enough of them into one of these records to cause truncation and a switch to TCP.  Should we be encouraging registration of shorter names wherever possible to forestall this?
2024-04-04
12 Murray Kucherawy [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy
2024-04-03
12 Roman Danyliw
[Ballot comment]
Thank you to Mallory Knodel for the GENART review.

I support the DISCUSS positions of Paul Wouters and Warren Kumari.  Both of these …
[Ballot comment]
Thank you to Mallory Knodel for the GENART review.

I support the DISCUSS positions of Paul Wouters and Warren Kumari.  Both of these positions already capture the majority of the feedback I would have provided.  I would emphasis the point made my Warren that additional text on the use case and deployment environment might help illuminate the design described in this document.

** Section 5.  Infourl
      The resolver information server MUST support the content-type
      'text/html'.
...
      The URL SHOULD be treated only as diagnostic
      information for IT staff.


-- Does this text imply that resolver information can be sent back in some other content-type as long as the resolved information server supports ‘text/html’?  As constructed, this text doesn’t appear to restrict the content-type of the information.

-- Under what circumstances would the IT staff use this for non-diagnostic information?
2024-04-03
12 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-04-03
12 Warren Kumari
[Ballot discuss]
Be ye not afraid -- see https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ on handling ballots, especially DISCUSS ballots...

I'd like to start off by apologizing for the tone …
[Ballot discuss]
Be ye not afraid -- see https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ on handling ballots, especially DISCUSS ballots...

I'd like to start off by apologizing for the tone of this DISCUSS - I know that you've put a lot of work into this document, and getting a review like this is frustrating.
I suspect that a fair bit of my concern can be addressed by having the document be much clearer about the intended use case / what the actual problem is that it is solving.


My DISCUSS is quite similar to Paul Wouters' -- there is much in this document which seems unclear and/or underspecified and/or incomplete.

As an initial example, the Introduction starts off with:
"Historically, DNS clients communicated with recursive resolvers without needing to know anything about the features supported by these resolvers.  However, recent developments (e.g., Extended Error Reporting [RFC8914] or encrypted DNS) imply that earlier assumption no longer generally applies."

I don't really see how "that earlier assumption no longer generally applies" -- my laptop is configured to use Google Public DNS, which happens to support RFC 8914 (Extended DNS Errors) and QNAME Minimization. My laptop happily communicates with 8.8.8. without knowing **anything about the "features supported by these resolvers"**.
I *could* see an argument being made that my laptop should know if the resolver supports various flavors of encrypted DNS so that it knows to connect over an encrypted transport, but that's what RFC9462, RFC9463 are for, no?

"Instead of depending on opportunistic approaches, DNS clients need a more reliable mechanism to discover the features that are supported by resolvers."
Similar to the prior -- why do clients *need* this? My laptop is currently working just fine without it. The document seems to have this base assumption throughout, but it doesn't really seem to justify it -- I'm hoping / assuming that this is sufficiently obvious within the WG that it was just omitted because "everyone knows".

"Retrieved information can be used to feed the server selection procedure. However, that selection procedure is out of the scope of this document." -- is this the justification for all of the above assertions? If so, I think that A: the document needs to be much more explicit about this (don't "bury the lede") and B: some sort of advice about *how* is would be used seems needed -- I get that you don't want to specify the whole selection procedure, but something like "the server selection procedure could use this to prioritize privacy-preserving resolvers over those that don't do QNAME minimization" or similar...


Section 3:
"If the Special-Use Domain Name "resolver.arpa", defined in [RFC9462], is used to discover an encrypted DNS resolver, the client can retrieve the resolver information using the RESINFO RR type and QNAME of "resolver.arpa". In this case, a client has to contend with the risk that a resolver does not support RESINFO. The resolver might pass the query upstream, and then the client can receive a positive RESINFO response either from a legitimate DNS resolver or an attacker. The DNS client MUST set the Recursion Desired (RD) bit of the query to 0. The DNS client MUST discard the response if the AA flag in the response is set to 0, indicating that the encrypted DNS resolver is not authoritative for the response."
This says "In this case, a client has to contend with the risk that a resolver does not support RESINFO." -- but surely that is true for the other cases too? Many clients live behind DNS forwarders / middle-boxes, which will happily pass unknown RR types upstream, but won't necessarily pass e.g EDNS responses back. If one of these clients sees that the "resolver" supports EDE, but the forwarder drops these, the client is being lied to.
Perhaps the techniques in this document are only allowed to be used over encrypted DNS transports? This might be implied by the fact that you are supposed to use "resolver.arpa" or "the QNAME of the domain name that is used to authenticate the DNS resolver", but if so, this is really not clear in the document. If that is indeed the case, the document needs to be much much more explicit about this, and also discuss what happens if you query for this over a non-encrypted protocol (which many resolvers won't actually know).

In addition, this says: "The DNS client MUST set the Recursion Desired (RD) bit of the query to 0. The DNS client MUST discard the response if the AA flag in the response is set to 0, indicating that the encrypted DNS resolver is not authoritative for the response." - is the "indicating that the *encrypted* DNS resolver" (and this section) implying that the RD bit must only be set to 0 when using the RFC9462 resolver.arpa mechanism, or whenever looking up RESINFO? I'd assume the latter, but that conflicts with the "*encrypted* DNS resolver" bit.

Why is it useful / important for a client to know that a resolver supports specific EDE errors? E.g If RESINFO says that Resolver X supports "exterr=15,16,17", and the resolver suddenly sends back Extended DNS Error Code 5 - DNSSEC Indeterminate, what should the client *do*? Is it a violation to send back an EDE Code not covered by the capability list? What if I run a resolver, and advertise "exterr=42", and then add additional support for codes 1, 2 and 3? I guess I have to wait for the TTL to expire before advertising these? Seeing as the document doesn't really explain what the information is used for, it's not clear when (other than at initial connection) a client would re-query for it. Many resolvers are also anycast at this point -- what capabilities should be advertised if the set is not uniform across all members? The minimum enclosing set? The maximal set?


The document also lists qnamemin and exterr as the supported capabilities - it's not at all clear why those ones were selected as important capabilities and not e.g 0x20, port randomization, jurisdiction, logging level and retention, favorite flavor of ice-cream, etc. If it is just that these happened to be two capabilities that you happened to choose, I think that it would be worth clarifying this -- the document does say "New keys can be defined as per the procedure defined in Section 8.2.", but the focus on qname and EDE in the text makes it sound like these are the primary uses.

infourl:
"It is not intended for end user consumption as the URL can possibly provide misleading information. A DNS client MAY choose to display the URL to the end user, if and only if the encrypted resolver has sufficient reputation, according to some local policy" -- so, which is it? If a DNS client does display this to the end user, they will consume it (and possibly be misled). This also seems like it is ripe for phishing / advertising -- "Welcome to BestHotels, thank you for using our wonderful Encrypted DNS server. For only $19.95 per day, you can get the DNSSEC validating version of this service, enter your Credit Card Below!!!"

Security Considerations:
"An encrypted resolver may return incorrect information in RESINFO. If the client cannot validate the attributes received from the resolver, that will be used for resolver selection or displayed to the end-user, the client should process those attributes only if the encrypted resolver has sufficient reputation according to local policy (e.g., user configuration, administrative configuration, or a built-in list of reputable resolvers). "
This feels very hand-wavey / underspecified - "If the client cannot validate the attributes received from the resolver, [...] the client should process those attributes only if the encrypted resolver has sufficient reputation according to local policy."
I don't really understand this -- how could a client validate the attributes? Surely not because they are DNSSEC signed / delivered over encrypted DNS? (That doesn't prove that the data is correct, only that it is what the resolver operator sent) So, how would a client validate that Resolver X supports e.g EDE Codes 9, 10, 11? Does this just boil down to "Don't trust any of this unless local policy says to?"
2024-04-03
12 Warren Kumari
[Ballot comment]
Nits:
1: "imply that earlier assumption no longer generally applies."
s/assumption/assumptions/ (or "the earlier assumptions"). Also, I think s/applies/apply/, or just rewrite this …
[Ballot comment]
Nits:
1: "imply that earlier assumption no longer generally applies."
s/assumption/assumptions/ (or "the earlier assumptions"). Also, I think s/applies/apply/, or just rewrite this ending part.

2: It is not intended for end user consumption as the URL can possibly provide misleading information.
s/consumption as/consumption, as/  Also, I think that "end-user" is the preferred usage, but I'm not sure.
2024-04-03
12 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2024-04-02
12 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-04-01
12 John Scudder [Ballot comment]
I support Paul’s DISCUSS.
2024-04-01
12 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-04-01
12 Orie Steele
[Ballot comment]
Thanks to Arnt Gulbrandsen for the ARTART Review.
Thanks to Tommy Jensen for the shepherd write up.

I support Paul's Discuss, and agree …
[Ballot comment]
Thanks to Arnt Gulbrandsen for the ARTART Review.
Thanks to Tommy Jensen for the shepherd write up.

I support Paul's Discuss, and agree with many of his comments.

In particular, Arnt mentioned in his review similar concerns regarding Section 7.

In Section 5, is misleading IT staff a security issue?
Its not clear how to protect end users in this section.
Consider MUST NOT display the URL to end users.

If you retain the recommendation to use text/html consider adding some guidance regarding web app sec, scripts etc...
This might better help explain your requirement to use HTTPS?

Prefer to see some concrete examples of acceptable strategies for managing reputation.
2024-04-01
12 Orie Steele Ballot comment text updated for Orie Steele
2024-04-01
12 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-03-30
12 Paul Wouters
[Ballot discuss]

In general, I am not sure what this document wants to achieve.

It states:

        DNS clients can use the …
[Ballot discuss]

In general, I am not sure what this document wants to achieve.

It states:

        DNS clients can use the resolver information to identify the
        capabilities of DNS resolvers.

It then defines qnamein, exterr and infourl. The latter should not be used
by the DNS client. So what should a DNS client do with the information
that QNAME Minimalization is used, or that the DNS resolver code base
supports EDE (but EDE might not be in use anyway). What behavioral
change is expected from "DNS Clients" that are targeted by this document?
If no change in behavior is expected, why should a DNS client support and
perform this query?


Furthermore, none of the answers can be trusted without some form of
enterprise provisioning.

Why inform the resolver is using qname minimalization? What makes this
optional special, compared to other things like 0x20 support, the infra-rr
hardering support, DNSSEC support? Why is it not providing keywords for
DoH or DoT or DoQ support? Why not show what normally would be in the
CHAOS version.bind data like dns implementation name and version?

If the DNS client would behave differently based on the setting of
qnamein, what would it be and how would it determine the security of
the returned value (eg why wouldn't the target DNS resolver just lie to
cause the DNS Client to do whatever behavior it does differently when
it sees qnamein?). If this is meant only for administrators doing DNS
diagnostics, why not ONLY return an infourl and have qnamein and exterr
contained in infourl, or even more keywords based on a DNS yang model
list of keywords?

What is the DNS Client expected to do with the exterr values returned?
What does "supported" mean, eg versus "configured". What different
DNS Client behavior is expected based on this value?

The "infourl" seems a bit risky. While the documents tries to limit
the impact, I don't understand its approach.

Why insist on "https" ? It's a public API that anyone that can query
the nameserver can presumably retrieve anyway? That is, I assume such
a infourl would not require HTTP level authentication. I don't see why
it should be forced over https.

Why is the information presented a text/html and not plaintext ? Or
json? Or yang? This would avoid various risks of exposure to the enduser
which are not meant to consume this anyway according to the document.

        The URL SHOULD be treated only as diagnostic

Why is that not the case for qnamein and exterr?
Why is that not a MUST?

        A DNS client MAY choose to display the URL to the end user

Why is this not a MUST NOT ?

        if and only if the encrypted resolver has sufficient reputation

This is not something an implementer can write code for reading the RFC.
It further more pushes centralization towards "reputable DNS resolvers".
How does the DNS client get updates about the reputable status of a DNS
resolver?

I feel just like "captive portals", that this can/will be misused and be used
for advertisement or other non-DNS purposes. Forcing this to be text/plain
or json/yang would make this "less consumable" to endusers and thus make them
more safe against abuse.

In Section 7 it states:

        1. Establish an authenticated secure connection to the DNS resolver.

        [...]

        It is important to note that, of these two measures, only the
        first one can apply to queries for 'resolver.arpa'

How can anyone establish a secure authenticated connection to
"resolver.arpa"?

If they do, either the client has to authenticate it is the real
"resolver.arpa" but then its contents cannot apply (it's something on
the internet, not local) or it authenticates to "something else", in
which case how can that be secure, or if it is secure but populated with
information that validates "starbucks", how meaningful is "authentication"
in this context?

The section contains another set of "weasel wording" on determining
reputation of the resolver that is not really implementable in code.
2024-03-30
12 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2024-03-30
12 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-add-resolver-info-12
CC @ekline

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

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

## Comments …
[Ballot comment]
# Internet AD comments for draft-ietf-add-resolver-info-12
CC @ekline

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

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

## Comments

### S5

* For "exterr", does this mean that a server that supports RFC 8914 in full
  should reply with:

    "exterr=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24"

  Without some attempt at summarizing this (e.g. "=0-24") there is a penalty
  to supporting more error codes over time. Of course, summarization schemes
  do introduce their own parsing complexity. :-/

  This is obviously a minor concern/comment, though.  (No action needed.)

### S7

* It occurs to me that an encrypted resolver might return correct information
  for itself but this information could still be incorrect for other
  resolvers that are part of a shared serving infrastructure (i.e. those
  servers comprising the service behind a resolver VIP).

  It might be worth noting some operational guidance like all resolvers
  in a group SHOULD have consistent RESINFO?
2024-03-30
12 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-03-29
12 Gunter Van de Velde
[Ballot comment]
Many thanks for the document. It was easy to read and process and well written.

Please use or ignore the below observations at …
[Ballot comment]
Many thanks for the document. It was easy to read and process and well written.

Please use or ignore the below observations at your desire.

The abstract could be made more precise:

[existing]
13   This document specifies a method for DNS resolvers to publish
14   information about themselves.  DNS clients can use the resolver
15   information to identify the capabilities of DNS resolvers.  How such
16   an information is then used by DNS clients is out of the scope of
17   this document.

[proposed]
  This document specifies a method for DNS resolvers to publish
  information about themselves.  DNS clients can use the resolver
  information to identify the capabilities of DNS resolvers.
  How DNS clients use such information is beyond the scope of this document.

other observations and clarifications:

101   Retrieved information can be used to feed the server selection
102   procedure.  However, that selection procedure is out of the scope of
103   this document.

Can the retrieved only be used for server selection, or is this merely an example use-case? This could maybe be clarified?

133   Section 5.  If the resolver understands the RESINFO RR type, the
134   RRSet MUST have exactly one record.  RESINFO is a property of the

What if there is none or more as one? is there an exception procedure?

156   The resolver information record uses the same format as DNS TXT
157   records.  As a reminder, the format rules for TXT records are defined
158   in the base DNS specification (Section 3.3.14 of [RFC1035]) and

The words 'As a reminder' sound pedantic. Maybe they can be removed without changing the validity of the information.

172   Keys MUST either be defined in the IANA registry (Section 8.2) or
173   begin with the substring "temp-" for names defined for local use
174   only.

Maybe additional clarification on what keys is being referenced to? It is reasonably clear from the previous context, but being more explicit, especially with a training MUST statement will reduce confusion.

180   qnamemin:  If the DNS resolver supports QNAME minimisation [RFC9156]
181       to improve DNS privacy, the key is present.  Note that, as per the
182       rules for the keys defined in Section 6.4 of [RFC6763], if there
183       is no '=' in a key, then it is a boolean attribute, simply
184       identified as being present, with no value.

I am unsure what 'the key is present' exactly means? does this need BCP14 normative language?
note that 'minimisation' is British English, while 'minimization' is American English

188   exterr:  If the DNS resolver supports extended DNS errors (EDE)
189       option [RFC8914] to return additional information about the cause
190       of DNS errors, the value of this key lists the possible extended
191       DNS error codes that can be returned by this DNS resolver.  When
192       multiple values are present, these values MUST be comma-separated.

what if the same value is added multiple times? or if there are 100000 values inserted? what if illegal values are inserted?

196   infourl:  An URL that points to the generic unstructured resolver
197       information (e.g., DoH APIs supported, possible HTTP status codes
198       returned by the DoH server, or how to report a problem) for
199       troubleshooting purposes.  The server that exposes such
200       information is called "resolver information server".

Is it possible that the URL is not complete, invalid or overly long? how to handle exception scenarios when the URL is illegal or incorrect?

202       The resolver information server MUST support the content-type
203       'text/html'.  The DNS client MUST reject the URL if the scheme is
204       not "https".  The URL SHOULD be treated only as diagnostic
205       information for IT staff.  It is not intended for end user
206       consumption as the URL can possibly provide misleading
207       information.  A DNS client MAY choose to display the URL to the
208       end user, if and only if the encrypted resolver has sufficient
209       reputation, according to some local policy (e.g., user
210       configuration, administrative configuration, or a built-in list of
211       respectable resolvers).

The wording 'if and only if' seems a difficult way to use 'when'?
2024-03-29
12 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-03-28
12 Orie Steele [Ballot comment]
Thanks to Arnt Gulbrandsen for the ARTART Review.
Thanks to Tommy Jensen for the shepherd write up.
2024-03-28
12 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2024-03-21
12 Jim Reid Request for Telechat review by DNSDIR Completed: Ready. Reviewer: Jim Reid. Sent review to list.
2024-03-21
12 Jim Reid Request for Telechat review by DNSDIR is assigned to Jim Reid
2024-03-20
12 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-12.txt
2024-03-20
12 Mohamed Boucadair New version approved
2024-03-20
12 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2024-03-20
12 Tirumaleswar Reddy.K Uploaded new revision
2024-03-15
11 Jim Reid Request for Telechat review by DNSDIR Completed: Almost Ready. Reviewer: Jim Reid. Sent review to list.
2024-03-11
11 Mallory Knodel Request for Last Call review by GENART Completed: Ready. Reviewer: Mallory Knodel. Sent review to list.
2024-03-07
11 Arnt Gulbrandsen Request for Telechat review by ARTART Completed: Ready. Reviewer: Arnt Gulbrandsen. Sent review to list.
2024-03-05
11 Barry Leiba Request for Telechat review by ARTART is assigned to Arnt Gulbrandsen
2024-03-03
11 Jim Reid Request for Telechat review by DNSDIR is assigned to Jim Reid
2024-03-03
11 Éric Vyncke Placed on agenda for telechat - 2024-04-04
2024-03-03
11 Éric Vyncke Ballot has been issued
2024-03-03
11 Éric Vyncke [Ballot Position Update] New position, Yes, has been recorded for Éric Vyncke
2024-03-03
11 Éric Vyncke Created "Approve" ballot
2024-03-03
11 Éric Vyncke IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2024-03-03
11 Éric Vyncke Ballot writeup was changed
2024-03-01
11 Éric Vyncke RFC Editor Note for ballot was generated
2024-02-29
11 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-02-29
11 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-29
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-02-29
11 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-11.txt
2024-02-29
11 Mohamed Boucadair New version approved
2024-02-29
11 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2024-02-29
11 Tirumaleswar Reddy.K Uploaded new revision
2024-02-29
10 Éric Vyncke To address/reply to the IETF Last Call comments (art and Mark Andrews).
2024-02-29
10 (System) Changed action holders to Tirumaleswar Reddy.K, Mohamed Boucadair (IESG state changed)
2024-02-29
10 Éric Vyncke IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2024-02-29
10 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-02-28
10 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2024-02-28
10 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-add-resolver-info-10. If any part of this review is inaccurate, please let us know.

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

IANA has completed its review of draft-ietf-add-resolver-info-10. If any part of this review is inaccurate, please let us know.

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

First, in the Resource Record (RR) TYPEs registry in the Domain Name System (DNS) Parameters registry group located at:

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

Type: RESINFO
Value: 261
Meaning: Resolver Information as Key/Value Pairs
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the DNS Resolver Information Keys registry. The new registry will be located in the Domain Name System (DNS) Parameters registry group located at:

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

The registration procedure is Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

Name: qnamemin
Description: The presence of the key name indicates that QNAME minimization is enabled
Specification: [ RFC-to-be ]

Name: exterr
Description: Lists the set of supported extended DNS errors. It must be an INFO-CODE decimal value in the "Extended DNS Error Codes" registry
Specification:  [ RFC-to-be ]

Name: infourl
Description: Provides an URL that points to an unstructured resolver information that is used for troubleshooting
Specification:  [ RFC-to-be ]

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

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

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist
2024-02-28
10 Jim Reid Request for Last Call review by DNSDIR Completed: Ready with Nits. Reviewer: Jim Reid. Sent review to list.
2024-02-27
10 Arnt Gulbrandsen Request for Last Call review by ARTART Completed: Ready with Issues. Reviewer: Arnt Gulbrandsen.
2024-02-22
10 Barry Leiba Request for Last Call review by ARTART is assigned to Arnt Gulbrandsen
2024-02-20
10 Johan Stenstam Assignment of request for Last Call review by DNSDIR to Johan Stenstam was rejected
2024-02-16
10 Jim Reid Request for Last Call review by DNSDIR is assigned to Jim Reid
2024-02-16
10 Johan Stenstam Assignment of request for Last Call review by DNSDIR to Johan Stenstam was rejected
2024-02-16
10 Jim Reid Request for Last Call review by DNSDIR is assigned to Johan Stenstam
2024-02-15
10 Jean Mahoney Request for Last Call review by GENART is assigned to Mallory Knodel
2024-02-15
10 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2024-02-15
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Steve Hanna
2024-02-15
10 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-02-15
10 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-02-29):

From: The IESG
To: IETF-Announce
CC: add-chairs@ietf.org, add@ietf.org, draft-ietf-add-resolver-info@ietf.org, evyncke@cisco.com, tojens@microsoft.com …
The following Last Call announcement was sent out (ends 2024-02-29):

From: The IESG
To: IETF-Announce
CC: add-chairs@ietf.org, add@ietf.org, draft-ietf-add-resolver-info@ietf.org, evyncke@cisco.com, tojens@microsoft.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DNS Resolver Information) to Proposed Standard


The IESG has received a request from the Adaptive DNS Discovery WG (add) to
consider the following document: - 'DNS Resolver Information'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-02-29. 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 specifies a method for DNS resolvers to publish
  information about themselves.  DNS clients can use the resolver
  information to identify the capabilities of DNS resolvers.  How such
  an information is then used by DNS clients is out of the scope of
  this document.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-add-resolver-info/



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




2024-02-15
10 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-02-15
10 Éric Vyncke Last call was requested
2024-02-15
10 Éric Vyncke Ballot approval text was generated
2024-02-15
10 Éric Vyncke Ballot writeup was generated
2024-02-15
10 Éric Vyncke IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-02-15
10 Éric Vyncke Last call announcement was generated
2024-02-14
10 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-02-14
10 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-14
10 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-10.txt
2024-02-14
10 Mohamed Boucadair New version approved
2024-02-14
10 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2024-02-14
10 Tirumaleswar Reddy.K Uploaded new revision
2024-02-14
09 Tommy Jensen
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-09

(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Tommy Jensen

Has the Document Shepherd personally …
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-09

(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Tommy Jensen

Has the Document Shepherd personally reviewed this version of the document and,
in particular, does he or she believe this version is ready for forwarding to
the IESG for publication?

Yes, the document shepherd has reviewed the latest document draft and believes
it is ready for forwarding to the IESG.

(1.b)  Has the document had adequate review both from key WG members and from
key non-WG members?

Yes.

Does the Document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?

No. The WG conducted a second review and LC at IETF 118 in response to a previous shepherd
review that uncovered a security issue in -07 which is now addressed by -09.

(1.c)  Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization, or XML?

No, the WG has fairly broad DNS representation, and this draft does not leave
that domain (no use of SVCB or other formats defined elsewhere, for example).
The Expert Review for the new RR type has now also taken place.

(1.d)  Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should be
aware of?  For example, perhaps he or she is uncomfortable with certain parts
of the document, or has concerns whether there really is a need for it.  In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

No. The shepherd has clearly stated that his sponsor has no intention of
implementing, but it is due to a lack of scenario rather than opposition to
architecture. The shepherd has agreed to advance and champion the document as a
representation of WG consensus for use by others.

Has an IPR disclosure related to this document been filed?  If so, please
include a reference to the disclosure and summarize the WG discussion and
conclusion on this issue.

No IPR disclosures have been filed relating to this document as of February 14th
2024.

(1.e)  How solid is the WG consensus behind this document?  Does it represent
the strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

It is a strong concurrence of a few individuals, but is still widely understood and accepted
by the WG.

(1.f)  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 entered into the ID Tracker.)

In short, no, the document shepherd does not believe there is a risk of
escalation, appeal, or retaliation by malcontent parties if this document is
published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who
have no interest in implementing the mechanism described in this document
(including his own employer), but none of these parties are opposed to the
standard itself for use by other parties. The reasons for not implementing
known to the document shepherd are rooted in product strategy reasoning, not
ethical or security concerns that would translate to valid reasons to block
publication.

(1.g)  Has the Document Shepherd personally verified that the document
satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this
check needs to be thorough.

On February 14th, 2024, the document shepherd ran the idnits tool version 2.17.1
and found two nits. One is “Unused Reference: 'I-D.pp-add-resinfo' is defined on line
390, but no explicit reference was found in the text”. This document is
referenced in the Acknowledgements section at the end of the document,
following the References section. The authors and document shepherd agree
having the reference is valuable as the referenced draft was a major source for
this document. The other nit was related to the document’s date being in the past (which is
expected).

Neither nit should prevent the document from proceeding through the
publication process.

Has the document met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews?

An Expert Review for the new DNS RR type defined by this document has taken
place. The document shepherd does not believe there are other reviews required
for this document.

If the document does not already indicate its intended status at the top of the
first page, please indicate the intended status here.

Intended RFC status: Proposed Standard
Justification: This document has the WG’s consensus after significant review, including resolving
design choices to be compatible with the expectations of more parties than the document authors
alone. In the shepherd’s opinion, this drafts meets all of the requirement in RFC 2026 Section 4.1.1
for a Proposed Standard (which was left unchanged by RFC 6410 Section 2.1 when the standard
tracks were reduced).

(1.h)  Has the document split its references into normative and informative?

Yes, the document splits normative and informative references.

The normative references, together with an indication of the type and whether
they have been updated by later versions, are as follows:

RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)
RFC 9462 - Standards Track (not updated)
RFC 9463 - Standards Track (not updated)

The informative references, together with an indication of the type and whether
they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list

Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state?

No.

If such normative references exist, what is the strategy for their completion?

Not applicable.

Are there normative references that are downward references, as described in
[RFC3967]?  If so, list these downward references to support the Area Director
in the Last Call procedure for them [RFC3967].

Not applicable. All normative references are either RFC-published Standards
Track or BCP.

(1.i)  Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body of the document?

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor
requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
  Create a new DNS RR TYPE with the following properties:
    Type: RESINFO
    Value: 261
    Meaning: Resolver Information as Key/Value Pairs
    Reference: RFCXXXX
  Create a new registry entitled “DNS Resolver Information Keys” under the
  “Domain Name System (DNS) Parameters” with the following columns:
    Name
    Description
    Specification

The fields provided meet precedent for recent RR TYPE entries requested, namely
the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections
14.1 and 14.2. Additionally, the guidance in RFC 6895 was followed per
IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC
Editor to update all instance of “RFCXXXX” in the document with the final RFC
number granted to the document upon publication. Instances of “RFCXXXX” can be
found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).

If the document specifies protocol extensions, are reservations requested in
appropriate IANA registries?  Are the IANA registries clearly identified?

Yes (see above).

If the document creates a new registry, does it define the proposed initial
contents of the registry and an allocation procedure for future registrations?

Yes.

Does it suggest a reasonable name for the new registry?  See [RFC2434].

Yes.

If the document describes an Expert Review process, has the Document Shepherd
conferred with the Responsible Area Director so that the IESG can appoint the
needed Expert during IESG Evaluation?

The Expert Review defined as required for new RR types in RFC 6895 has taken
place.

(1.j)  Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB definitions,
etc., validate correctly in an automated checker?

N/A. The closest thing to this is the example content of the new record type
defined within the document.
2024-02-14
09 Éric Vyncke Revised I-D and shepherd write-up are required before proceeding, see my AD review at:
https://mailarchive.ietf.org/arch/msg/add/YShSKzRKfAqftpnmWPYkkMRd4eQ/
2024-02-14
09 (System) Changed action holders to Tirumaleswar Reddy.K, Mohamed Boucadair (IESG state changed)
2024-02-14
09 Éric Vyncke IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2024-02-12
09 Éric Vyncke IESG state changed to AD Evaluation from Publication Requested
2024-02-07
09 Glenn Deen
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-08

(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Tommy Jensen

Has the Document Shepherd personally …
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-08

(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Tommy Jensen

Has the Document Shepherd personally reviewed this version of the document and,
in particular, does he or she believe this version is ready for forwarding to
the IESG for publication?

Yes, the document shepherd has reviewed the latest document draft and believes
it is ready for forwarding to the IESG.

(1.b)  Has the document had adequate review both from key WG members and from
key non-WG members?

Yes.

Does the Document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?

No. The WG conducted a second review and LC at IETF 118 in response to a previous shepherd
review that uncovered a security issue in -07 which is now addressed by -08.

(1.c)  Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization, or XML?

No, the WG has fairly broad DNS representation, and this draft does not leave
that domain (no use of SVCB or other formats defined elsewhere, for example).
The Expert Review for the new RR type has now also taken place.

(1.d)  Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should be
aware of?  For example, perhaps he or she is uncomfortable with certain parts
of the document, or has concerns whether there really is a need for it.  In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

No. The shepherd has clearly stated that his sponsor has no intention of
implementing, but it is due to a lack of scenario rather than opposition to
architecture. The shepherd has agreed to advance and champion the document as a
representation of WG consensus for use by others.

Has an IPR disclosure related to this document been filed?  If so, please
include a reference to the disclosure and summarize the WG discussion and
conclusion on this issue.

No IPR disclosures have been filed relating to this document as of January 31st
2024.

(1.e)  How solid is the WG consensus behind this document?  Does it represent
the strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

It is a strong concurrence of a few individuals, but is still widely understood and accepted
by the WG.

(1.f)  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 entered into the ID Tracker.)

In short, no, the document shepherd does not believe there is a risk of
escalation, appeal, or retaliation by malcontent parties if this document is
published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who
have no interest in implementing the mechanism described in this document
(including his own employer), but none of these parties are opposed to the
standard itself for use by other parties. The reasons for not implementing
known to the document shepherd are rooted in product strategy reasoning, not
ethical or security concerns that would translate to valid reasons to block
publication.

(1.g)  Has the Document Shepherd personally verified that the document
satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this
check needs to be thorough.

On January 31st, 2024, the document shepherd ran the idnits tool version 2.17.1
and found two warnings. One is “Unused Reference: 'I-D.pp-add-resinfo' is defined on line
393, but no explicit reference was found in the text”. This document is
referenced in the Acknowledgements section at the end of the document,
following the References section. The authors and document shepherd agree
having the reference is valuable as the referenced draft was a major source for
this document. The other warning (and a comment) were related to the document’s year not
matching the current year. This is expected.

Neither nit should prevent the document from proceeding through the
publication process.

Has the document met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews?

An Expert Review for the new DNS RR type defined by this document has taken
place. The document shepherd does not believe there are other reviews required
for this document.

If the document does not already indicate its intended status at the top of the
first page, please indicate the intended status here.

Intended RFC status: Proposed Standard

(1.h)  Has the document split its references into normative and informative?

Yes, the document splits normative and informative references.

The normative references, together with an indication of the type and whether
they have been updated by later versions, are as follows:

RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)
RFC 9462 - Standards Track (not updated)
RFC 9463 - Standards Track (not updated)

The informative references, together with an indication of the type and whether
they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list

Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state?

No.

If such normative references exist, what is the strategy for their completion?

Not applicable.

Are there normative references that are downward references, as described in
[RFC3967]?  If so, list these downward references to support the Area Director
in the Last Call procedure for them [RFC3967].

Not applicable. All normative references are either RFC-published Standards
Track or BCP.

(1.i)  Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body of the document?

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor
requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
  Create a new DNS RR TYPE with the following properties:
    Type: RESINFO
    Value: 261
    Meaning: Resolver Information as Key/Value Pairs
    Reference: RFCXXXX
  Create a new registry entitled “DNS Resolver Information Keys” under the
  “Domain Name System (DNS) Parameters” with the following columns:
    Name
    Description
    Specification

The fields provided meet precedent for recent RR TYPE entries requested, namely
the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections
14.1 and 14.2. Additionally, the guidance in RFC 6895 was followed per
IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC
Editor to update all instance of “RFCXXXX” in the document with the final RFC
number granted to the document upon publication. Instances of “RFCXXXX” can be
found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).

If the document specifies protocol extensions, are reservations requested in
appropriate IANA registries?  Are the IANA registries clearly identified?

Yes (see above).

If the document creates a new registry, does it define the proposed initial
contents of the registry and an allocation procedure for future registrations?

Yes.

Does it suggest a reasonable name for the new registry?  See [RFC2434].

Yes.

If the document describes an Expert Review process, has the Document Shepherd
conferred with the Responsible Area Director so that the IESG can appoint the
needed Expert during IESG Evaluation?

The Expert Review defined as required for new RR types in RFC 6895 has taken
place.

(1.j)  Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB definitions,
etc., validate correctly in an automated checker?

N/A. The closest thing to this are the example contents of the new record type
defined within the document.
2024-02-07
09 Glenn Deen IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2024-02-07
09 Glenn Deen IESG state changed to Publication Requested from I-D Exists
2024-02-07
09 (System) Changed action holders to Éric Vyncke (IESG state changed)
2024-02-07
09 Glenn Deen Responsible AD changed to Éric Vyncke
2024-02-07
09 Glenn Deen Document is now in IESG state Publication Requested
2024-02-07
09 Glenn Deen Changed consensus to Yes from Unknown
2024-02-07
09 Glenn Deen Intended Status changed to Proposed Standard from None
2024-02-07
09 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-09.txt
2024-02-07
09 Mohamed Boucadair New version approved
2024-02-07
09 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2024-02-07
09 Tirumaleswar Reddy.K Uploaded new revision
2024-01-31
08 Tommy Jensen
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-08

(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Tommy Jensen

Has the Document Shepherd personally …
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-08

(1.a)  Who is the Document Shepherd for this document?

Document Shepherd: Tommy Jensen

Has the Document Shepherd personally reviewed this version of the document and,
in particular, does he or she believe this version is ready for forwarding to
the IESG for publication?

Yes, the document shepherd has reviewed the latest document draft and believes
it is ready for forwarding to the IESG.

(1.b)  Has the document had adequate review both from key WG members and from
key non-WG members?

Yes.

Does the Document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?

No. The WG conducted a second review and LC at IETF 118 in response to a previous shepherd
review that uncovered a security issue in -07 which is now addressed by -08.

(1.c)  Does the Document Shepherd have concerns that the document needs more
review from a particular or broader perspective, e.g., security, operational
complexity, someone familiar with AAA, internationalization, or XML?

No, the WG has fairly broad DNS representation, and this draft does not leave
that domain (no use of SVCB or other formats defined elsewhere, for example).
The Expert Review for the new RR type has now also taken place.

(1.d)  Does the Document Shepherd have any specific concerns or issues with
this document that the Responsible Area Director and/or the IESG should be
aware of?  For example, perhaps he or she is uncomfortable with certain parts
of the document, or has concerns whether there really is a need for it.  In any
event, if the WG has discussed those issues and has indicated that it still
wishes to advance the document, detail those concerns here.

No. The shepherd has clearly stated that his sponsor has no intention of
implementing, but it is due to a lack of scenario rather than opposition to
architecture. The shepherd has agreed to advance and champion the document as a
representation of WG consensus for use by others.

Has an IPR disclosure related to this document been filed?  If so, please
include a reference to the disclosure and summarize the WG discussion and
conclusion on this issue.

No IPR disclosures have been filed relating to this document as of January 31st
2024.

(1.e)  How solid is the WG consensus behind this document?  Does it represent
the strong concurrence of a few individuals, with others being silent, or does
the WG as a whole understand and agree with it?

It is a strong concurrence of a few individuals, but is still widely understood and accepted
by the WG.

(1.f)  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 entered into the ID Tracker.)

In short, no, the document shepherd does not believe there is a risk of
escalation, appeal, or retaliation by malcontent parties if this document is
published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who
have no interest in implementing the mechanism described in this document
(including his own employer), but none of these parties are opposed to the
standard itself for use by other parties. The reasons for not implementing
known to the document shepherd are rooted in product strategy reasoning, not
ethical or security concerns that would translate to valid reasons to block
publication.

(1.g)  Has the Document Shepherd personally verified that the document
satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this
check needs to be thorough.

On January 31st, 2024, the document shepherd ran the idnits tool version 2.17.1
and found two warnings. One is “Unused Reference: 'I-D.pp-add-resinfo' is defined on line
393, but no explicit reference was found in the text”. This document is
referenced in the Acknowledgements section at the end of the document,
following the References section. The authors and document shepherd agree
having the reference is valuable as the referenced draft was a major source for
this document. The other warning (and a comment) were related to the document’s year not
matching the current year. This is expected.

Neither nit should prevent the document from proceeding through the
publication process.

Has the document met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews?

An Expert Review for the new DNS RR type defined by this document has taken
place. The document shepherd does not believe there are other reviews required
for this document.

If the document does not already indicate its intended status at the top of the
first page, please indicate the intended status here.

Intended RFC status: Proposed Standard

(1.h)  Has the document split its references into normative and informative?

Yes, the document splits normative and informative references.

The normative references, together with an indication of the type and whether
they have been updated by later versions, are as follows:

RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)
RFC 9462 - Standards Track (not updated)
RFC 9463 - Standards Track (not updated)

The informative references, together with an indication of the type and whether
they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list

Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state?

No.

If such normative references exist, what is the strategy for their completion?

Not applicable.

Are there normative references that are downward references, as described in
[RFC3967]?  If so, list these downward references to support the Area Director
in the Last Call procedure for them [RFC3967].

Not applicable. All normative references are either RFC-published Standards
Track or BCP.

(1.i)  Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body of the document?

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor
requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
  Create a new DNS RR TYPE with the following properties:
    Type: RESINFO
    Value: 261
    Meaning: Resolver Information as Key/Value Pairs
    Reference: RFCXXXX
  Create a new registry entitled “DNS Resolver Information Keys” under the
  “Domain Name System (DNS) Parameters” with the following columns:
    Name
    Description
    Specification

The fields provided meet precedent for recent RR TYPE entries requested, namely
the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections
14.1 and 14.2. Additionally, the guidance in RFC 6895 was followed per
IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC
Editor to update all instance of “RFCXXXX” in the document with the final RFC
number granted to the document upon publication. Instances of “RFCXXXX” can be
found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).

If the document specifies protocol extensions, are reservations requested in
appropriate IANA registries?  Are the IANA registries clearly identified?

Yes (see above).

If the document creates a new registry, does it define the proposed initial
contents of the registry and an allocation procedure for future registrations?

Yes.

Does it suggest a reasonable name for the new registry?  See [RFC2434].

Yes.

If the document describes an Expert Review process, has the Document Shepherd
conferred with the Responsible Area Director so that the IESG can appoint the
needed Expert during IESG Evaluation?

The Expert Review defined as required for new RR types in RFC 6895 has taken
place.

(1.j)  Has the Document Shepherd verified that sections of the document that
are written in a formal language, such as XML code, BNF rules, MIB definitions,
etc., validate correctly in an automated checker?

N/A. The closest thing to this are the example contents of the new record type
defined within the document.
2023-11-24
08 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-08.txt
2023-11-24
08 Tirumaleswar Reddy.K New version accepted (logged-in submitter: Tirumaleswar Reddy.K)
2023-11-24
08 Tirumaleswar Reddy.K Uploaded new revision
2023-11-24
08 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-11-24
08 Tirumaleswar Reddy.K Uploaded new revision
2023-11-06
07 Tommy Jensen
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally …
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Yes, the document shepherd has reviewed the latest document draft, but does not believe it is ready for forwarding to the IESG yet. This is only because there was one issue uncovered during initial shepherd review which needs WG consensus on the author’s proposed solution. Once that issue is closed, the document shepherd believes this document will be ready for the IESG.


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

Previously yes. However, the -07 draft (latest) has not had sufficient attention on its solution to an issue uncovered by the document shepherd’s first review. Otherwise the content has been thoroughly reviewed.


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Yes, but temporarily. The editors have been thorough in documenting their changes to the WG and responsive in issuing new versions. However, the WGLC passed with no opposition but also no on-list support voiced. The latest versions (-06 onward) were published post WGLC with changes the document shepherd suggested during initial review prior to this document being published which has not had positive acks that it addresses the identified problem.

We intend to close on this during IETF 118 and expect this question to update to “No concerns about reviews” soon.


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No, the WG has fairly broad DNS representation, and this draft does not leave that domain (no use of SVCB or other formats defined elsewhere, for example). The Expert Review for the new RR type has now also taken place.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No. The shepherd has clearly stated that his sponsor has no intention of implementing, but it is due to a lack of scenario rather than opposition to architecture. The shepherd has agreed to advance and champion the document as a representation of WG consensus for use by others.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document as of November 6th 2023.


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It is a strong concurrence of a few individuals, with most of the WG previously expressing feedback now silent. WGLC was passed with no objections but also no other-than-author support.


(1.f)  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 entered into the ID Tracker.)

In short, no, the document shepherd does not believe there is a risk of escalation, appeal, or retaliation by malcontent parties if this document is published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who have no interest in implementing the mechanism described in this document (including his own employer), but none of these parties are opposed to the standard itself for use by other parties. The reasons for not implementing known to the document shepherd are rooted in product strategy reasoning, not ethical or security concerns that would translate to valid reasons to block publication.


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

On November 6th, 2023, the document shepherd ran the idnits tool version 2.17.1 and found one nit: “Unused Reference: 'I-D.pp-add-resinfo' is defined on line 417, but no explicit reference was found in the text”. This document is referenced in the Acknowledgements section at the end of the document, following the References section. The authors and document shepherd agree having the reference is valuable as the referenced draft was a major source for this document.

This nit should not prevent the document from proceeding through the publication process.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

An Expert Review for the new DNS RR type defined by this document has taken place. The document shepherd does not believe there are other reviews required for this document.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: Proposed Standard



(1.h)  Has the document split its references into normative and informative? 

Yes, the document splits normative and informative references.

The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

I-D.ietf-add-ddr – Standards Track (not updated, in AUTH48)
I-D.ietf-add-dnr – Standards Track (not updated, in AUTH48)
RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)

The informative references, together with an indication of the type and whether they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
    (see http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4)
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list
    (see https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.


If such normative references exist, what is the strategy for their completion? 

Not applicable.


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable. All normative references are either RFC-published Standards Track or BCP.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
  Create a new DNS RR TYPE with the following properties:
    Type: RESINFO
    Value: TBD
    Meaning: Resolver Information as Key/Value Pairs
    Reference: RFCXXXX
  Create a new registry entitled “DNS Resolver Information Keys” under the “Domain Name System (DNS) Parameters” with the following columns:
    Name
    Value Type
    Description
    Specification

The fields provided meet precedent for recent RR TYPE entries requested, namely the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections 14.1 and 14.2 (link). Additionally, the guidance in RFC 6895 was followed per IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC Editor to update all instance of “RFCXXXX” in the document with the final RFC number granted to the document upon publication. Instances of “RFCXXXX” can be found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes (see above).


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Yes.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Yes.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

The Expert Review defined as required for new RR types in RFC 6895 has taken place.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

N/A. The closest thing to this are the example contents of the new record type defined within the document.

2023-11-06
07 Tommy Jensen
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally …
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Yes, the document shepherd has reviewed the latest document draft, but does not believe it is ready for forwarding to the IESG yet. This is only because there was one issue uncovered during initial shepherd review which needs WG consensus on the author’s proposed solution. Once that issue is closed, the document shepherd believes this document will be ready for the IESG.


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

Previously yes. However, the -07 draft (latest) has not had sufficient attention on its solution to an issue uncovered by the document shepherd’s first review. Otherwise the content has been thoroughly reviewed.


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Yes, but temporarily. The editors have been thorough in documenting their changes to the WG and responsive in issuing new versions. However, the WGLC passed with no opposition but also no on-list support voiced. The latest versions (-06 onward) were published post WGLC with changes the document shepherd suggested during initial review prior to this document being published which has not had positive acks that it addresses the identified problem.

We intend to close on this during IETF 118 and expect this question to update to “No concerns about reviews” soon.


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No, the WG has fairly broad DNS representation, and this draft does not leave that domain (no use of SVCB or other formats defined elsewhere, for example). The Expert Review for the new RR type has now also taken place.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No. The shepherd has clearly stated that his sponsor has no intention of implementing, but it is due to a lack of scenario rather than opposition to architecture. The shepherd has agreed to advance and champion the document as a representation of WG consensus for use by others.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document as of November 6th 2023.


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It is a strong concurrence of a few individuals, with most of the WG previously expressing feedback now silent. WGLC was passed with no objections but also no other-than-author support.


(1.f)  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 entered into the ID Tracker.)

In short, no, the document shepherd does not believe there is a risk of escalation, appeal, or retaliation by malcontent parties if this document is published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who have no interest in implementing the mechanism described in this document (including his own employer), but none of these parties are opposed to the standard itself for use by other parties. The reasons for not implementing known to the document shepherd are rooted in product strategy reasoning, not ethical or security concerns that would translate to valid reasons to block publication.


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

On November 6th, 2023, the document shepherd ran the idnits tool version 2.17.1 and found one nit: “Unused Reference: 'I-D.pp-add-resinfo' is defined on line 417, but no explicit reference was found in the text”. This document is referenced in the Acknowledgements section at the end of the document, following the References section. The authors and document shepherd agree having the reference is valuable as the referenced draft was a major source for this document.

This nit should not prevent the document from proceeding through the publication process.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

An Expert Review for the new DNS RR type defined by this document has taken place. The document shepherd does not believe there are other reviews required for this document.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: Proposed Standard



(1.h)  Has the document split its references into normative and informative? 

Yes, the document splits normative and informative references.

The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

I-D.ietf-add-ddr – Standards Track (not updated, in AUTH48)
I-D.ietf-add-dnr – Standards Track (not updated, in AUTH48)
RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)

The informative references, together with an indication of the type and whether they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
• (see http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4)
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list
• (see https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.


If such normative references exist, what is the strategy for their completion? 

Not applicable.


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable. All normative references are either RFC-published Standards Track or BCP.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
  Create a new DNS RR TYPE with the following properties:
    Type: RESINFO
    Value: TBD
    Meaning: Resolver Information as Key/Value Pairs
    Reference: RFCXXXX
  Create a new registry entitled “DNS Resolver Information Keys” under the “Domain Name System (DNS) Parameters” with the following columns:
    Name
    Value Type
    Description
    Specification

The fields provided meet precedent for recent RR TYPE entries requested, namely the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections 14.1 and 14.2 (link). Additionally, the guidance in RFC 6895 was followed per IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC Editor to update all instance of “RFCXXXX” in the document with the final RFC number granted to the document upon publication. Instances of “RFCXXXX” can be found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes (see above).


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Yes.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Yes.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

The Expert Review defined as required for new RR types in RFC 6895 has taken place.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

N/A. The closest thing to this are the example contents of the new record type defined within the document.

2023-11-06
07 Tommy Jensen
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally …
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Yes, the document shepherd has reviewed the latest document draft, but does not believe it is ready for forwarding to the IESG yet. This is only because there was one issue uncovered during initial shepherd review which needs WG consensus on the author’s proposed solution. Once that issue is closed, the document shepherd believes this document will be ready for the IESG.


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

Previously yes. However, the -07 draft (latest) has not had sufficient attention on its solution to an issue uncovered by the document shepherd’s first review. Otherwise the content has been thoroughly reviewed.


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Yes, but temporarily. The editors have been thorough in documenting their changes to the WG and responsive in issuing new versions. However, the WGLC passed with no opposition but also no on-list support voiced. The latest versions (-06 onward) were published post WGLC with changes the document shepherd suggested during initial review prior to this document being published which has not had positive acks that it addresses the identified problem.

We intend to close on this during IETF 118 and expect this question to update to “No concerns about reviews” soon.


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No, the WG has fairly broad DNS representation, and this draft does not leave that domain (no use of SVCB or other formats defined elsewhere, for example). The Expert Review for the new RR type has now also taken place.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No. The shepherd has clearly stated that his sponsor has no intention of implementing, but it is due to a lack of scenario rather than opposition to architecture. The shepherd has agreed to advance and champion the document as a representation of WG consensus for use by others.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document as of November 6th 2023.


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It is a strong concurrence of a few individuals, with most of the WG previously expressing feedback now silent. WGLC was passed with no objections but also no other-than-author support.


(1.f)  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 entered into the ID Tracker.)

In short, no, the document shepherd does not believe there is a risk of escalation, appeal, or retaliation by malcontent parties if this document is published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who have no interest in implementing the mechanism described in this document (including his own employer), but none of these parties are opposed to the standard itself for use by other parties. The reasons for not implementing known to the document shepherd are rooted in product strategy reasoning, not ethical or security concerns that would translate to valid reasons to block publication.


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

On November 6th, 2023, the document shepherd ran the idnits tool version 2.17.1 and found two nits:
• “Unused Reference: 'I-D.pp-add-resinfo' is defined on line 417, but no explicit reference was found in the text”
o This document is referenced in the Acknowledgements section at the end of the document, following the References section
o The tool is in error, and the authors and document shepherd agree having the reference is valuable as the referenced draft was a major source for this document

This nit should not prevent the document from proceeding through the publication process.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

An Expert Review for the new DNS RR type defined by this document has taken place. The document shepherd does not believe there are other reviews required for this document.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: Proposed Standard



(1.h)  Has the document split its references into normative and informative? 

Yes, the document splits normative and informative references.

The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

I-D.ietf-add-ddr – Standards Track (not updated, in AUTH48)
I-D.ietf-add-dnr – Standards Track (not updated, in AUTH48)
RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)

The informative references, together with an indication of the type and whether they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
• (see http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4)
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list
• (see https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.


If such normative references exist, what is the strategy for their completion? 

Not applicable.


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable. All normative references are either RFC-published Standards Track or BCP.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
  Create a new DNS RR TYPE with the following properties:
    Type: RESINFO
    Value: TBD
    Meaning: Resolver Information as Key/Value Pairs
    Reference: RFCXXXX
  Create a new registry entitled “DNS Resolver Information Keys” under the “Domain Name System (DNS) Parameters” with the following columns:
    Name
    Value Type
    Description
    Specification

The fields provided meet precedent for recent RR TYPE entries requested, namely the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections 14.1 and 14.2 (link). Additionally, the guidance in RFC 6895 was followed per IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC Editor to update all instance of “RFCXXXX” in the document with the final RFC number granted to the document upon publication. Instances of “RFCXXXX” can be found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes (see above).


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Yes.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Yes.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

The Expert Review defined as required for new RR types in RFC 6895 has taken place.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

N/A. The closest thing to this are the example contents of the new record type defined within the document.

2023-11-06
07 Tommy Jensen
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally …
Title: DNS Resolver Information

Current Version: draft-ietf-add-resolver-info-07


(1.a)  Who is the Document Shepherd for this document? 

Document Shepherd: Tommy Jensen


Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication?

Yes, the document shepherd has reviewed the latest document draft, but does not believe it is ready for forwarding to the IESG yet. This is only because there was one issue uncovered during initial shepherd review which needs WG consensus on the author’s proposed solution. Once that issue is closed, the document shepherd believes this document will be ready for the IESG.


(1.b)  Has the document had adequate review both from key WG members and from key non-WG members? 

Previously yes. However, the -07 draft (latest) has not had sufficient attention on its solution to an issue uncovered by the document shepherd’s first review. Otherwise the content has been thoroughly reviewed.


Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

Yes, but temporarily. The editors have been thorough in documenting their changes to the WG and responsive in issuing new versions. However, the WGLC passed with no opposition but also no on-list support voiced. The latest versions (-06 onward) were published post WGLC with changes the document shepherd suggested during initial review prior to this document being published which has not had positive acks that it addresses the identified problem.

We intend to close on this during IETF 118 and expect this question to update to “No concerns about reviews” soon.


(1.c)  Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML?

No, the WG has fairly broad DNS representation, and this draft does not leave that domain (no use of SVCB or other formats defined elsewhere, for example). The Expert Review for the new RR type has now also taken place.


(1.d)  Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of?  For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it.  In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. 

No. The shepherd has clearly stated that his sponsor has no intention of implementing, but it is due to a lack of scenario rather than opposition to architecture. The shepherd has agreed to advance and champion the document as a representation of WG consensus for use by others.


Has an IPR disclosure related to this document been filed?  If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue.

No IPR disclosures have been filed relating to this document as of November 6th 2023.


(1.e)  How solid is the WG consensus behind this document?  Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

It is a strong concurrence of a few individuals, with most of the WG previously expressing feedback now silent. WGLC was passed with no objections but also no other-than-author support.


(1.f)  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 entered into the ID Tracker.)

In short, no, the document shepherd does not believe there is a risk of escalation, appeal, or retaliation by malcontent parties if this document is published as an RFC.

Speaking as an industry member, the document shepherd is aware of parties who have no interest in implementing the mechanism described in this document (including his own employer), but none of these parties are opposed to the standard itself for use by other parties. The reasons for not implementing known to the document shepherd are rooted in product strategy reasoning, not ethical or security concerns that would translate to valid reasons to block publication.


(1.g)  Has the Document Shepherd personally verified that the document satisfies all ID nits?  (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are not enough; this check needs to be thorough. 

On November 6th, 2023, the document shepherd ran the idnits tool version 2.17.1 and found two nits:
• “Unused Reference: 'I-D.pp-add-resinfo' is defined on line 417, but no explicit reference was found in the text”
o This document is referenced in the Acknowledgements section at the end of the document, following the References section
o The tool is in error, and the authors and document shepherd agree having the reference is valuable as the referenced draft was a major source for this document

This nit should not prevent the document from proceeding through the publication process.


Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? 

An Expert Review for the new DNS RR type defined by this document has taken place. The document shepherd does not believe there are other reviews required for this document.


If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here.

Intended RFC status: Proposed Standard



(1.h)  Has the document split its references into normative and informative? 

Yes, the document splits normative and informative references.

The normative references, together with an indication of the type and whether they have been updated by later versions, are as follows:

I-D.ietf-add-ddr – Standards Track (not updated, in AUTH48)
I-D.ietf-add-dnr – Standards Track (not updated, in AUTH48)
RFC 1035 – Standards Track (updated by 28 RFCs, most recently RFC 8767)
RFC 2119BCP 14 (updated by RFC 8174)
RFC 6763 – Standards Track (updated by RFC 8553)
RFC 8126BCP 26 (not updated)
RFC 8174BCP 14 (not updated)
RFC 8446 – Standards Track (not updated)
RFC 8914 – Standards Track (not updated)
RFC 9156 – Standards Track (not updated)

The informative references, together with an indication of the type and whether they have been updated, are as follows:

I-D.pp-add-resinfo – intended for Standards Track, but expired (WG has rejected)
IANA-DNS – IANA’s “Domain Name System (DNS) Parameters” list
• (see http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4)
RFC 7858 – Standards Track (updated by RFC 8310)
RFC 8484 – Standards Track (not updated)
RFC 8499BCP 219 (not updated)
RFC 9250 – Standards Track (not updated)
RRTYPE – IANA’s “Resource Record (RR) TYPEs” list
• (see https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml)


Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? 

No.


If such normative references exist, what is the strategy for their completion? 

Not applicable.


Are there normative references that are downward references, as described in [RFC3967]?  If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967].

Not applicable. All normative references are either RFC-published Standards Track or BCP.


(1.i)  Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? 

Yes, the IANA considerations section exists. Yes, the IANA and RFC Editor requests are consistent with the rest of the document.

There are two IANA requests (document shepherd notes added in <> brackets):
•Create a new DNS RR TYPE with the following properties:
o Type: RESINFO
o Value: TBD
o Meaning: Resolver Information as Key/Value Pairs
o Reference: RFCXXXX
•Create a new registry entitled “DNS Resolver Information Keys” under the “Domain Name System (DNS) Parameters” with the following columns:
o Name
o Value Type
o Description
o Specification

The fields provided meet precedent for recent RR TYPE entries requested, namely the SVCB and HTTPS RR TYPEs defined in draft-ietf-dnsop-svcb-https-12 sections 14.1 and 14.2 (link). Additionally, the guidance in RFC 6895 was followed per IANA’s guidance to get the RR type Expert Review.

In addition to the two IANA-specific requests, there is a note to the RFC Editor to update all instance of “RFCXXXX” in the document with the final RFC number granted to the document upon publication. Instances of “RFCXXXX” can be found in Sections 7, 7.1, 7.2 (contained to the IANA considerations section).


If the document specifies protocol extensions, are reservations requested in appropriate IANA registries?  Are the IANA registries clearly identified? 

Yes (see above).


If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? 

Yes.


Does it suggest a reasonable name for the new registry?  See [RFC2434]. 

Yes.


If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation?

The Expert Review defined as required for new RR types in RFC 6895 has taken place.


(1.j)  Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker?

N/A. The closest thing to this are the example contents of the new record type defined within the document.

2023-11-05
07 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-07.txt
2023-11-05
07 Mohamed Boucadair New version approved
2023-11-05
07 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-11-05
07 Tirumaleswar Reddy.K Uploaded new revision
2023-10-23
06 Glenn Deen Added to session: IETF-118: add  Wed-0830
2023-10-04
06 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-06.txt
2023-10-04
06 Mohamed Boucadair New version approved
2023-10-04
06 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-10-04
06 Tirumaleswar Reddy.K Uploaded new revision
2023-09-20
05 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-05.txt
2023-09-20
05 Mohamed Boucadair New version approved
2023-09-20
05 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-09-20
05 Tirumaleswar Reddy.K Uploaded new revision
2023-09-12
04 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-04.txt
2023-09-12
04 Mohamed Boucadair New version approved
2023-09-12
04 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-09-12
04 Tirumaleswar Reddy.K Uploaded new revision
2023-07-25
03 David Lawrence This document now replaces draft-reddy-add-resolver-info instead of None
2023-07-24
03 Glenn Deen Notification list changed to tojens@microsoft.com because the document shepherd was set
2023-07-24
03 Glenn Deen Document shepherd changed to Tommy Jensen
2023-07-13
03 Glenn Deen
This draft has had an early DNS Directorate review and has been updated as a result.

The editors believe it is ready for WGLC which …
This draft has had an early DNS Directorate review and has been updated as a result.

The editors believe it is ready for WGLC which is now being issued.

This call will run for 3 weeks until August 3, 2023

-glenn deen  ADD co-chair
2023-07-13
03 Glenn Deen IETF WG state changed to In WG Last Call from WG Document
2023-07-04
03 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-03.txt
2023-07-04
03 (System) New version approved
2023-07-04
03 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-07-04
03 Tirumaleswar Reddy.K Uploaded new revision
2023-06-30
02 Johan Stenstam Request for Early review by DNSDIR Completed: Ready with Issues. Reviewer: Johan Stenstam. Sent review to list.
2023-06-14
02 Jim Reid Request for Early review by DNSDIR is assigned to Johan Stenstam
2023-06-12
02 Glenn Deen Requested Early review by DNSDIR
2023-05-26
02 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-02.txt
2023-05-26
02 Mohamed Boucadair New version approved
2023-05-26
02 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-05-26
02 Tirumaleswar Reddy.K Uploaded new revision
2023-03-29
01 Glenn Deen Added to session: IETF-116: add  Thu-0730
2023-02-22
01 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-01.txt
2023-02-22
01 (System) New version approved
2023-02-22
01 (System) Request for posting confirmation emailed to previous authors: "Tirumaleswar Reddy.K" , Mohamed Boucadair
2023-02-22
01 Tirumaleswar Reddy.K Uploaded new revision
2023-02-15
00 Tirumaleswar Reddy.K New version available: draft-ietf-add-resolver-info-00.txt
2023-02-15
00 Glenn Deen WG -00 approved
2023-02-15
00 Tirumaleswar Reddy.K Set submitter to "Tirumaleswar Reddy ", replaces to (none) and sent approval email to group chairs: add-chairs@ietf.org
2023-02-15
00 Tirumaleswar Reddy.K Uploaded new revision