Security Considerations for Transient Numeric Identifiers Employed in Network Protocols
draft-gont-numeric-ids-sec-considerations-11

[Ballot comment]
# GEN AD review of draft-gont-numeric-ids-sec-considerations-10

CC @larseggert

Thanks to Gyan S. Mishra for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/sQeXJs6ZU4ga80XkFYFCGKo_u0w).

## 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 5, paragraph 6
```
-      transientnumeric identifiers.
+      transient numeric identifiers.
+                +
```

### Outdated references

Reference `[RFC6528]` to `RFC6528`, which was obsoleted by `RFC9293` (this may
be on purpose).

Document references `draft-gont-predictable-numeric-ids-03`, but `-11` is the
latest available revision.

Reference `[RFC0793]` to `RFC793`, which was obsoleted by `RFC9293` (this may
be on purpose).

Reference `[RFC2460]` to `RFC2460`, which was obsoleted by `RFC8200` (this may
be on purpose).

### URLs

These URLs in the document did not return content:

* http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.4542&rep=rep1&type=pdf

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

* http://seclists.org/bugtraq/1998/Dec/48

### Grammar/style

#### Section 1, paragraph 11
```
ransport protocol endpoint, session, etc) from all other objects of the same
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 2, paragraph 3
```
not operate in the prescribed manner but normal operation can be resumed aut
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 3, paragraph 5
```
ion (whether the core specification or or an update to it), but an implementa
                                    ^^^^^
```
Possible typo: you repeated a word.

#### Section 4, paragraph 2
```
t needed, activity correlation is made made possible. For example, employing
                                  ^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 4, paragraph 8
```
ols from different layers, the goal of of isolating the properties of a layer
                                    ^^^^^
```
Possible typo: you repeated a word.

## Notes

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

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

[Ballot comment]
I support Alvaro Retana’s DISCUSS position.

I also endorse Alvaro’s COMMENT about reviewing the IETF LC thread around consensus to publish in the current status/form.

I support Lars Eggert’s DISCUSS position.  The same feedback was also noted in the IETF LC (https://mailarchive.ietf.org/arch/msg/last-call/m0XLciccHlL7xfQQssYHgA9Z5ZY/)

** Section 1.  Editorial.
  the poor selection of identifiers in such protocols,
  usually as a result of insufficient or misleading specifications.

“Misleading” specification appears to be a new type of flaw and different from those characterized in Section 4.

** Section 1.  Editorial.
  Recent history indicates that when new protocols are standardized or
  new protocol implementations are produced, the security and privacy
  properties of the associated identifiers tend to be overlooked and
  inappropriate algorithms to generate such identifiers are either
  suggested in the specification or selected by implementers.  As a
  result, advice in this area is warranted.

What is that recent history where this occurred?  I’m reacting to the “recent” part of the history and wonder if this will age will.

** Section 3.  Typo. s/or or/or/

** Section 3.
  For example, some popular operating
  systems (notably Microsoft Windows

Can the text be more specific on the Window version number or cite this by reference so it ages better?  Is there a comprehensive OS list that can be referenced instead?

** Section 4. Typo. /made made/made/

[Ballot comment]
Thanks for working on this specification.

I reacted a bit on the fact that a "NOTE" has a normative requirement. This note seems like valid and strong enough that it can be part of the regular section text, still it is a note. I don't really know how to interpret an enforce a normative requirement from a note. I am not balloting discuss as I think Alvaro has kind of already picked it up in his ballot.

[Ballot discuss]
I am balloting DISCUSS because I believe that the expected actions resulting from this document are not specific enough:

(1) §7 reads:

  This document formally updates [RFC3552] such that a vulnerability
  assessment of transient numeric identifiers is performed when writing
  the "Security Considerations" section of future RFCs.

Is the assessment a requirement or a recommendation (when defining transient numeric identifiers)? 

The Abstract says that "this document updates RFC 3552, requiring future RFCs to contain a vulnerability assessment of their transient numeric identifiers."  The update itself doesn't result in a requirement.

Please be explicit (SHOULD/MUST ?) in §7.


(2) The requirements of the assessment itself (§5) can also be more explicit:

[Line numbers from idnits.]

289 5.  Vulnerability Assessment Requirements for Transient Numeric
290     Identifiers

292   Protocol specifications that employ transient numeric identifiers
293   SHOULD:

(2a) The points to be covered in the assessment are only recommended and not required.  When is it ok to not include any, or all, of the points mentioned?  Why is this not a requirement?  Are some parts optional?


295   1.  Clearly specify the interoperability requirements for the
296       aforementioned transient numeric identifiers (e.g., required
297       properties such as uniqueness, along with the failure severity if
298       such properties are not met).

(2b) "Clearly specify the interoperability requirements..."  Clarity can be subjective.  s/.../Specify the interoperability requirements...


300   2.  Provide a vulnerability assessment of the aforementioned
301       identifiers.

303           Note: Section 8 and Section 9 of
304           [I-D.irtf-pearg-numeric-ids-generation] provide a general
305           vulnerability assessment of transient numeric identifiers,
306           along with a vulnerability assessment of common algorithms for
307           generating transient numeric identifiers.

(2c) Going back to (1), is this the only part that is intended to be performed as a result of the update to rfc3552?

(2d) What should be included in the vulnerability assessment?  Given that this bullet talks about identifiers, are the considerations from §8/I-D.irtf-pearg-numeric-ids-generation (correlation, leakage, fingerprinting, etc.) expected to be included?

(2e) The reference to §9 seems not to be needed at this point, or are you also expecting an assessment of the algorithm?


309   3.  Recommend an algorithm for generating the aforementioned
310       transient numeric identifiers that mitigates the vulnerabilities
311       identified in the previous step, such as those discussed in
312       [I-D.irtf-pearg-numeric-ids-generation].

(2f) Is the expectation that this recommendation will result in a normative requirement, recommendation, or just an option?


314   Note:
315       As discussed in Section 1, use of cryptographic techniques for
316       confidentiality and authentication might not eliminate all the
317       issues associated with predictable transient numeric identifiers.
318       Therefore, the advice from this section SHOULD still be applied
319       for cases where cryptographic techniques are employed for
320       confidentiality or authentication of the associated
321       transientnumeric identifiers.

(2g) "SHOULD still be applied"

Given that §1 doesn't exclude protocols using cryptographic techniques for confidentiality and authentication from the considerations in this document, the "SHOULD" above reinforces that and indicates a fact, vs a normative recommendation.  s/SHOULD/should


[nit] s/transientnumeric/transient numeric

[Ballot comment]
(1) As others in the Last Call thread for -06 [1], I think this draft would be more appropriate as an Informational document.  Even though I didn't find further discussion on this topic in the archive, I trust the Responsible AD and assume that any concerns have been addressed.  This (non-blocking) comment is intended to record my opinion and not to rehash the discussion.

Moving forward...  Is the intent for this document to become part of BCP72?  If so, that should be indicated somewhere -- I suggest using the RFC Editor Note to make sure the expectation is clear.


(2) The Security Considerations section doesn't say anything about the, well, security considerations raised in this document.  Previous versions included this: "This entire document is about the security and privacy implications of transient numeric identifiers..."  I'm not sure why it was removed, but it would be nice to bring that text back.


[1] https://mailarchive.ietf.org/arch/msg/last-call/SCr-7ET1S74cehGd4z-81DBe1WQ/

[Ballot discuss]
# GEN AD review of draft-gont-numeric-ids-sec-considerations-10

CC @larseggert

Thanks to Gyan S. Mishra for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/sQeXJs6ZU4ga80XkFYFCGKo_u0w).

## Discuss

### Paragraph 0
```
  Network Working Group                                            F. Gont
  Internet-Draft                                              SI6 Networks
  Updates: 3552 (if approved)                                      I. Arce
```
RFC3552 is a BCP on the IAB stream that was approved by the IESG. Can
it be updated by a document on the IETF stream without the update
also being explicitly approved by the IAB?

### "Abstract", paragraph 1
```
    Poor selection of transient numerical identifiers in protocols such
    as the TCP/IP suite has historically led to a number of attacks on
    implementations, ranging from Denial of Service (DoS) to data
    injection and information leakage that can be exploited by pervasive
    monitoring.  To prevent such flaws in future protocols and
    implementations, this document updates RFC 3552, requiring future
    RFCs to contain a vulnerability assessment of their transient numeric
    identifiers.
```
Does this document intend to make requirements for all numeric
identifiers used by a protocol, or only those that are observable in
plaintext? All motivational text is AFAICT based on flaws that arose
because such identifiers were transmitted in plaintext, so does the
document intend to limit its guidance to those (and not to other
identifiers that are for example always transmitted in encrypted
form)? If the document does intend to give guidance on identifiers
that are transmitted in encrypted form, it would be good to give some
examples why that is necessary. In any event, please be more precise
about the applicability of the guidance given here.

[Ballot comment]
## 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 5, paragraph 6
```
-      transientnumeric identifiers.
+      transient numeric identifiers.
+                +
```

### Outdated references

Reference `[RFC6528]` to `RFC6528`, which was obsoleted by `RFC9293` (this may
be on purpose).

Document references `draft-gont-predictable-numeric-ids-03`, but `-11` is the
latest available revision.

Reference `[RFC0793]` to `RFC793`, which was obsoleted by `RFC9293` (this may
be on purpose).

Reference `[RFC2460]` to `RFC2460`, which was obsoleted by `RFC8200` (this may
be on purpose).

### URLs

These URLs in the document did not return content:

* http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.91.4542&rep=rep1&type=pdf

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

* http://seclists.org/bugtraq/1998/Dec/48

### Grammar/style

#### Section 1, paragraph 11
```
ransport protocol endpoint, session, etc) from all other objects of the same
                                    ^^^
```
A period is needed after the abbreviation "etc.".

#### Section 2, paragraph 3
```
not operate in the prescribed manner but normal operation can be resumed aut
                                    ^^^^
```
Use a comma before "but" if it connects two independent clauses (unless they
are closely connected and short).

#### Section 3, paragraph 5
```
ion (whether the core specification or or an update to it), but an implementa
                                    ^^^^^
```
Possible typo: you repeated a word.

#### Section 4, paragraph 2
```
t needed, activity correlation is made made possible. For example, employing
                                  ^^^^^^^^^
```
Possible typo: you repeated a word.

#### Section 4, paragraph 8
```
ols from different layers, the goal of of isolating the properties of a layer
                                    ^^^^^
```
Possible typo: you repeated a word.

## Notes

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

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

[Ballot comment]
# Internet AD comments for draft-gont-numeric-ids-sec-considerations-10
CC @ekline

## Comments

### S4

* I don't quite see how implementations using flawed PRNGs is relevant
  here.  Such a failing is not really a protocol specification issue.

  (And we already have RFCs 4086, 8937, and others...)

## Nits

### S1

* "such properties not met" -> "such properties are not met"

### S3

* "or or an update to it" -> "or an update to it"

### S4

* "made made" -> "made"

* "of of" -> "of"

### S5

* "transientnumeric" -> "transient numeric"

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

The IANA Functions Operator has reviewed draft-gont-numeric-ids-sec-considerations-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Specialist

# Document Shepherd Write-Up for Individual Documents


## Document History

1. Was the document considered in any WG, and if so, why was it not adopted as a
  work item there?

It was discussed on multiple IETF/IRTF lists. It went to secdispatch and the advise there was to split the original document into three pieces (https://mailarchive.ietf.org/arch/msg/pearg/AXaMGXGeXDZ05rxNfTWsteuR530/)

Two documents were adopted at PEARG. The shepherding AD is not aware why the security document was not accepted at PEARG. The work is clearly too small to spin up a WG for, so AD sponsorshop was selected (sort of before the current AD, but confirmed by the current AD (Paul Wouters)

2. Was there controversy about particular points that caused the WG to not adopt
  the document?

  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.

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

  N/A

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

  It has seen reviews in its earlier one document version. While everything benefits
  from always more reviews, this document is ready and has been stalled very long.
  Everyone who wanted surely has had a chance (and will get another chance at IETF LC)


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.

  N/A

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

  N/A

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.

  N/A

## 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 - note the shepherd is the responsible AD.

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?

    Not needed.

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?

    BCP. This is the correct type, as the document is giving BCP advise on generating
    numeric IDs in applications with respect to security.

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.

    No IPR known to authors:
    https://mailarchive.ietf.org/arch/msg/last-call/G0pn-dke3xTxLKX3dA-cT8OZPYA/
    https://mailarchive.ietf.org/arch/msg/last-call/TaPE0ekyskXuPHy3WT8LivayNH0/


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 above two links.

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

    [NITS have been relayed to author, should be resolved in a new -08]

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

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

    N/A

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.

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?

    N/A

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.

    Yes. It updates 3552. It is not discussed in the introduction, but in the more
    appropriate Security Considerations section (which is what 3552 is about)

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 section exists and lists no actions required for IANA.

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.

    N/A

[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/

The following Last Call announcement was sent out (ends 2023-01-09):

From: The IESG
To: IETF-Announce
CC: draft-gont-numeric-ids-sec-considerations@ietf.org, paul.wouters@aiven.io
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice


The IESG has received a request from an individual submitter to consider the
following document: - 'Security Considerations for Transient Numeric
Identifiers Employed in
  Network Protocols'
  as Best Current Practice

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


  Poor selection of transient numerical identifiers in protocols such
  as the TCP/IP suite has historically led to a number of attacks on
  implementations, ranging from Denial of Service (DoS) to data
  injection and information leakage that can be exploited by pervasive
  monitoring.  To prevent such flaws in future protocols and
  implementations, this document updates RFC 3552, requiring future
  RFCs to contain a vulnerability assessment of their transient numeric
  identifiers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-gont-numeric-ids-sec-considerations/



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

AD note 1: This draft was split off from an earlier draft. The related other work is:

https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-generation/
https://datatracker.ietf.org/doc/draft-irtf-pearg-numeric-ids-history/

AD note 2: Could do authors please confirm their willingness to be authors on the document,
          as well as notify the list with any IPR claims or confirmation of no known IPR claims.

# Document Shepherd Write-Up for Individual Documents


## Document History

1. Was the document considered in any WG, and if so, why was it not adopted as a
  work item there?

It was discussed on multiple IETF/IRTF lists. It went to secdispatch and the advise there was to split the original document into three pieces (https://mailarchive.ietf.org/arch/msg/pearg/AXaMGXGeXDZ05rxNfTWsteuR530/)

Two documents were adopted at PEARG. The shepherding AD is not aware why the security document was not accepted at PEARG. The work is clearly too small to spin up a WG for, so AD sponsorshop was selected (sort of before the current AD, but confirmed by the current AD (Paul Wouters)

2. Was there controversy about particular points that caused the WG to not adopt
  the document?

  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.

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

  N/A

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

  It has seen reviews in its earlier one document version. While everything benefits
  from always more reviews, this document is ready and has been stalled very long.
  Everyone who wanted surely has had a chance (and will get another chance at IETF LC)


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.

  N/A

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

  N/A

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.

  N/A

## 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 - note the shepherd is the responsible AD.

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?

    Not needed.

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?

    BCP. This is the correct type, as the document is giving BCP advise on generating
    numeric IDs in applications with respect to security.

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.

    [TBD]

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.

    [TBD]

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

    [NITS have been relayed to author, should be resolved in a new -08]

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

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

    N/A

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.

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?

    N/A

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.

    Yes. It updates 3552. It is not discussed in the introduction, but in the more
    appropriate Security Considerations section (which is what 3552 is about)

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 section exists and lists no actions required for IANA.

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.

    N/A

[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/

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

The IANA Functions Operator has reviewed draft-gont-numeric-ids-sec-considerations-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-01-04):

From: The IESG
To: IETF-Announce
CC: draft-gont-numeric-ids-sec-considerations@ietf.org, kaduk@mit.edu
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Security Considerations for Transient Numeric Identifiers Employed in Network Protocols) to Best Current Practice


The IESG has received a request from an individual submitter to consider the
following document: - 'Security Considerations for Transient Numeric
Identifiers Employed in
  Network Protocols'
  as Best Current Practice

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


  Poor selection of transient numerical identifiers in protocols such
  as the TCP/IP suite has historically led to a number of attacks on
  implementations, ranging from Denial of Service (DoS) to data
  injection and information leakage that can be exploited by pervasive
  monitoring.  To prevent such flaws in future protocols and
  implementations, this document updates RFC 3552, requiring future
  RFCs to contain analysis of the security and privacy properties of
  any transient numeric identifiers specified by the protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-gont-numeric-ids-sec-considerations/



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