[DNSOP] Mohamed Boucadair's Discuss on draft-ietf-dnsop-rfc8624-bis-09: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-dnsop-rfc8624-bis-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8624-bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Wes, Warren,

Many thanks for the effort put into this specification.

Thanks to Nabeel Cocker for his first OPSDIR review and Wes for promptly
engaging with Nabeel.

Also, thanks to Éric, Tim, and authors for taking care comments shared as part
of IETF LC (extended LC to PS instead of Info + tag as this update 9157).

I will definitely ballot “Yes”, but I’d like to quickly discuss few points.

# DISCUSS

## Redundant with 8624?

I spent some time to understand whether this is a bis or an update vs. 8624.
The diff at
https://author-tools.ietf.org/diff?doc_1=rfc8624&doc_2=draft-ietf-dnsop-rfc8624-bis
shows several sections that are common (1.2, 5, 6) with some minor tweaks.
There is also other text that is in 8624 but was moved around (e.g., 2nd and
3rd para of 1.1 or the 2nd para in 1.3).

If this is an update, then we should explain why redundant text is
included/needed. Adding a clarification early in the document to explain the
intent would be sufficient, IMO. Ideally, I'd remove redundant text (e.g., be
replaced with references to the relevant sections in 8624).

## Deprecated values

###
https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml#dns-sec-alg-numbers-1
has the following:

12      GOST R 34.10-2001 (DEPRECATED)  ECC-GOST        Y       *      
[RFC5933][proposed standard][Change the status of GOST Signature Algorithms in
DNSSEC in the IETF stream to Historic]

While deprecation seems is no reflected in Table 2.

CURRENT:
 |12|ECC-GOST       |MUST NOT   |MAY        |MUST NOT   |MAY        |

Note that this deprecated value:

1       RSA/MD5 (DEPRECATED, see 5)     RSAMD5  N       Y      
[RFC3110][proposed standard][RFC4034][proposed standard]

was adequately handled in Table 2:

CURRENT:
   |1 |RSAMD5         |MUST NOT   |MUST NOT   |MUST NOT   |MUST NOT   |

### Idem, https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml has
the following:

3       GOST R 34.11-94 DEPRECATED      [RFC5933][Change the status of GOST
Signature Algorithms in DNSSEC in the IETF stream to Historic]

While, deprecation is not explicitly reflected in Table 3:

CURRENT:
   |3     |GOST R    |MUST NOT   |MAY        |MUST NOT  | MAY         |
   |      |34.11-94  |           |           |          |             |

## Modification policy

The registration policy for the two registries is "RFC Required", while the
deprecated values were modified with a status-change in the past. Should be
update the policy to be consistent with the practice?

## Instructions to fill new columns for some entries in the registry

There are no instructions about which values to use of the following entries in
the registry

252     Reserved for Indirect Keys      INDIRECT        N       N      
[RFC4034][proposed standard] 253     private algorithm       PRIVATEDNS      Y 
     Y       [RFC4034][proposed standard] 254     private algorithm OID  
PRIVATEOID      Y       Y       [RFC4034][proposed standard]


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Abstract

CURRENT:
   The document does not change the status (MUST, MAY, RECOMMENDED, etc)
   of any of the algorithms listed in RFC8624; that is the work of
   future documents.

* I would delete the last part of this sentence. No need to commit on something
that may or may not happen :-) * s/etc/etc.

# Section 1.3

CURRENT:
   [RFC2119] considers the term SHOULD equivalent to RECOMMENDED, and
   SHOULD NOT equivalent to NOT RECOMMENDED.  The authors of this
   document have chosen to use the terms RECOMMENDED and NOT
   RECOMMENDED, as this more clearly expresses the recommendations to
   implementers.

De we really need to say this? This is covered by 2119.

Also, the document when published will reflect the IETF consensus, not authors
preference.

# Section 2:

## Table 1 is redundant with Sections 7.1/7.2. I would delete and add a point
to these sections. Keep the content in one single place.

## Normative language for IANA considerations

Section 2 contains many statements that usually fall under an IANA
considerations section. Example of such text is (but there are other
occurrences):

CURRENT:
   "Implement for DNSSSEC Validation" columns SHALL follow the
   "Specification Required" policy as defined in [RFC8126] in order to
   promote continued evolution of DNSSEC algorithms and DNSSEC agility.
   New entries added through the "Specification Required" process will
   have the value of "MAY" for all columns.

When such text is in an IANA cons section, the use of the normative language
(SHALL) is avoided.

You have this right for other parts in that same section, e.g.,

CURRENT:
   Adding a new entry to, or changing existing values in, the "DNS
   System Algorithm Numbers" registry for the "Use for DNSSSEC Signing",
   "Use for DNSSSEC Validation", "Implement for DNSSSEC Signing", or
   "Implement for DNSSSEC Validation" columns to any other value than
   "MAY" requires a Standards Action.

# Section 3: Consider adding IANA notes

Given that the registry will be authoritative and that this text is important
to interpret the table, I wonder whether we need to transform some of the text
into IANA sections. For example,

CURRENT:
   When there are multiple RECOMMENDED algorithms in the "use" column,
   operators should choose the best algorithm according to local policy.

The are other similar occurrences that are worth considered as well.

# Section 4: [*] meaning

CURRENT:
   |0     |NULL (CDS |MUST NOT   |MUST NOT   |MUST NOT  | MUST NOT    |
   |      |only)     |[*]        |[*]        |[*]       | [*]         |

Unless I missed, I don’t see where we explain the meaning of [*].

# Section 6

The wording in rfc8624  seems more accurate (“a new” instead of “the key”, for
example).

As indicated above, my preference is to simply point the relevant section in
8624.

## Nits

## idnits is not happy with citations in the abstract

CURRENT:
  revised IANA DNSSEC considerations from [RFC9157].

## Section 2: Many "register"

OLD: registries registered with IANA

NEW: registries maintained by IANA

Cheers,
Med