Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates
draft-ietf-lamps-rfc3709bis-10

[Ballot comment]
# GEN AD review of draft-ietf-lamps-rfc3709bis-08

CC @larseggert

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

## Comments

### Section 4.1, paragraph 8
```
    Note that the HTTPS scheme (https://...) requires the validation of
    other certificates to establish a secure connection.  For this
    reason, the HTTP scheme (http://...) may be easier for a client to
    handle.  Also, the hash of the logotype data provides data integrity.
```
It may be easier, but it's also insecure. I find it odd that we don't
recommend HTTPS over HTTP here?

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term `his`; alternatives might be `they`, `them`, `their`
* Term `traditional`; alternatives might be `classic`, `classical`, `common`,
  `conventional`, `customary`, `fixed`, `habitual`, `historic`,
  `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
  `time-honored`, `universal`, `widely used`, `widespread`

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

### Typos

#### Section 3, paragraph 6
```
-    applications where the audio text is placed as the "alt" atttribute
-                                                                -
```

#### Section 3, paragraph 6
```
-    value of an html image (img) element and the language value obtained
-                ^^^^
+    value of an HTML image (img) element and the language value obtained
+                ^^^^
```

#### Section 7, paragraph 16
```
-    When a bitmapped image is used, the PNG [ISO15948] format SHOULD be
-                ---
```

### URLs

These URLs in the document can probably be converted to HTTPS:

* http://www.w3.org/TR/2008/PR-SVGTiny12-20081117

### Grammar/style

#### Section 1, paragraph 3
```
tificate may be examined from several different perspectives. Systematic pro
                              ^^^^^^^^^^^^^^^^^
```
Consider using "several".

#### Section 1, paragraph 9
```
a user identifies the owner of the web site. * Peer e-mail exchange in busin
                                  ^^^^^^^^
```
Nowadays, it's more common to write this as one word.

#### Section 1.1, paragraph 4
```
ate is too technical and is not user friendly. It contains no graphic symbol
                                ^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 1.3, paragraph 3
```
the end, the human will decide whether or not to accept an executable email a
                              ^^^^^^^^^^^^^^
```
Consider shortening this phrase to just "whether". It is correct though if you
mean "regardless of whether".

#### Section 6, paragraph 7
```
references to information stored outside of the SVG image of type B, C, or D
                                ^^^^^^^^^^
```
This phrase is redundant. Consider using "outside".

#### Section 7, paragraph 2
```
FC1952] as specified in [SVGR]. When a uncompressed SVG image is fetched wit
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 7, paragraph 3
```
characters as specified above. When a SVG image is embedded in the certific
                                    ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

## 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

Next steps out of the telechat: Not enough ADs balloted for this document to pass.  A few have volunteered to address this early next week.  In the mean time, please review the COMMENTs.

[Ballot comment]
Original DISCUSS:
------------------
Don't Panic! As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion...

I'm assuming that I'm missing something really obvious here, but this *feels* like a bad idea to me...

The document says: "The use of logotypes will, in many cases, affect the users decision to trust and use a certificate." Yes, but that seems like a bad outcome...

Random things on the Internet tell me that Microsoft has a well recognized logo. Seems plausible, let's use that as an example. When a user is trying to figure out if a certificate actually belongs to Microsoft they are likely to go "Oh, yes, it's a square composed of other colored squares, this must really be Microsoft", even if the CN is for www.evil-attackers-r-us.net. Even without an attacker intentionally creating visually confusing logos, many are similar - for example, https://icn.bg/ looks really similar to Microsoft's logo (and many things look very similar to the Pepsi logo - https://yourmileagemayvary.net/2021/05/23/look-up-in-the-sky-its-a-coke-plane-its-a-pepsi-plane-its/ ).

Here is an image with two logos: https://cdn.mos.cms.futurecdn.net/hD95PaJgx5ZZVCFduTWhtg-1200-80.jpg.webp One of these is for airbnb, and one is for a Japanese drive-in. Keeping in mind that, as a user, the logotype is likely to affect your decision to trust and use the cert, when entering your credit-card info to book your next vacation rental, do you know which of these you should expect? If you get the drive-in one, would you really recognize that?

The document uses VISA and MasterCard as examples, but, without looking in your wallet to actually confirm what their logos look like, are you *sure* that you would be able to unambiguously identify them if placed next to logos made by an attacker?

Ok, so now that I've had my soapbox rant: This document updates RFC 3709 and RFC 6170, which been around since 2004 and 2011 respectively. Apparently the sky hasn't actually fallen yet, and so I must be missing something. I did spend quite a while trying to find examples using RFC3709/RFC6170, so I could figure out what I'm missing, but failed. I *did* find a few CA certs with this, but they just had links to http://logo.verisign.com/vslogo.gif (which doesn't resolve). The only "live" cert was for https://www.dtihost.cz/, but it's not valid.

Again, I'm probably missing something obvious, and so clue-bat appreciated...

[Ballot comment]
# Sec AD review of draft-ietf-lamps-rfc3709bis-08

CC @paulwouters
   
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.

This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows
automated tools to process items (eg to produce github issers)

Like Warren, I had an "OMG" moment, but then also realize it is a bis document :-)

Going through the changes, I appreciate the attention to privacy and security that were added.
I just have a few comments.

## Comments

### svg+xml vs svg+xml+gzip

I find it a little odd that support for svg+xml is SHOULD and svg+xml+gz is MUST, as clearly if you support the MUST you have all the parts to support the SHOULD. Also, it makes me a little nervous to have to have gzip support in this security function, as we have seen lot sof dangerous vulnerabilities in opensource decompression library functions.

### Why not register image/svg+xml-compressed media type
```
        NOTE: The image/svg+xml-compressed media type is widely implemented,
                          but it has not yet been registered with IANA.
```

Why does this RFC not register it?

### usage or install of cert?
```
      Further, when logotype data is not cached, activity on the network
        would reveal certificate usage frequency
```

Is the usage of logotypes to be expected every time the certificate is used? Or only when the certificate is "human checked" for installation?
I would think when installing a VPN cert, that I would see the logotype when installing the cert, but not every time I bring up my VPN. So
I think the "certificate usage frequency" is not necessarily leaked as this sentence claims.

### DoT
```
      In addition, the use of an encrypted DNS mechanism, such as DoT
        [RFC7858] or DoH [RFC9230], hides the name resolution traffic
        associated fetching remote logotype objects.
```
It hides it only from third party observers. A malicious (or nosy) CA
can still see all the DNS traffic as they will point it to their authoritative
DNS servers. So encryption to these servers doesn't hamper them seeing things.
So I think this claim needs to be updated to state "third party people cannot see DNS
when using DoT".

### SHA1 in example use
Seems a bit lazy to keep the RFC 3709 certificate unchanged using SHA1 when the document
drops SHA-1 as the mandatory-to-implement hash algorithm :P

[Ballot discuss]
Don't Panic! As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion...

I'm assuming that I'm missing something really obvious here, but this *feels* like a bad idea to me...

The document says: "The use of logotypes will, in many cases, affect the users decision to trust and use a certificate." Yes, but that seems like a bad outcome...

Random things on the Internet tell me that Microsoft has a well recognized logo. Seems plausible, let's use that as an example. When a user is trying to figure out if a certificate actually belongs to Microsoft they are likely to go "Oh, yes, it's a square composed of other colored squares, this must really be Microsoft", even if the CN is for www.evil-attackers-r-us.net. Even without an attacker intentionally creating visually confusing logos, many are similar - for example, https://icn.bg/ looks really similar to Microsoft's logo (and many things look very similar to the Pepsi logo - https://yourmileagemayvary.net/2021/05/23/look-up-in-the-sky-its-a-coke-plane-its-a-pepsi-plane-its/ ).

Here is an image with two logos: https://cdn.mos.cms.futurecdn.net/hD95PaJgx5ZZVCFduTWhtg-1200-80.jpg.webp One of these is for airbnb, and one is for a Japanese drive-in. Keeping in mind that, as a user, the logotype is likely to affect your decision to trust and use the cert, when entering your credit-card info to book your next vacation rental, do you know which of these you should expect? If you get the drive-in one, would you really recognize that?

The document uses VISA and MasterCard as examples, but, without looking in your wallet to actually confirm what their logos look like, are you *sure* that you would be able to unambiguously identify them if placed next to logos made by an attacker?

Ok, so now that I've had my soapbox rant: This document updates RFC 3709 and RFC 6170, which been around since 2004 and 2011 respectively. Apparently the sky hasn't actually fallen yet, and so I must be missing something. I did spend quite a while trying to find examples using RFC3709/RFC6170, so I could figure out what I'm missing, but failed. I *did* find a few CA certs with this, but they just had links to http://logo.verisign.com/vslogo.gif (which doesn't resolve). The only "live" cert was for https://www.dtihost.cz/, but it's not valid.

Again, I'm probably missing something obvious, and so clue-bat appreciated...

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-lamps-rfc3709bis-07
CC @evyncke

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 Hollebeek for the shepherd's write-up including the WG consensus *and* the justification of the intended status.

Thanks also to Don Eastlake for his internet directorate review that I requested, see:
https://datatracker.ietf.org/doc/review-ietf-lamps-rfc3709bis-07-intdir-telechat-eastlake-2022-11-23/
I have noted that Russ, as author, has already replied and addressed the Don's comments.

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Section 1

Just a minor regret as several points about human beings are written but no reference is provided. As a human being, I would tend to agree strongly with the authors of course but a reference, if any, would have been nice ;-)

### Section 1.1

Suggest to expand the B2B and B2C acronyms as they are not part of https://www.rfc-editor.org/materials/abbrev.expansion.txt

### Section 4.1

The I-D seems to allow for plain HTTP transport, which is a little surprising. Of course, there could be a chicken and egg issue and anyway the hash should provide authenticity of the logo. At least, FTP was removed ;-)

### Strength of the hash

Probably a naive question but should the crypto strength of the hash be linked to the strength of the public key / signature of the certificate ? I.e., if a human being is about to trust a cert based on a logo, I would naively assume that the logo is more protected than the cert itself.

### Section 7 image/svg+xml-compressed

The note about "image/svg+xml-compressed" is interesting: is there work somewhere to register to IANA ? If and when it happens, then will it be allowed to be used in this specification ?

## NITS

### Section 3

Isn't "one-way hash" a pleonasm ? I.e., should "hash" be enough ?

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

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

[Ballot comment]
# Internet AD comments for draft-ietf-lamps-rfc3709bis-07
CC @ekline

## Nits

### S1.2

* "from his wallet" -> "from their wallet", perhaps

### S6

* "replying party software" -> "relying party software"

[Ballot comment]
Hi,

Thanks for this document.  This is quite a long way outside my area of expertise and given that this is a bis document, I only looked over the diff relative to RFC 3709.

On a general note, I was wondering how widely deployed logotypes are?  I tried various web searches for "logotype" with and without "X.509/certificates" and didn't seem to find any obvious matches.  Perhaps a different commercial name is used for this?

I also have one specific comment on the text:

All direct addressing URIs SHOULD
  use the HTTPS scheme (https://...) or the HTTP scheme (http://...) or
  the DATA scheme (data://...) [RFC3986].  However, the "data" URI
  scheme MUST NOT be used with the indirect addressing.  Clients MUST
  support retrieval of referenced LogoTypeData with the HTTP [RFC9110]
  and the HTTP with TLS [RFC8446], or subsequent versions of these
  protocols.  Client applications SHOULD also support the "data" URI
  scheme [RFC2397] for direct addressing with embedded logotype data
  within the extension.

I find this text (specifically the SHOULD in the first sentence, and MUST/SHOULD in the subsequent sentences to be somewhat ambiguous.  E.g., it is unclear to me whether using an alternative scheme from the three listed is allowed, and if so under what circumstances such a scheme can be used?  If no other schemes can be used then perhaps the first sentence should just be: "All direct addressing URIs use the HTTPS scheme (https://...) or the HTTP scheme (http://...) or the DATA scheme (data://...) [RFC3986]."

Regards,
Rob

// I would also like to thank Sheng for the OPSDIR review.

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

The IANA Functions Operator has completed its review of draft-ietf-lamps-rfc3709bis-06. If any part of this review is inaccurate, please let us know.

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

We understand that, upon approval of this document, there is a single action which we must complete.

In the SMI Security for PKIX Module Identifier registry on the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry page located at:

https://www.iana.org/assignments/smi-numbers/

the reference for the existing registration will be changed to:

Decimal: 22
Description: id-mod-logotype
Reference: [ RFC-to-be ]

NOTE: The IANA Considerations section only mentions the above registration, but there are four references to RFC 3709 and two references to RFC 6170 in the IANA registries:

https://www.iana.org/assignments/smi-numbers

IANA Question --> Should the references to RFC 3709 and RFC 6170 be updated to point to this document? If so, the IANA Considerations section needs to be updated to state that this document should be listed as the new reference for [all/all but one/only one] of the registrations that refer to RFC 3709 or RFC 6170, whether or not the affected registrations are also listed in the IANA Considerations section.

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,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-rfc3709bis@ietf.org, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org, tim.hollebeek@digicert.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Internet X.509 Public Key Infrastructure: Logotypes in X.509 Certificates) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Internet
X.509 Public Key Infrastructure: Logotypes in X.509
  Certificates'
  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 2022-10-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies a certificate extension for including
  logotypes in public key certificates and attribute certificates.
  This document obsoletes RFC 3709 and RFC 6170.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc3709bis/



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

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 document reached broad agreement.

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

No.

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 one has threatened an appeal or expressed extreme discontent.

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)?

This is an update and merge of two older documents, RFC 3709 and RFC 6170.
Historical implementations exist for both RFCs, and implementations are rapidly
becoming more common as these RFCs are fundamental to Verified Mark Certificates
which are rapidly being rolled out by Google, Apple, and others.

These experiences have shown that the two documents are in need of modernization
(e.g. SHA-1 is mandatory to implement in RFC 3709), so this merge/update is very
timely and useful for the industry.

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.

The document is largely (and perhaps almost exclusively) of interest to
participants in the LAMPS working group.

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.

The document shepherd does not believe any such expert reviews are required.

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 does not contain a YANG module.

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.

Review by a member of the working group found and fixed an error in the generation
of the examples which was fixed by the author; the author's examples and the
version generated by an independent reviewer now agree.

The document shepherd also independently reviewed and compiled the ASN.1 modules
included in the document.

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.  The document fixes a number of important issues with the two parent
documents, and the changes are helpfully summarized and documented in Appendix C.

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?

The document shepherd reviewed the list of common issues for the Security area,
and did not find any of the identified issues in the document.

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 matches the status of the document it replaces (RFC 3709).
The datatracker attributes appear to be correct.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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.

The current list of authors includes all the authors of the previous RFCs.

The document shepherd contacted the authors by private email and asked:

(1) You are still willing to be an author on the draft,
(2) You do not hold any IP related to the draft, and
(3) You are unaware of any other IP related to the draft.

All the authors responded affirmatively to all three statements

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.

Yes, see question #1 in response 12.

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

There are two remaining nits:

== Outdated reference: draft-ietf-httpbis-semantics has been published as
    RFC 9110
- will be fixed during the RFC publication process

** Downref: Normative reference to an Informational RFC: RFC 1952
- RFC 1952 is already in the DOWNREF registry

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

See 14 ... the remainder were manually reviewed and looked correct.

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

None.

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.

There is one normative downward reference, but as noted above, it is already in
the DOWNREF registry.

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?

No.

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.

The document obsoletes RFC 3709 and 6170.  This is mentioned on the title page,
in the abstract, and in the introduction.

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]).

The IANA Considerations have been reviewed by the document shepherd and appear
to be correct.  In addition, IANA early review has already happened
([IANA #1234128]), and the author responded that all references to 3709 and
6170 should be updated to point to this document once this document is
published as an RFC.

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.

The document does not propose any new IANA registries.

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 document reached broad agreement.

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

No.

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 one has threatened an appeal or expressed extreme discontent.

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)?

This is an update and merge of two older documents, RFC 3709 and RFC 6170.
Historical implementations exist for both RFCs, and implementations are rapidly
becoming more common as these RFCs are fundamental to Verified Mark Certificates
which are rapidly being rolled out by Google, Apple, and others.

These experiences have shown that the two documents are in need of modernization
(e.g. SHA-1 is mandatory to implement in RFC 3709), so this merge/update is very
timely and useful for the industry.

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.

The document is largely (and perhaps almost exclusively) of interest to
participants in the LAMPS working group.

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.

The document shepherd does not believe any such expert reviews are required.

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 does not contain a YANG module.

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.

Review by a member of the working group found and fixed an error in the generation
of the examples which was fixed by the author; the author's examples and the
version generated by an independent reviewer now agree.

The document shepherd also independently reviewed and compiled the ASN.1 modules
included in the document.

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.  The document fixes a number of important issues with the two parent
documents, and the changes are helpfully summarized and documented in Appendix C.

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?

The document shepherd reviewed the list of common issues for the Security area,
and did not find any of the identified issues in the document.

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 matches the status of the document it replaces (RFC 3709).
The datatracker attributes appear to be correct.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][8]? 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.

The current list of authors includes all the authors of the previous RFCs.

The document shepherd contacted the authors by private email and asked:

(1) You are still willing to be an author on the draft,
(2) You do not hold any IP related to the draft, and
(3) You are unaware of any other IP related to the draft.

All the authors responded affirmatively to all three statements

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.

Yes, see question #1 in response 12.

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

There are two remaining nits:

== Outdated reference: draft-ietf-httpbis-semantics has been published as
    RFC 9110
- will be fixed during the RFC publication process

** Downref: Normative reference to an Informational RFC: RFC 1952
- RFC 1952 is already in the DOWNREF registry

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

See 14 ... the remainder were manually reviewed and looked correct.

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

None.

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.

There is one normative downward reference, but as noted above, it is already in
the DOWNREF registry.

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?

No.

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.

The document obsoletes RFC 3709 and 6170.  This is mentioned on the title page,
in the abstract, and in the introduction.

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]).

The IANA Considerations have been reviewed by the document shepherd and appear
to be correct.  In addition, IANA early review has already happened
([IANA #1234128]), and the author responded that all references to 3709 and
6170 should be updated to point to this document once this document is
published as an RFC.

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.

The document does not propose any new IANA registries.