On 9/12/20 18:14, Benjamin Kaduk wrote:
Hi Russ,
Thanks for the comments.
On Wed, Dec 09, 2020 at 04:09:07PM -0500, Russ Housley wrote:
I have to comments.
1) I do not see this document as a BCP. Despite the inclusion of the boilerplate, there is not a single MUST in the document. I have no objection to an Informational RFC.
The assumption/expectation was that this would become part of BCP 72 along
with RFC 3552. Do you think it should be a standalone document, or can you
propose normative language that would make it more appropriate as a BCP?
The most straightforward way seems to be to introduce the three numbered
items from Section 5 as:
Protocol specifications that specify transient numeric identifiers
{MUST,SHOULD}:
I guess either "MUST" or "SHOULD" would do.
2) The document is really about transient identifiers. It does not only apply to ones that are numeric.
That's probably true. Numeric identifiers have some additional
properties/structure that have specific considerations, but the core
concerns do apply to non-numeric identifiers as well. (Proposed text would
be wonderful, of course.)
I'm not sure I can come up with transient identifiers that are not
numeric -- in the worst case, they might be represented e.g. via
"characters", but at the end of the day an implementation would be
processing them as numbers.
That aside, "transient numeric identifiers" is very focused on a topic
that's well-studied, etc. While it's generally nice to generalize
concepts as much as possible, as noted I cannot think of transient
identifiers that are not numeric -- and if there were, I'd be very
curious how draft-irtf-pearg-numeric-ids-generation would apply to them
since all the algorithms work on numbers.
Thoughts?
Thanks!
Regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@xxxxxxxxxxxxxxx
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
