Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices
draft-ietf-opsawg-mud-tls-14

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

IANA has completed its review of draft-ietf-opsawg-mud-tls-13. If any part of this review is inaccurate, please let us know.

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

IANA has questions about the third, fourth, fifth and sixth actions requested in the IANA Considerations section of this document.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

three new namespaces will be registered as follows:

ID: yang:iana-tls-profile
URI: urn:ietf:params:xml:ns:yang:iana-tls-profile
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-acl-tls
URI: urn:ietf:params:xml:ns:yang:ietf-acl-tls
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-mud-tls
URI: urn:ietf:params:xml:ns:yang:ietf-mud-tls
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

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

three new YANG modules will be registered as follows:

Name: iana-tls-profile
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-tls-profile
Prefix: ianatp
Module:
Reference: [ RFC-to-be ]

Name: ietf-acl-tls
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-acl-tls
Prefix: ietf-acl-tls
Module:
Reference: [ RFC-to-be ]

Name: ietf-mud-tls
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-mud-tls
Prefix: ietf-mud-tls
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

Third, a new registry is to be created called iana-tls-profile YANG Module in the YANG Modules registry group on:

https://www.iana.org/protocols

the initial version of the iana-tls-profile YANG module is documented in Section 5.3 of the current draft. The following note will be added to the new registry:

- tls-version and dtls-version values must not be directly added to the iana-tls-profile YANG module. They must instead be respectively added to the "ACL TLS Version Codes", and "ACL DTLS Version Codes" registries.

- (D)TLS parameters must not be directly added to the iana-tls-profile YANG module. They must instead be added to the "ACL (D)TLS Parameters" registry.

The registration procedure for the new registry is Expert Review as defined by RFC8126.

IANA Question --> The authors, in this section, provide this text: "The registration procedure for "ietf-acl-tls" YANG module will be Specification Required, as defined by [RFC8126]." ietf-acl-tls does get registered as a YANG module, but it does not get a new YANG Module registry. What is the intent of this text?

Fourth, a new registry will be created called the ACL TLS Version Codes registry. The new registry will be managed via Expert Review as defined in RFC8126.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry group? If it needs a new group, does it also need a new category at http://www.iana.org/protocols (and if so, should the group and the category have the same name)?

A note will be added to the top of the new registry as follows:

When this registry is modified, the YANG module iana-tls-profile must be updated as defined in [ RFC-to-be ].

There are initial registrations in the new registry as follows:

Value: 1
Label: tls12
Description: TLS Version 1.2
Reference: [RFC5246]

Value: 2
Label: tls13
Description: TLS Version 1.3
Reference: [RFC8446]

Fifth, a new registry will be created called the ACL DTLS Version Codes registry. The new registry will be managed via Expert Review as defined in RFC8126.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry group? If it needs a new group, does it also need a new category at http://www.iana.org/protocols (and if so, should the group and the category have the same name)?

A note will be added to the top of the new registry as follows:

When this registry is modified, the YANG module iana-tls-profile must be updated as defined in [ RFC-to-be ].

There are initial registrations in the new registry as follows:

Value: 1
Label: dtls12
Description: DTLS Version 1.2
Reference: [RFC6347]

Value: 2
Label: dtls13
Description: DTLS Version 1.3
Reference: [RFC9147]

Sixth, a new registry will be created called the ACL (D)TLS parameters registry. The new registry will be managed via Expert Review as defined in RFC8126.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry group? If it needs a new group, does it also need a new category at http://www.iana.org/protocols (and if so, should the group and the category have the same name)?

A note will be added to the top of the new registry as follows:

When this registry is modified, the YANG module iana-tls-profile must be updated as defined in [ RFC-to-be ].

There are initial registrations in the new registry as follows (for each of the initial registrations the Reference will be set to [ RFC-to-be ]):

Parameter Name: extension-type
YANG Type: uint16
JSON Type: Number
Description: Extension type

Parameter Name: supported-group
YANG Type: uint16
JSON Type: Number
Description: Supported group

Parameter Name: signature-algorithm
YANG Type: uint16
JSON Type: Number
Description: Signature algorithm

Parameter Name: psk-key-exchange-mode
YANG Type: uint8
JSON Type: Number
Description: pre-shared key exchange mode

Parameter Name: application-protocol
YANG Type: string
JSON Type: String
Description: Application protocol

Parameter Name: cert-compression-algorithm
YANG Type: uint16
JSON Type: Number
Description: Certificate compression algorithm

Parameter Name: cipher-algorithm
YANG Type: uint16
JSON Type: Number
Description: Cipher Suite

Parameter Name: tls-version
YANG Type: enumeration
JSON Type: String
Description: TLS version

Parameter Name: dtls-version
YANG Type: enumeration
JSON Type: String
Description: DTLS version

Seventh, in the MUD Extensions Registry in the Manufacturer Usage Description (MUD) registry group located at:

https://www.iana.org/assignments/mud/

a single new registration will be made as follows:

Value: ietf-mud-tls
Reference: [ RFC-to-be ]

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

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

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-03-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-opsawg-mud-tls@ietf.org, opsawg-chairs@ietf.org, opsawg@ietf.org, paul.wouters@aiven.io, thomas.fossati@arm.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices) to Proposed Standard


The IESG has received a request from the Operations and Management Area
Working Group WG (opsawg) to consider the following document: - 'Manufacturer
Usage Description (MUD) (D)TLS Profiles for IoT Devices'
  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-03-11. 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 memo extends the Manufacturer Usage Description (MUD)
  specification to incorporate (D)TLS profile parameters.  This allows
  a network security service to identify unexpected (D)TLS usage, which
  can indicate the presence of unauthorized software or malware on an
  endpoint.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud-tls/



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8701: Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility (Informational - Internet Engineering Task Force (IETF))

** Last updated: 2022-12-12 **

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The former.

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

At CfA (joint OPSAWG and TLS) [CFA] the potential for ossification associated
with the proposed mechanism was raised from members of the TLS WG.

[CFA] https://mailarchive.ietf.org/arch/msg/opsawg/5DKU6h7qb1kgKur5Kt5nRr8UxeY/

At adoption [IETF-00], the OPSAWG chair (Joe Clarke) suggested that:

```
[...] it might be good to get a more formal early review of this work from
SecDir so that the WG can focus on additional items required to move the work
forward.
```

There has been no early SecDir involvement AFAICS though.

[IETF-00] https://mailarchive.ietf.org/arch/msg/opsawg/WkEGiLbHHY2RQd0NDbcCRSHzj7Y/

Tom Petch in his WGLC review [TOM1] raised the point of splitting the document
and publish the IANA-maintained YANG module separately.

[TOM1] https://mailarchive.ietf.org/arch/msg/opsawg/uDo7E4rXITp479Br5rz0EIExmjE/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No; on the contrary, Tom has made clear that he wouldn't appeal [TOM2]:

"""
I would not take this issue to an appeal in case the Document Shepherd is
wondering what to put in section 3.
"""

[TOM2] https://mailarchive.ietf.org/arch/msg/opsawg/t5fkjKo0l1oVccs_yESUEb-A1aU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The document  has no "Implementation Status" section.  I contacted the authors
and they said they are not aware of existing implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the TLS WG being the obvious candidate.  AFAICS, except for CfA, the TLS
WG has not been directly involved in reviewing.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Xufeng Liu has provided the YANG Doctor review, which the authors have addressed
in -11.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document defines three YANG modules:

* iana-tls-profile
* ietf-acl-tls
* ietf-mud-tls

All modules validate without warnings.

Re: NMDA.  Similar to MUD (RFC 8250), the YANG modules specified in this draft
are not meant to be accessed via NETCONF/RESTCONF.  See Section 8, last
paragraph [NMDA].

[NMDA] https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-10.html#section-8-3

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no other formal language in the document apart from YANG.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.  Before or in parallel with the AD handover though, given the strong
security focus of the document, I suggest widening the reviewers' pool to
include the TLS WG and the Security Directorate.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

See 9.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the right track for this document. All related DT
attributes look good.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All three authors have stated that they are not aware of any IPR. [HENK-IPR]
No IPR disclosures have been submitted directly on either the individual or the
IETF draft.

[HENK-IPR] https://mailarchive.ietf.org/arch/msg/opsawg/wOD9WOGFP4uAWCxHdwKtPOPTCMs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has three authors, all of which willing to be listed as such ;-)
There are no further contributors listed and none is expected.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.  Running idnits on version -09 of the document reports 5 errors, 3
warnings and 9 comments [IDNITS-09].  2/5 errors look like false positives:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
  ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)

because the document *really* needs to normatively reference version 1.2 of TLS
and DTLS.

[IDNITS-09] https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-09.txt

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

Not that I can see.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The only normative reference behind paywall is:

  [X690]    ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

Multiple other IETF standards depend on this, so I reckon there's no problem.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The normative reference to TLS GREASE [RFC8701] makes sense in the context of
this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

draft-ietf-netconf-crypto-types [NCT] is the only normative dependency which is
still an I-D.  At the time of writing, the document is past WGLC in the NETCONF
WG.

[NCT] https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It all looks good to me.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

* "ACL TLS Version Codes"
* "ACL DTLS Version Codes"
* "ACL (D)TLS parameters"

In all cases there are no explicit instructions for the DE.

The first two registries have self-evident semantics, so the lack of
instructions is not a problem.

The third one references two *very* large (D)TLS registries as its
authoritative source:

a) https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
b) https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

I think it should be made more clear what are the criteria for picking items
from the (D)TLS registries and placing them in the new "ACL (D)TLS parameters"
registry. The pre-populated table is not particularly helpful for devising the
underlying criterion because its values are gathered from a mix of sources.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

** Last updated: 2022-12-12 **

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The former.

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

At CfA (joint OPSAWG and TLS) [CFA] the potential for ossification associated
with the proposed mechanism was raised from members of the TLS WG.

[CFA] https://mailarchive.ietf.org/arch/msg/opsawg/5DKU6h7qb1kgKur5Kt5nRr8UxeY/

At adoption [IETF-00], the OPSAWG chair (Joe Clarke) suggested that:

```
[...] it might be good to get a more formal early review of this work from
SecDir so that the WG can focus on additional items required to move the work
forward.
```

There has been no early SecDir involvement AFAICS though.

[IETF-00] https://mailarchive.ietf.org/arch/msg/opsawg/WkEGiLbHHY2RQd0NDbcCRSHzj7Y/

Tom Petch in his WGLC review [TOM1] raised the point of splitting the document
and publish the IANA-maintained YANG module separately.

[TOM1] https://mailarchive.ietf.org/arch/msg/opsawg/uDo7E4rXITp479Br5rz0EIExmjE/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No; on the contrary, Tom has made clear that he wouldn't appeal [TOM2]:

"""
I would not take this issue to an appeal in case the Document Shepherd is
wondering what to put in section 3.
"""

[TOM2] https://mailarchive.ietf.org/arch/msg/opsawg/t5fkjKo0l1oVccs_yESUEb-A1aU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The document  has no "Implementation Status" section.  I contacted the authors
and they said they are not aware of existing implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the TLS WG being the obvious candidate.  AFAICS, except for CfA, the TLS
WG has not been directly involved in reviewing.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Xufeng Liu has provided the YANG Doctor review, which the authors have addressed
in -11.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document defines three YANG modules:

* iana-tls-profile
* ietf-acl-tls
* ietf-mud-tls

All modules validate without warnings.

Re: NMDA.  Similar to MUD (RFC 8250), the YANG modules specified in this draft
are not meant to be accessed via NETCONF/RESTCONF.  See Section 8, last
paragraph [NMDA].

[NMDA] https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-10.html#section-8-3

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no other formal language in the document apart from YANG.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.  Before or in parallel with the AD handover though, given the strong
security focus of the document, I suggest widening the reviewers' pool to
include the TLS WG and the Security Directorate.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

See 9.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the right track for this document. All related DT
attributes look good.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All three authors have stated that they are not aware of any IPR. [HENK-IPR]
No IPR disclosures have been submitted directly on either the individual or the
IETF draft.

[HENK-IPR] https://mailarchive.ietf.org/arch/msg/opsawg/wOD9WOGFP4uAWCxHdwKtPOPTCMs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has three authors, all of which willing to be listed as such ;-)
There are no further contributors listed and none is expected.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.  Running idnits on version -09 of the document reports 5 errors, 3
warnings and 9 comments [IDNITS-09].  2/5 errors look like false positives:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
  ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)

because the document *really* needs to normatively reference version 1.2 of TLS
and DTLS.

[IDNITS-09] https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-09.txt

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

Not that I can see.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The only normative reference behind paywall is:

  [X690]    ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

Multiple other IETF standards depend on this, so I reckon there's no problem.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The normative reference to TLS GREASE [RFC8701] makes sense in the context of
this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

draft-ietf-netconf-crypto-types [NCT] is the only normative dependency which is
still an I-D.  At the time of writing, the document is past WGLC in the NETCONF
WG.

[NCT] https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It all looks good to me.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

* "ACL TLS Version Codes"
* "ACL DTLS Version Codes"
* "ACL (D)TLS parameters"

In all cases there are no explicit instructions for the DE.

The first two registries have self-evident semantics, so the lack of
instructions is not a problem.

The third one references two *very* large (D)TLS registries as its
authoritative source:

a) https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
b) https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

I think it should be made more clear what are the criteria for picking items
from the (D)TLS registries and placing them in the new "ACL (D)TLS parameters"
registry. The pre-populated table is not particularly helpful for devising the
underlying criterion because its values are gathered from a mix of sources.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Xufeng Liu. Sent review to list. Submission of review completed at an earlier date.

** Last updated: 2022-10-15 **

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The former.

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

At CfA (joint OPSAWG and TLS) [CFA] the potential for ossification associated
with the proposed mechanism was raised from members of the TLS WG.

[CFA] https://mailarchive.ietf.org/arch/msg/opsawg/5DKU6h7qb1kgKur5Kt5nRr8UxeY/

At adoption [IETF-00], the OPSAWG chair (Joe Clarke) suggested that:

```
[...] it might be good to get a more formal early review of this work from
SecDir so that the WG can focus on additional items required to move the work
forward.
```

There has been no early SecDir involvement AFAICS though.

[IETF-00] https://mailarchive.ietf.org/arch/msg/opsawg/WkEGiLbHHY2RQd0NDbcCRSHzj7Y/

Tom Petch in his WGLC review [TOM1] raised the point of splitting the document
and publish the IANA-maintained YANG module separately.

[TOM1] https://mailarchive.ietf.org/arch/msg/opsawg/uDo7E4rXITp479Br5rz0EIExmjE/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No; on the contrary, Tom has made clear that he wouldn't appeal [TOM2]:

"""
I would not take this issue to an appeal in case the Document Shepherd is
wondering what to put in section 3.
"""

[TOM2] https://mailarchive.ietf.org/arch/msg/opsawg/t5fkjKo0l1oVccs_yESUEb-A1aU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The document  has no "Implementation Status" section.  I contacted the authors
and they said they are not aware of existing implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the TLS WG being the obvious candidate.  AFAICS, except for CfA, the TLS
WG has not been directly involved in reviewing.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

At the time of writing, there has been no formal YANG Doctor review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document defines three YANG modules:

* iana-tls-profile
* ietf-acl-tls
* ietf-mud-tls

All modules validate without warnings.

Re: NMDA.  Similar to MUD (RFC 8250), the YANG modules specified in this draft
are not meant to be accessed via NETCONF/RESTCONF.  See Section 8, last
paragraph [NMDA].

[NMDA] https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-10.html#section-8-3

Cheers,

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no other formal language in the document apart from YANG.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.  Before or in parallel with the AD handover though, given the strong
security focus of the document, I suggest widening the reviewers' pool to
include the TLS WG and the Security Directorate.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

See 9.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the right track for this document. All related DT
attributes look good.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All three authors have stated that they are not aware of any IPR. [HENK-IPR]
No IPR disclosures have been submitted directly on either the individual or the
IETF draft.

[HENK-IPR] https://mailarchive.ietf.org/arch/msg/opsawg/wOD9WOGFP4uAWCxHdwKtPOPTCMs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has three authors, all of which willing to be listed as such ;-)
There are no further contributors listed and none is expected.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.  Running idnits on version -09 of the document reports 5 errors, 3
warnings and 9 comments [IDNITS-09].  2/5 errors look like false positives:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
  ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)

because the document *really* needs to normatively reference version 1.2 of TLS
and DTLS.

[IDNITS-09] https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-09.txt

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

Not that I can see.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The only normative reference behind paywall is:

  [X690]    ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

Multiple other IETF standards depend on this, so I reckon there's no problem.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The normative reference to TLS GREASE [RFC8701] makes sense in the context of
this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

draft-ietf-netconf-crypto-types [NCT] is the only normative dependency which is
still an I-D.  At the time of writing, the document is past WGLC in the NETCONF
WG.

[NCT] https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It all looks good to me.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

* "ACL TLS Version Codes"
* "ACL DTLS Version Codes"
* "ACL (D)TLS parameters"

In all cases there are no explicit instructions for the DE.

The first two registries have self-evident semantics, so the lack of
instructions is not a problem.

The third one references two *very* large (D)TLS registries as its
authoritative source:

a) https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
b) https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

I think it should be made more clear what are the criteria for picking items
from the (D)TLS registries and placing them in the new "ACL (D)TLS parameters"
registry. The pre-populated table is not particularly helpful for devising the
underlying criterion because its values are gathered from a mix of sources.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The former.

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

At CfA (joint OPSAWG and TLS) [CFA] the potential for ossification associated
with the proposed mechanism was raised from members of the TLS WG.

[CFA] https://mailarchive.ietf.org/arch/msg/opsawg/5DKU6h7qb1kgKur5Kt5nRr8UxeY/

At adoption [IETF-00], the OPSAWG chair (Joe Clarke) suggested that:

```
[...] it might be good to get a more formal early review of this work from
SecDir so that the WG can focus on additional items required to move the work
forward.
```

There has been no early SecDir involvement AFAICS though.

[IETF-00] https://mailarchive.ietf.org/arch/msg/opsawg/WkEGiLbHHY2RQd0NDbcCRSHzj7Y/

Tom Petch in his WGLC review [TOM1] raised the point of splitting the document
and publish the IANA-maintained YANG module separately.

[TOM1] https://mailarchive.ietf.org/arch/msg/opsawg/uDo7E4rXITp479Br5rz0EIExmjE/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No; on the contrary, Tom has made clear that he wouldn't appeal [TOM2]:

"""
I would not take this issue to an appeal in case the Document Shepherd is
wondering what to put in section 3.
"""

[TOM2] https://mailarchive.ietf.org/arch/msg/opsawg/t5fkjKo0l1oVccs_yESUEb-A1aU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

The document  has no "Implementation Status" section.  I contacted the authors
and they said they are not aware of existing implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the TLS WG being the obvious candidate.  AFAICS, except for CfA, the TLS
WG has not been directly involved in reviewing.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

At the time of writing, there has been no formal YANG Doctor review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document defines three YANG modules:

* iana-tls-profile
* ietf-acl-tls
* ietf-mud-tls

All modules validate without warnings.

Re: NMDA.  Similar to MUD (RFC 8250), the YANG modules specified in this draft
are not meant to be accessed via NETCONF/RESTCONF.  See Section 8, last
paragraph [NMDA].

[NMDA] https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-10.html#section-8-3

Cheers,

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no other formal language in the document apart from YANG.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.  Before or in parallel with the AD handover though, given the strong
security focus of the document, I suggest widening the reviewers' pool to
include the TLS WG and the Security Directorate.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

See 9.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the right track for this document. All related DT
attributes look good.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All three authors have stated that they are not aware of any IPR. [HENK-IPR]
No IPR disclosures have been submitted directly on either the individual or the
IETF draft.

[HENK-IPR] https://mailarchive.ietf.org/arch/msg/opsawg/wOD9WOGFP4uAWCxHdwKtPOPTCMs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has three authors, all of which willing to be listed as such ;-)
There are no further contributors listed and none is expected.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.  Running idnits on version -09 of the document reports 5 errors, 3
warnings and 9 comments [IDNITS-09].  2/5 errors look like false positives:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
  ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)

because the document *really* needs to normatively reference version 1.2 of TLS
and DTLS.

[IDNITS-09] https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-09.txt

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

Not that I can see.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The only normative reference behind paywall is:

  [X690]    ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

Multiple other IETF standards depend on this, so I reckon there's no problem.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The normative reference to TLS GREASE [RFC8701] makes sense in the context of
this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

draft-ietf-netconf-crypto-types [NCT] is the only normative dependency which is
still an I-D.  At the time of writing, the document is past WGLC in the NETCONF
WG.

[NCT] https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It all looks good to me.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

* "ACL TLS Version Codes"
* "ACL DTLS Version Codes"
* "ACL (D)TLS parameters"

In all cases there are no explicit instructions for the DE.

The first two registries have self-evident semantics, so the lack of
instructions is not a problem.

The third one references two *very* large (D)TLS registries as its
authoritative source:

a) https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
b) https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

I think it should be made more clear what are the criteria for picking items
from the (D)TLS registries and placing them in the new "ACL (D)TLS parameters"
registry. The pre-populated table is not particularly helpful for devising the
underlying criterion because its values are gathered from a mix of sources.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

*** in progress, missing bits tagged "TBC(tho)" ***

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The former.

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

At CfA (joint OPSAWG and TLS) [CFA] the potential for ossification associated
with the proposed mechanism was raised from members of the TLS WG.

[CFA] https://mailarchive.ietf.org/arch/msg/opsawg/5DKU6h7qb1kgKur5Kt5nRr8UxeY/

At adoption [IETF-00], the OPSAWG chair (Joe Clarke) suggested that:

```
[...] it might be good to get a more formal early review of this work from
SecDir so that the WG can focus on additional items required to move the work
forward.
```

There has been no early SecDir involvement AFAICS though.

[IETF-00] https://mailarchive.ietf.org/arch/msg/opsawg/WkEGiLbHHY2RQd0NDbcCRSHzj7Y/

Tom Petch in his WGLC review [TOM1] raised the point of splitting the document
and publish the IANA-maintained YANG module separately.

[TOM1] https://mailarchive.ietf.org/arch/msg/opsawg/uDo7E4rXITp479Br5rz0EIExmjE/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No; on the contrary, Tom has made clear that he wouldn't appeal [TOM2]:

"""
I would not take this issue to an appeal in case the Document Shepherd is
wondering what to put in section 3.
"""

[TOM2] https://mailarchive.ietf.org/arch/msg/opsawg/t5fkjKo0l1oVccs_yESUEb-A1aU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

I don't know. TBC(tho)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the TLS WG being the obvious candidate.  AFAICS, apart from CfA, the TLS
WG has not been directly involved.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

At the time of writing, there has been no formal YANG Doctor review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document defines three YANG modules:

* iana-tls-profile
* ietf-acl-tls
* ietf-mud-tls

All modules validate without warnings.

Re: NMDA.  I don't know.  TBC(tho)

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no other formal language in the document apart from YANG.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.  Before or in parallel with the AD handover though, given the strong
security focus of the document, I suggest widening the reviewers' pool to
include the TLS WG and the Security Directorate.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

See 9.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the right track for this document. All related DT
attributes look good.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All three authors have stated that they are not aware of any IPR. [HENK-IPR]
No IPR disclosures have been submitted directly on either the individual or the
IETF draft.

[HENK-IPR] https://mailarchive.ietf.org/arch/msg/opsawg/wOD9WOGFP4uAWCxHdwKtPOPTCMs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has three authors, all of which willing to be listed as such ;-)
There are no further contributors listed and none is expected.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.  Running idnits on version -09 of the document reports 5 errors, 3
warnings and 9 comments [IDNITS-09].  2/5 errors look like false positives:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
  ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)

because the document *really* needs to normatively reference version 1.2 of TLS
and DTLS.

[IDNITS-09] https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-09.txt

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

Not that I can see.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The only normative reference behind paywall is:

  [X690]    ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

Multiple other IETF standards depend on this, so I reckon there's no problem.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The normative reference to TLS GREASE [RFC8701] makes sense in the context of
this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

draft-ietf-netconf-crypto-types [NCT] is the only I-D which is a normative
dependency.  At the time of writing, the document is past WGLC in the NETCONF
WG.

[NCT] https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It all looks good to me.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

* "ACL TLS Version Codes"
* "ACL DTLS Version Codes"
* "ACL (D)TLS parameters"

There are no explicit instructions for the DE,

The first two registries have self-evident semantics, so the lack of
instructions is not a problem.

The third one references two *very* large (D)TLS registries as the
authoritative source:

a) https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
b) https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

I think it should be made more clear what are the criteria for picking items
from the (D)TLS registries and placing them in the new "ACL (D)TLS parameters"
registry.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

*** in progress, missing bits tagged "TBC(tho)" ***

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The former.

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

At CfA (joint OPSAWG and TLS) [CFA] the potential for ossification associated
with the proposed mechanism was raised from members of the TLS WG.

[CFA] https://mailarchive.ietf.org/arch/msg/opsawg/5DKU6h7qb1kgKur5Kt5nRr8UxeY/

At adoption [IETF-00], the OPSAWG chair (Joe Clarke) suggested that:

```
[...] it might be good to get a more formal early review of this work from
SecDir so that the WG can focus on additional items required to move the work
forward.
```

There has been no early SecDir involvement AFAICS though.

[IETF-00] https://mailarchive.ietf.org/arch/msg/opsawg/WkEGiLbHHY2RQd0NDbcCRSHzj7Y/

Tom Petch in his WGLC review [TOM1] raised the point of splitting the document
and publish the IANA-maintained YANG module separately.

[TOM1] https://mailarchive.ietf.org/arch/msg/opsawg/uDo7E4rXITp479Br5rz0EIExmjE/

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No; on the contrary, Tom has made clear that he wouldn't appeal [TOM2]:

"""
I would not take this issue to an appeal in case the Document Shepherd is
wondering what to put in section 3.
"""

[TOM2] https://mailarchive.ietf.org/arch/msg/opsawg/t5fkjKo0l1oVccs_yESUEb-A1aU/

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

I don't know. TBC(tho)

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Yes, the TLS WG being the obvious candidate.  AFAICS, apart from CfA, the TLS
WG has not been directly involved.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

At the time of writing, there has been no formal YANG Doctor review.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document defines three YANG modules:

* iana-tls-profile
* ietf-acl-tls
* ietf-mud-tls

All modules validate without warnings.

Re: NMDA.  I don't know.  TBC(tho)

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

There is no other formal language in the document apart from YANG.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.  Before or in parallel with the AD handover though, given the strong
security focus of the document, I suggest widening the reviewers' pool to
include the TLS WG and the Security Directorate.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

See 9.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard, which is the right track for this document. All related DT
attributes look good.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

All three authors have stated that they are not aware of any IPR. [HENK-IPR]
No IPR disclosures have been submitted directly on either the individual or the
IETF draft.

[HENK-IPR] https://mailarchive.ietf.org/arch/msg/opsawg/wOD9WOGFP4uAWCxHdwKtPOPTCMs/

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The document has three authors, all of which willing to be listed as such ;-)
There are no further contributors listed and none is expected.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Yes.  Running idnits on version -09 of the document reports 5 errors, 3
warnings and 9 comments [IDNITS-09].  2/5 errors look like false positives:

  ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
  ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)

because the document *really* needs to normatively reference version 1.2 of TLS
and DTLS.

[IDNITS-09] https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-tls-09.txt

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

Not that I can see.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

The only normative reference behind paywall is:

  [X690]    ITU-T, "Information technology - ASN.1 encoding Rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ISO/IEC 8825-1:2002, 2002.

Multiple other IETF standards depend on this, so I reckon there's no problem.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

The normative reference to TLS GREASE [RFC8701] makes sense in the context of
this document.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

draft-ietf-netconf-crypto-types [NCT] is the only I-D which is a normative
dependency.  At the time of writing, the document is past WGLC in the NETCONF
WG.

[NCT] https://datatracker.ietf.org/doc/draft-ietf-netconf-crypto-types/

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No, this document is new

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

It all looks good to me.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

* "ACL TLS Version Codes"
* "ACL DTLS Version Codes"
* "ACL (D)TLS parameters"

There are no explicit instructions for the DE,

The first two registries have self-evident semantics, so the lack of
instructions is not a problem.

The third one references two *very* large (D)TLS registries as the
authoritative source:

a) https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
b) https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

I think it should be made more clear what are the criteria for picking items
from the (D)TLS registries and placing them in the new "ACL (D)TLS parameters"
registry.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/