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

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

I support Lars and Alvaro’s DISCUSS positions.

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/

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.

[Thanks for addressing my 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).

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

Thanks for writing this helpful document.  I have no substantive comments.  One minor nit that I spotted was "of of".