Extended DNS Errors
draft-ietf-dnsop-extended-error-16

[Ballot comment]
Thank you for addressing my trivial DISCUSS. I have kept the rest of my COMMENTs for archiving purpose.

--- for archiving ---

Please find below some non-blocking COMMENTs. An answer will be appreciated.

I hope that this helps to improve the document,

Finally, I loved reading the acknowledgements section ;-)

Regards,

-éric

== COMMENTS ==
-- Section 2 --
For my own curiosity, why is there no added semantic in the INFO-CODE ? Such as a bit or a range for transient errors vs. permanent errors.

It is also a little unclear whether the EDE can happen multiple times (or is it implicit for EDNS0 option?)

-- Section 4.5 --
The "forged answer" is not qualified in the name but well in the definition examples. Suggest to rename it in "forged answer by policy" and also create another code for "forged answer for technical reason" (e.g., DNS64).

We could also wonder whether this code is an "error" code or a "warning" code. If the latter, then the "EDE" acronym does not really apply anymore (but this is cosmetic).

[Ballot comment]
Thank you for addressing my Discuss point!
It's probably worth a second look at the IANA considerations (see below),
and I do have a few other comments.

Section 1

Were you going to say something about EDE allowing stubs to stop after
SERVFAIL-due-to-DNSSEC-bogus instead of continuing on to a non-validating
resolver?

Section 2

(I note that BCP 18 likes a language indicator, and "intended for human consumption"
relies on humans to be language detectors, which is not always reliable.)

Section 3

  the truncation bit when dropping EDE options.  Because long EXTRA-
  TEXT fields may trigger truncation, which is undesirable given the
  supplemental nature of EDE.  Implementers and operators creating EDE
  options SHOULD avoid lengthy EXTRA-TEXT contents.

I think this was intended to be one sentence, not two?

Section 5.2

Are these two snippets consistent with each other?

  o  0 - 49151: First come, first served.
  o  49152 - 65280: Private use.
[...]
  INFO-CODE:  25-65535
  Purpose:  Unasigned
  Reference:  Section 5.2

Section 6

  unauthenticated information.  As such, EDE content should be treated
  only as diagnostic information and MUST NOT alter DNS protocol
  processing.  Until all DNS answers are authenticated via DNSSEC or

This looks an awful lot like the text Eric Orth didn't like when proposed
in the secdir review thread.

[Ballot comment]
Comments:

I know that in some crypto use cases, error codes are deliberately kept vague to frustrate analysis by attackers. Have the DNSSEC error codes been vetted for the same risk? Or does that not apply here?

Sec 5.2: since the shepherd write up, the maximum 16-bit integer has dropped to 65280. Have these code points gone somewhere?

Nits:

Sec 4.4 s/serever/server

Sec 6: s/validaion/validation

The redundant word in “This information is unauthenticated information” is redundant.

[Ballot discuss]
Sections 4.16 and 4.17 have some discussion that suggests that the
respective extended errors apply only to the current "local hop" of a DNS
query, and thus should not be propagated by a resolver/forwarder as part of
a response.  If so, this would be at odds with the discussion in Section 3
that leaves such bhavior as merely "implementation dependent" (giving some
MAY-level options).  I'm not sure what the intent is, here, so let's talk
about whether there's anything that should change.

[Also reminding myself to check that the allocation policy/ranges are updated
per Donald Eastlake's LC review]

[Ballot discuss]
Sections 4.16 and 4.17 have some discussion that suggests that the
respective extended errors apply only to the current "local hop" of a DNS
query, and thus should not be propagated by a resolver/forwarder as part of
a response.  If so, this would be at odds with the discussion in Section 3
that leaves such bhavior as merely "implementation dependent" (giving some
MAY-level options).  I'm not sure what the intent is, here, so let's talk
about whether there's anything that should change.

[Ballot comment]
Section 4.16

  The server is unable to respond to the request because the domain is
  blacklisted due to an internal security policy imposed by the
  operator of the server being directly talked to.

This wording implies that code 15 MUST NOT be copied by a
resolver/forwarder, which is somewhat at odds with Section 3.

Section 4.17

  The server is unable to respond to the request because the domain is
  blacklisted by a security policy imposed upon the server being talked
  to by an external requirement.  Note that how the imposed policy is

[ditto]

COMMENT

The RFC Editor is going to have to look closely at a lot of commas, but I'll
try to not dwell too much on them here.  I will note that "i.e." and "e.g."
are to be offset from other text both before and after, whether by comma,
parenthesis, dash, or other punctuation.

Section 1

  A good example of issues that would benefit by additional error
  information are errors caused by DNSSEC validation issues.  When a
  stub resolver queries a name which is DNSSEC bogus (using a

I know that "DNSSEC bogus" is a term of art, but not everyone will.  Would a
reference to RFC 8499 somewhere in here be worthwhile?

  option is to ask the next configured DNS resolver.  The result of
  trying the next resolver is one of two outcomes: either the next
  resolver also validates, and a SERVFAIL is returned again or the next
  resolver is not a validating resolver, and the user is returned a
  potentially harmful result.  With an Extended DNS Error (EDE) option

nit: some puncuation before "or the next resolver is also", please.

  Some combinations of extended error codes and RCODEs may seem
  nonsensical (such as resolver-specific extended error codes in
  responses from authoritative servers), so systems interpreting the
  extended error codes MUST NOT assume that a combination will make
  sense.  [...]

It's not really clear what actionable guidance there is in "MUST NOT assume
that [...] will make sense".

Section 1.1

Please use the current BCP 14 boilerplate from RFC 8174.

Section 2

      message.  The INFO-CODE serves as an index into the "Extended DNS
      Errors" registry Section 5.1.

nit: maybe "registry defined in"?

  o  EXTRA-TEXT, a variable length, UTF-8 encoded, text field that may
      hold additional textual information.  Note: EXTRA-TEXT may be zero
      octets in length, indicating there is no EXTRA-TEXT included.
      Care should be taken not to leak private information that an
      observer would not otherwise have access to, such as account
      numbers.

What's the internationalization plan for EXTRA-TEXT?  (See BCP 18.)
(Also, I'm apparently not imaginative enough to come up with a case where an
account number would be in an error message, so I am glad that you thought
of it and included it!)

Section 3

  supplemental nature of EDE.  Implementers and operators creating EDE
  options SHOULD avoid setting unnecessarily long EXTRA-TEXT contents
  to avoid truncation.

nit(?): "SHOULD avoid setting unnecessarily long" is not clearly actionable;
perhaps "should be mindful of such potential consequences of long EXTRA-TEXT
contents when generating EDE information" is better?

  When a resolver or forwarder receives an EDE option, whether or not
  (and how) to pass along EDE information on to their original client
  is implementation dependent.  Implementations MAY choose to not
  forward information, or they MAY choose to create a new EDE option(s)
  that conveys the information encoded in the received EDE.  When doing

Just to check: they can only create new EDE options if the relevant OPT
pseudo-RR was in the query from the client?  (I guess we don't say anything
about the resolver or forwarder adding such an option to its outbound query,
so maybe this is implicit.)

Section 4.4

Is a reference to RFC 8767 appropriate for "serve-stale"?

Section 4.8, 4.9

(Just to check: it is okay/conceivable to return both codes 7 and 8 for the
same response?)

Also, s/but but/but/

Setion 4.13

[I guess NSEC5 isn't happening, so we don't need to be future-proof for it?]

Section 4.21

  response.  A resolver that receives a query (with the RD bit clear)
  SHOULD include this EDE code in the REFUSED response.

It seems like it would be appropriate to remove the parentheses here.

Section 4.2

side note: it's a little surprising to see a "not supported" code be
described as specifically due to deprecation, to the exclusion of "not yet
supported".

Section 5.1

  Value  Name                Status    Reference
  -----  ----------------    ------    ------------------
    TBD  Extended DNS Error    TBD      [ This document ]

Shouldn't we say what "Status" we're requesting?

Section 5.2

  INFO-CODE:  0
  Purpose:  Other Error

Just to note: the Section 4.1 heading is just "Other", not "Other Error".

  INFO-CODE:  3
  Purpose:  Stale Answer
  Reference:  Section 4.4, [I-D.ietf-dnsop-serve-stale]

(That's RFC 8767 now.)

  INFO-CODE:  14
  Purpose:  Not Ready.
  Reference:  Section 4.15

nit: none of the other entries have a full stop.

  INFO-CODE:  19
  Purpose:  Stale NXDomain Answer
  Reference:  Section 4.20

nit: should "NXDOMAIN" be in all-caps?

Section 6

  Though DNSSEC continues to be deployed, unfortunately a significant
  number of clients (~11% according to [GeoffValidation]) that receive
  a SERVFAIL from a validating resolver because of a DNSSEC validaion
  issue will simply ask the next (potentially non-validating) resolver
  in their list, and thus don't get any of the protections which DNSSEC
  should provide.

"Don't get any of the protections" is a very strong statement, which is
arguably too strong, here.  Maybe just "don't get the reliability of
protection that DNSSEC should provide"?

Is the intent that allowing EDE to be attached to SERVFAIL will reduce the
occurrence of this "blindly proceed to the next (potentially non-validating)
resolver" behavior?  If so, we should say that!

  This information is unauthenticated information, and an attacker (e.g

I'm not actually sure which information "this information" is intended to
refer to.  At first I thought the SERVFAIL from the previous paragraph, but
this seems to be talking about a more generic issue (and neither does it
seem to be the EDE we're introducing in this document, since the sentence
ends "could insert an extended error response" as if that's in addition to
"this information").  Please clarify!

[Ballot comment]
Thank you for this document.  I found it straight forward and easy to read.

However, I was left wondering how DNS clients are expected to process any received errors and whether any more guidance should be given either for classes of errors, or perhaps for particular errors.  Or is the recovery action entirely left to the clients discretion?

E.g. is the default action if any of these errors are received to just throw up your hands, and inform the user with a "computer say's no" error, along with the details?  Or in some cases, does it make sense to retry the operation against the same server (perhaps for "Not Ready"), or in other cases does it make sense to try and same operation against another DNS server?

Thanks,
Rob

[Ballot discuss]
Thank you for the work put into this document. The document is clear, easy to read and quite useful.

I have a trivial to fix DISCUSS about BCP14 (see below).

I hope that this helps to improve the document,

Finally, I loved reading the acknowledgements section ;-)

Regards,

-éric

-- Section 1.1 --
Trivial to fix: please use BCP 14 boilerplate (see RFC 8174).

[Ballot comment]
Please find below some non-blocking COMMENTs. An answer will be appreciated.

I hope that this helps to improve the document,

Finally, I loved reading the acknowledgements section ;-)

Regards,

-éric

== COMMENTS ==
-- Section 2 --
For my own curiosity, why is there no added semantic in the INFO-CODE ? Such as a bit or a range for transient errors vs. permanent errors.

It is also a little unclear whether the EDE can happen multiple times (or is it implicit for EDNS0 option?)

-- Section 4.5 --
The "forged answer" is not qualified in the name but well in the definition examples. Suggest to rename it in "forged answer by policy" and also create another code for "forged answer for technical reason" (e.g., DNS64).

We could also wonder whether this code is an "error" code or a "warning" code. If the latter, then the "EDE" acronym does not really apply anymore (but this is cosmetic).

[Ballot comment]
** Thanks for responding to the SECDIR review (and thanks Catherine Meadows for the review).  I recommend applying the proposed text (suggested by Wes) to the Security Considerations that resulted from the discussion.  For me, it strikes a balance.

** Section 4.5.  Code = 4 (Forged answer) rolls up into a single code a number of rationales as to why the answer was forged (e.g., legal vs. malware).  However, when the request is blocked via blacklist, separate codes are not defined to convey the rationale.  Why isn’t there symmetry? 

** Section 6.  Per the example of [RFC2845] and [RFC8094] as being approaches where DNS answer could be authenticated, consider adding RFC8484 to the list too.

** Editorial Nits:
-- Section 1.  Typo. s/These extended  DNS error codes described in this document and can be used … /These extended DNS error codes described in this document can be used …/

-- Section 2.  Typo. s/ The INFO-CODE serves as an index into the "Extended DNS  Errors" registry Section 5.1./ The INFO-CODE serves as an index into the "Extended DNS Errors" registry defined in Section 5.1./

-- Section 4.  s/… in the "Extended DNS Errors" registry Section 5.1 ./ … in the "Extended DNS Errors" registry defined in Section 5.1 ./

-- Section 4.9. s/but but/but/

-- Section 4.4. Typo. s/serever/server/

-- Section 7.  “One author also wants to thank the band …”, is this really needed in an archival document?

[Ballot comment]
Some non-mushroom-infection-related thoughts:

[ section 2 ]
* I'm insufficiently fluent in Unicode but is some reference here appropriate?
  Perhaps RFC 5198 (if not 3629)?

* Is some text of the form "EDE text may be null terminated but MUST NOT be
  assumed to be; the length MUST be derived from the OPTION-LENGTH field"
  worth including?

[ section 4.1 ]
? s/a EXTRA-TEXT/an EXTRA-TEXT/ perhaps

[ section 4.5 ]
* should DNS64 servers send "Forged Answer" EDEs with a NOERROR synthesized
  AAAA response?

[ section 4.22 ]
* "Not Supported" because something has been deprecated seems sufficiently
  specific that perhaps "Deprecated" or "No longer supported" would be more
  appropriate?

[Ballot comment]
Bigger things:

The introduction is great, but the last paragraph drifts into normative language, which feels weird in an introduction.  I suggest moving that stuff off to a later section, even a new one.

Section 1.1 should use the more modern form of BCP 14.

I may need more DNS clue, but I'm wondering why any of the SHOULDs in the first paragraph of Section 3 are not MUSTs, or alternatively why I would ever deviate from what they're saying.

Lesser things:

Section 1:
* "... and so the stub resolvers only ..." -- s/resolvers/resolver's/
* "... is returned again or the next ..." -- add a comma after "again"
* "... described in this document and can be used  ..." -- remove "and"

Section 4.4:
* "... unable to resolve answer within ..." -- "an answer" or "the answer"

Section 4.9:
* "... validation, but but no ..." -- s/but but/but/

Section 4.16:
* "... operator of the server being directly talked to." -- "being directly queried", perhaps?

Section 4.25:
* "An authoritative server that cannot answer ..." -- remove "that", perhaps?

And with that, I'm off to check out Infected Mushroom.

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

The IANA Functions Operator has completed its review of draft-ietf-dnsop-extended-error-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

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

First, in the DNS EDNS0 Option Codes (OPT) registry on the Domain Name System (DNS) Parameters registry page located at:

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

a single, new option code will be registered as follows:

Value: [ TBD-at-Registration ]
Name: Extended DNS Error
Status:
Reference: [ RFC-to-be ]

IANA Question --> The current draft indicated that the Status field should have a value of "TBD" but the available choices for that field are "Standard," "Optional," and "On-hold." Since the intended status of the document is Standards Track, should the Status field be changed to "Standard?"

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

Second, a new registry is to be created called the "Extended DNS Error Codes registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols? Should it be located on the Domain Name System (DNS) Parameters registry page located at:

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

The new registry will be managed as follows (RFC8126):

0 - 49151: First come, first served.
49152 - 65280: Private use.

INFO-CODE Purpose Reference
-------------+----------------------------+-------------
0 Other Error [ RFC-to-be ]
1 Unsupported DNSKEY Algorithm [ RFC-to-be ]
2 Unsupported DS Digest Type [ RFC-to-be ]
3 Stale Answer [ RFC-to-be ]
[I-D.ietf-dnsop-serve-stale]
4 Forged Answer [ RFC-to-be ]
5 DNSSEC Indeterminite [ RFC-to-be ]
6 DNSSEC Bogus [ RFC-to-be ]
7 Signature Expired [ RFC-to-be ]
8 Signature Not Yet Valid [ RFC-to-be ]
9 DNSKEY Missing [ RFC-to-be ]
10 RRSIGs Missing [ RFC-to-be ]
11 No Zone Key Bit Set [ RFC-to-be ]
12 NSEC Missing [ RFC-to-be ]
13 Cached Error [ RFC-to-be ]
14 Not Ready [ RFC-to-be ]
15 Blocked [ RFC-to-be ]
16 Censored [ RFC-to-be ]
17 Filtered [ RFC-to-be ]
18 Prohibited [ RFC-to-be ]
19 Stale NXDomain Answer [ RFC-to-be ]
20 Not Authoritative [ RFC-to-be ]
21 Not Supported [ RFC-to-be ]
22 No Reachable Authority [ RFC-to-be ]
23 Network Error [ RFC-to-be ]
24 Invalid Data [ RFC-to-be ]
25 - 49151 Unassigned
49152 - 65280 Private Use

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

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

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-04-02):

From: The IESG
To: IETF-Announce
CC: barryleiba@gmail.com, tjw.ietf@gmail.com, dnsop-chairs@ietf.org, Tim Wicinski , dnsop@ietf.org, draft-ietf-dnsop-extended-error@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extended DNS Errors) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Extended DNS Errors'
  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 2020-04-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines an extensible method to return additional
  information about the cause of DNS errors.  Though created primarily
  to extend SERVFAIL to provide additional information about the cause
  of DNS and DNSSEC failures, the Extended DNS Errors option defined in
  this document allows all response types to contain extended error
  information.  Extended DNS Error information does not change the
  processing of RCODEs.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ballot/


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

(1) This document is Proposed Standard, and this is the type of RFC.

(2) 

Technical Summary:

  This document defines an extensible method to return additional
  information about the cause of DNS errors.  Though created primarily
  to extend SERVFAIL to provide additional information about the cause
  of DNS and DNSSEC failures, the Extended DNS Errors option defined
  in this document allows all response types to contain extended error
  information.

Working Group Summary:

  The document went through a rigorous consensus process, and there were
  several points which took a few iterations to resolve, but they were
  all resolved to strong approval from the working group.

Document Quality:

  There are no current implementations, but both software vendors and
  third party DNS providers are planning to implement these error codes
  now that the specifics have been agreed on.


Personnel:

Document Shepherd:  Tim Wicinski
Responsible Area Director:  Barry Leiba

(3)  The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar).  The shepherd feels
the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) WG Consensus is solid.  There has been many iterations and comments from a
broad spectrum of working group participants.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is a Normative reference to ietf-dnsop-serve-stale, but that
document is in the RFC-Editor queue.

(15) There are no downward normative references

(16)  This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

A New Extended DNS Error Code EDNS Option

(18)

The document calls for the creation of a new IANA Registry.

Registry Name: "Extended DNS Error"
Code point space:

  o  0 - 49151: First come, first served.
  o  49152 - 65535: Experimental / Private use.

Because the registry is first-come, first-served, no expert reviews for
future allocations are needed.

(19) N/A

(20) No Yang Necessary

(1) This document is Proposed Standard, and this is the type of RFC.

(2) 

Technical Summary:

  This document defines an extensible method to return additional
  information about the cause of DNS errors.  Though created primarily
  to extend SERVFAIL to provide additional information about the cause
  of DNS and DNSSEC failures, the Extended DNS Errors option defined
  in this document allows all response types to contain extended error
  information.

Working Group Summary:

  The document went through a rigorous consensus process, and there were
  several points which took a few iterations to resolve, but they were
  all resolved to strong approval from the working group.

Document Quality:

  There are no current implementations, but both software vendors and
  third party DNS providers are planning to implement these error codes
  now that the specifics have been agreed on.


Personnel:

Document Shepherd:  Tim Wicinski
Responsible Area Director:  Barry Lieba

(3)  The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar).  The shepherd feels
the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) WG Consensus is solid.  There has been many iterations and comments from a
broad spectrum of working group participants.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is a Normative reference to ietf-dnsop-serve-stale, but that
document is in the RFC-Editor queue.

(15) There are no downward normative references

(16)  This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

A New Extended DNS Error Code EDNS Option

(18)

The document calls for the creation of a new IANA Registry.

Registry Name: "Extended DNS Error"
Code point space:

  o  0 - 49151: First come, first served.
  o  49152 - 65535: Experimental / Private use.

Because the registry is first-come, first-served, no expert reviews for
future allocations are needed.

(19) N/A

(20) No Yang Necessary

(1) This document is Proposed Standard, and this is the type of RFC.

(2) 

Technical Summary:

  This document defines an extensible method to return additional
  information about the cause of DNS errors.  Though created primarily
  to extend SERVFAIL to provide additional information about the cause
  of DNS and DNSSEC failures, the Extended DNS Errors option defined
  in this document allows all response types to contain extended error
  information.

Working Group Summary:

  The document went through a rigorous consensus process, and there were
  several points which took a few iterations to resolve, but they were
  all resolved to strong approval from the working group.

Document Quality:

  There are no current implementations, but both software vendors and
  third party DNS providers are planning to implement these error codes
  now that the specifics have been agreed on.


Personnel:

Document Shepherd:  Tim Wicinski
Responsible Area Director:  Barry Lieba

(3)  The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (spelling/grammar).  The shepherd feels
the document is ready for publication.

(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) WG Consensus is solid.  There has been many iterations and comments from a
broad spectrum of working group participants.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) There is a Normative reference to ietf-dnsop-serve-stale, but that
document is in the RFC-Editor queue.

(15) There are no downward normative references

(16)  This RFC will not change any existing RFCs.

(17) The document shepherd confirmed the consistency and references of the
IANA Considerations section are accurate

A New Extended DNS Error Code EDNS Option

(18)

The document calls for the creation of a new IANA Registry.

Registry Name: "Extended DNS Error"
Code point space:

  o  0 - 49151: First come, first served.
  o  49152 - 65535: Experimental / Private use.

Because the registry is first-come, first-served, no expert reviews for
future allocations are needed.

(19) N/A

(20) No Yang Necessary