Guidance for NSEC3 Parameter Settings
draft-ietf-dnsop-nsec3-guidance-10

[Ballot comment]
My DISCUSS and comments were addressed in -09. Thanks!



Good document, nice to see operations feedback back into the IETF via a new BCP.

Resolved DISCUSS:

#1:  This document updates RFC 5155 but has no Updates: clause and no reference of this in the Abstract. In case this would not be seen as an Update:able offense, then the text "Note that this specification updates [RFC5155]" should be changed :)

Resolved comments:

    The algorithm field is not discussed by this document.

Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are discussed?

    The NSEC3PARAM flags field currently contains no flags, but
    individual NSEC3 records contain the "Opt-Out" flag

This reads a little odd. Because the IANA NSEC3param registry lists 1 flat, the opt-out flag:

https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1

Maybe a sentence more clearly stating there is currently only one flag defined and that is opt-out and then discuss it.

    are encouraged to use a flags value of 0 (zero)

And rewrite this to say "are encouraged to not use the opt-out flag" so if in the future we define another flag, we don't have to errata or Update: this document for this one line mentioning 0.

  The first
  hash is typically sufficient to discourage zone enumeration performed
  by "zone walking" an NSEC or NSEC3 chain.

NSEC uses no hashing, so this sentence reads a little odd. Perhaps:

  The first
  hash with NSEC3 is typically sufficient to discourage zone enumeration performed
  by "zone walking" an unhashed NSEC chain.


  If NSEC3 must be used, then an iterations count of 0 MUST be used to
  alleviate computational burdens.

I think we need a sentence here (or in the section 2.4 above) that explains the iterations count of 0 means 1 hashing operation is done. Eg it is an "extra iteration count". I'd like to prevent implementors from thinking nsec3 can be unhashed completely.

Appendix D needs a note to the RFC Editor to remove itself.

Appendix E lists a bunch of implementations. Normally, this would be placed in an Implementation Status section, that is removed before publication. Should this section really be contained within this document?

nits:

"within the Internet" ? I'd probably use "on the Internet" :)

"tamper-resistance proof" -> "tamper-resistant proof" ?

"repeating that hashing algorithm" -> "repeating that hashing using the same algorithm"

Remove "ftp" from the example list in Section 2.3 as we deprecated it? The less credit we give it, the better :)


    in deploying both RFC4470 or NSEC3

This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"

"and the zone resigned."  -> "and the full zone needs to be resigned."

"and lower their default acceptable limits over time." -> "but lower their default acceptable limits over time."

There is a weird rendering of  {RFC8914} instead of [RFC8914]

I think Petr Špaček would like to see his last name fixed :)

[Ballot comment]
Good document, nice to see operations feedback back into the IETF via a new BCP.

Resolved DISCUSS:

#1:  This document updates RFC 5155 but has no Updates: clause and no reference of this in the Abstract. In case this would not be seen as an Update:able offense, then the text "Note that this specification updates [RFC5155]" should be changed :)

Resolved comments:

    The algorithm field is not discussed by this document.

Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are discussed?

    The NSEC3PARAM flags field currently contains no flags, but
    individual NSEC3 records contain the "Opt-Out" flag

This reads a little odd. Because the IANA NSEC3param registry lists 1 flat, the opt-out flag:

https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1

Maybe a sentence more clearly stating there is currently only one flag defined and that is opt-out and then discuss it.

    are encouraged to use a flags value of 0 (zero)

And rewrite this to say "are encouraged to not use the opt-out flag" so if in the future we define another flag, we don't have to errata or Update: this document for this one line mentioning 0.

  The first
  hash is typically sufficient to discourage zone enumeration performed
  by "zone walking" an NSEC or NSEC3 chain.

NSEC uses no hashing, so this sentence reads a little odd. Perhaps:

  The first
  hash with NSEC3 is typically sufficient to discourage zone enumeration performed
  by "zone walking" an unhashed NSEC chain.


  If NSEC3 must be used, then an iterations count of 0 MUST be used to
  alleviate computational burdens.

I think we need a sentence here (or in the section 2.4 above) that explains the iterations count of 0 means 1 hashing operation is done. Eg it is an "extra iteration count". I'd like to prevent implementors from thinking nsec3 can be unhashed completely.

Appendix D needs a note to the RFC Editor to remove itself.

Appendix E lists a bunch of implementations. Normally, this would be placed in an Implementation Status section, that is removed before publication. Should this section really be contained within this document?

nits:

"within the Internet" ? I'd probably use "on the Internet" :)

"tamper-resistance proof" -> "tamper-resistant proof" ?

"repeating that hashing algorithm" -> "repeating that hashing using the same algorithm"

Remove "ftp" from the example list in Section 2.3 as we deprecated it? The less credit we give it, the better :)


    in deploying both RFC4470 or NSEC3

This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"

"and the zone resigned."  -> "and the full zone needs to be resigned."

"and lower their default acceptable limits over time." -> "but lower their default acceptable limits over time."

There is a weird rendering of  {RFC8914} instead of [RFC8914]

I think Petr Špaček would like to see his last name fixed :)

[Ballot discuss]
I've been sitting trying to work out in my mind if a BCP document should be requesting code points - and if I should change the position from a no objection to a discuss - and the more I think about this - I feel that a discuss here is probably the right option.

I'd like to discuss if both the sections of the document that utilize normative language and require additional code points aren't better suited to a standards track document.

[Ballot comment]
Thanks for the work put into this document.

Having read through the document, I would also like to support Paul's discuss since the document does seem to update RFC5155.  I also would like to second what Murray said about it seeming a little strange to see a BCP document updating a standards track document. 

Finally - I was a little surprised to see IANA actions in a document entitled "guidance for...." - not sure if anyone else agrees with me, but it seems strange to see a BCP document requesting IANA actions

[Ballot comment]
Thanks for this document, I found it easy to read and useful. I have only a few nits:

1. In the Introduction: “This sacrifices the tamper-resistance proof of non-
  existence offered by NSEC3”

That doesn’t parse. Probably what you mean is “This sacrifices the tamper-resistance of the proof of non-existence offered by NSEC3” (added “of the”)? Or "... the tamper-resistant proof" would also work.

2. In Sections 2.4 and 3.1, I suggest “re-signing” (signing again) instead of “resigning” (quitting).

3. Appendix B has “The table (Appendix C)
  below”

The “(Appendix C)” part appears to be a mistake? The table is uncaptioned, I guess you either should caption it and xref that caption, or just remove the xref?

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tim Wicinski for the shepherd's write-up and the WG consensus, I would have appreciated a little more text about the intended status though.

I hope that this helps to improve the document,

Regards,

-éric

I share other ADs' comments about the lack of formally updating

## Section 2

Suggest to change the title s/considerations/discussions/ as this section explains the recommendations of section 3.

## Section 3.2

S/near the time of publication/near the time of publication of this document/ ?

## Section 7.1

RFC 8174 should be normative

# NITS 

## Section 1
Should "zone apex" be explained ?

## Appendix C

I am not sure whether Peter Špaček appreciates his last name writing in the I-D ;-) (my first name, Éric, suffers from the same issue ;-) )

[Ballot comment]
# GEN AD review of draft-ietf-dnsop-nsec3-guidance-08

CC @larseggert

Thanks to Meral Shirazipour for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/s5hyTc3FVrHGhUW0kHVOGLVXTgo).

## Comments

### Section 3.2, paragraph 4
```
    Validating resolvers returning an insecure or SERVFAIL answer to
    their client after receiving and validating an unsupported NSEC3
    parameter from the authoritative server(s) SHOULD return an Extended
    DNS Error (EDE) {RFC8914} EDNS0 option of value (RFC EDITOR: TBD).
    Validating resolvers that choose to ignore a response with an
    unsupported iteration count (and do not validate the signature) MUST
    NOT return this EDE option.
```
{RFC8914} looks like a Markdown citation bug.

### Missing references

No reference entries found for: `[RFC8914]` and
`[draft-hardaker-dnsop-nsec3-guidance]`.

## Nits

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

### Stray characters

The text version of this document contains these HTML entities, which might
indicate issues with its XML source: `č`, `Š`, and `Č`

### Grammar/style

#### "Table of Contents", paragraph 1
```
. . . . . . . . . . 10 Appendix D. Github Version of This Document . . . . .
                                  ^^^^^^
```
The official name of this software platform is spelled with a capital "H".

#### Section 1.1, paragraph 1
```
lag [RFC5155], which specifies whether or not that NSEC3 record provides pro
                              ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

#### Section 2.3, paragraph 1
```
w, ftp, mail, imap, login, database, etc) can be used to quickly reveal a lar
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 5, paragraph 1
```
y Covering NSEC Records and DNSSEC On-line Signing", RFC 4470, DOI 10.17487/R
                                  ^^^^^^^
```
Do not mix variants of the same word ("on-line" and "online") within a single
text.

#### Section 7.1, paragraph 2
```
NSSEC zone enumeration algorithm", n.d.. Appendix A. Deployment measurements
                                      ^^
```
Two consecutive dots.

#### "Appendix A.", paragraph 2
```
Vixie * Tim Wicinski Appendix D. Github Version of This Document While this
                                  ^^^^^^
```
The official name of this software platform is spelled with a capital "H".

## Notes

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

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Thanks for the efforts on this document. I reviewed this document and haven't find transport related issues. However, I have observed

  - the updating RFC 5155 issue like others have, so, lets support Paul's discuss.
 
  - RFC 8174 should be in the normative reference.

[Ballot comment]
Thanks for the efforts on this document. I reviewed this document and haven't find transport related issues. However, I have observed

  - the updating RFC 5155 issue like others have, so, lets support Paul's discuss.
  - RFC 8174 should be in the normative reference.

[Ballot comment]
I support Paul's DISCUSS; basically, "What Roman said".  Also, for possible IESG conversation: Is it weird at all that a BCP is updating a Standards Track document?

A very minor point: I don't think you need Section 2.1.

I'm pretty sure the reference to RFC 8174 needs to be normative; it's part of the same BCP as RFC 2119, which you do already have as normative.

In Section 2.2:

OLD:
  "... whether or not that NSEC3 record provides proof of non-existence or not."
NEW:
  "... whether that NSEC3 record provides proof of non-existence."

Regarding the SHOULD in Section 3.2, what other action might a resolver legitimately return, and why?

Same question for the SHOULD in Section 4.

Why wasn't Appendix E done in the form of BCP 205?  Is the intent to keep it when the draft is published as an RFC?

[Ballot comment]
** I support Paul Wouter’s DISCUSS position.  Like Alvaro and Francesca also commented, this document appears to be changing the behavior of RFC5155.  It should formally update it in the meta data.  Specifically:

-- The language in Section 3.2. appears to “weaken” the guidance in Section 10.3 of RFC5155

-- Section 3.2 also seems to explicitly say it is updating RFC5155 with “[n]ote that this specification updates [RFC5155] …”

** Section 2.
  The following sections describe recommendations for setting
  parameters for NSEC3 and NSEC3PARAM.

I don’t believe this is accurate.  There are few tangible recommendations about iterations or salts in this section.  That’s in Section 3.

** Section 2.2.
  In general, NSEC3 with the Opt-Out flag enabled
  should only be used in large, highly dynamic zones with a small
  percentage of signed delegations.  Operationally, this allows for
  fewer signature creations when new delegations are inserted into a
  zone.  This is typically only necessary for extremely large
  registration points providing zone updates faster than real-time
  signing allows or when using memory-constrained hardware

Qualitative scales such as “large … dynamic zones” and “extremely large registration points” used.  Can the operational experience informing these statements be cited to suggest the scale?

** Section 3.1.
  Operators are encouraged to forgo using a salt entirely by using a
  zero-length salt value instead (represented as a "-" in the
  presentation format).

Section 2.4 seemed to take a stronger position on the lack of utility of the salt.  Is there a reason normative language isn’t being used?

[Ballot discuss]
#1:  This document updates RFC 5155 but has no Updates: clause and no reference of this in the Abstract. In case this would not be seen as an Update:able offense, then the text "Note that this specification updates [RFC5155]" should be changed :)

[Ballot comment]
Good document, nice to see operations feedback back into the IETF via a new BCP.

comments:

    The algorithm field is not discussed by this document.

Maybe add a reference pointer to RFC 8624 where algorithms for DNSSEC are discussed?

    The NSEC3PARAM flags field currently contains no flags, but
    individual NSEC3 records contain the "Opt-Out" flag

This reads a little odd. Because the IANA NSEC3param registry lists 1 flat, the opt-out flag:

https://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-1

Maybe a sentence more clearly stating there is currently only one flag defined and that is opt-out and then discuss it.

    are encouraged to use a flags value of 0 (zero)

And rewrite this to say "are encouraged to not use the opt-out flag" so if in the future we define another flag, we don't have to errata or Update: this document for this one line mentioning 0.

  The first
  hash is typically sufficient to discourage zone enumeration performed
  by "zone walking" an NSEC or NSEC3 chain.

NSEC uses no hashing, so this sentence reads a little odd. Perhaps:

  The first
  hash with NSEC3 is typically sufficient to discourage zone enumeration performed
  by "zone walking" an unhashed NSEC chain.


  If NSEC3 must be used, then an iterations count of 0 MUST be used to
  alleviate computational burdens.

I think we need a sentence here (or in the section 2.4 above) that explains the iterations count of 0 means 1 hashing operation is done. Eg it is an "extra iteration count". I'd like to prevent implementors from thinking nsec3 can be unhashed completely.

Appendix D needs a note to the RFC Editor to remove itself.

Appendix E lists a bunch of implementations. Normally, this would be placed in an Implementation Status section, that is removed before publication. Should this section really be contained within this document?

nits:

"within the Internet" ? I'd probably use "on the Internet" :)

"tamper-resistance proof" -> "tamper-resistant proof" ?

"repeating that hashing algorithm" -> "repeating that hashing using the same algorithm"

Remove "ftp" from the example list in Section 2.3 as we deprecated it? The less credit we give it, the better :)


    in deploying both RFC4470 or NSEC3

This read awkward. Perhaps "in deploying either RFC4470 or NSEC3"

"and the zone resigned."  -> "and the full zone needs to be resigned."

"and lower their default acceptable limits over time." -> "but lower their default acceptable limits over time."

There is a weird rendering of  {RFC8914} instead of [RFC8914]

I think Petr Špaček would like to see his last name fixed :)

[Ballot comment]
Thank you for the work on this document.

Before reading Alvaro's comment, I was going to bring up that the following paragraph in Section 3.2 could be confusing for a reader who is aware of the "Updates" RFC header.

  Note that this specification updates [RFC5155] by significantly
  decreasing the requirements originally specified in Section 10.3 of
  [RFC5155].  See the Security Considerations for arguments on how to
  handle responses with non-zero iteration count.

I see that Alvaro is questioning if this doc should actually update 5155, I personally don't have a strong opinion, and don't think it is absolutely necessary, although I am curious to hear if there has been discussion in the community about it. In any case I think it would be good to rephrase the above paragraph to avoid saying that this doc updates 5155 when it doesn't.

Thanks,
Francesca

[Ballot comment]
Should this document formally Update RFC5155?  Besides providing "guidance on setting NSEC3 parameters", there is also Normative language that seems similar to what is in rfc5155, but not the same.  For example:

In §3.2 this document says:

  Validating resolvers MAY return an insecure response to their clients
  when processing NSEC3 records with iterations larger than 0.  Note
  also that a validating resolver returning an insecure response MUST
  still validate the signature over the NSEC3 record to ensure the
  iteration count was not altered since record publication (see
  [RFC5155] section 10.3).

I couldn't find text in rfc5155 about how returning insecure responses is optional, but I did find this in §10.3 that seems related to the validation requirement:

  A resolver MAY treat a response with a higher value as insecure,
  after the validator has verified that the signature over the NSEC3
  RR is correct.


Reading further, §3.2 does say that "this specification updates [RFC5155]", but there's no indication in the header or anywhere else.

[Ballot comment]
Should this document formally Update RFC5155?  Besides providing "guidance on setting NSEC3 parameters", there is also Normative language that seems similar to what is in rfc5155, but not the same.  For example:

In §3.2 this document says:

  Validating resolvers MAY return an insecure response to their clients
  when processing NSEC3 records with iterations larger than 0.  Note
  also that a validating resolver returning an insecure response MUST
  still validate the signature over the NSEC3 record to ensure the
  iteration count was not altered since record publication (see
  [RFC5155] section 10.3).

I couldn't find text in rfc5155 about how returning insecure responses is optional, but I did find this in §10.3 that seems related to the validation requirement:

  A resolver MAY treat a response with a higher value as insecure,
  after the validator has verified that the signature over the NSEC3
  RR is correct.


Reading further, §3.2 does say that "this specification updates [RFC5155]".

[Ballot comment]
Hi,

Thanks for this document.  I found it mostly to be easy to read.

One minor point, I found it slightly confusing in various places as to whether "iterations" meant "total number of interactions" or the "iterations parameter" that refers to the number of extra interactions.  Hence I would suggest changing "iterations" to "iterations parameter" or "extra iterations" or "total iterations" in various places depending on the context to ensure that this it is clear/obvious in all places.

Regards,
Rob

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

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

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Extended DNS Error Codes registry on the Domain Name System (DNS) Parameters registry page located at:

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

a new registration is to be made as follows:

INFO-CODE: [ TBD-at-Registration ]
Purpose: Unsupported NSEC3 iterations value
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action 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,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-05-02):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-nsec3-guidance@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Guidance for NSEC3 parameter settings) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Guidance for NSEC3 parameter
settings'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-05-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


  NSEC3 is a DNSSEC mechanism providing proof of non-existence by
  asserting that there are no names that exist between two domain names
  within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly
  disclosing the bounding domain name pairs.  This document provides
  guidance on setting NSEC3 parameters based on recent operational
  deployment experience.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5155: DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4470: Minimally Covering NSEC Records and DNSSEC On-line Signing (Proposed Standard - Internet Engineering Task Force (IETF))

(1) This RFC is being requested as Best Current Practice (BCP), and this is the proper type of RFC, and it is indicated as such.


(2)

Technical Summary:

  NSEC3 is a DNSSEC mechanism providing proof of non-existence by
  promising there are no names that exist between two domainnames
  within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly
  disclosing the bounding domainname pairs.  This document provides
  guidance on setting NSEC3 parameters based on recent operational
  deployment experience.

Working Group Summary:

Working group consensus took some time, as the discussion about what were the correct values to
recommend.  After iterative testing, recommended values were agreed via working group consensus.

Document Quality:

There are existing implementations that are described in Appendix E.

Personnel:

Tim Wicinski is the Document Shepherd.

Warren Kumari is the R. A. D.

(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) The WG Consensus on this document is very solid.

(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) All normative references are in a clear state.

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

(18) N/A

(19) N/A

(20) No Yang Necessary

(1) This RFC is being requested as Best Current Practice (BCP), and this is the proper type of RFC, and it is indicated as such.


(2)

Technical Summary:

  NSEC3 is a DNSSEC mechanism providing proof of non-existence by
  promising there are no names that exist between two domainnames
  within a zone.  Unlike its counterpart NSEC, NSEC3 avoids directly
  disclosing the bounding domainname pairs.  This document provides
  guidance on setting NSEC3 parameters based on recent operational
  deployment experience.

Working Group Summary:

Working group consensus took some time, as the discussion about what were the correct values to
recommend.  After iterative testing, recommended values were agreed via working group consensus.

Document Quality:

There are existing implementations that are described in Appendix E.

Personnel:

Tim Wicinski is the Document Shepherd.

Warren Kumari is the R. A. D.

(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) The WG Consensus on this document is very solid.

(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) All normative references are in a clear state.

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

(18) N/A

(19) N/A

(20) No Yang Necessary