[sidr] Stephen Farrell's No Objection on draft-ietf-sidr-origin-validation-signaling-10: (with COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-sidr-origin-validation-signaling-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- section 2, super-nit: when you say "the last octet ...
encodes" that is a teeny bit ambiguous, as it could just
about be read to mean that the last octet is a bit mask,
leading someone's code to not correctly handle future
values >2. So it might be good to be that little bit more
explicit that the other 6 bits of that octet are also
important, even if they're not defined now. IOW, if a
device sees a value 4 in there then it MUST NOT treat that
as valid by only seeing zeroes in the two low order bits.
(And btw, I assume network byte order is generically
understood here too, not sure if that also needs to be
stated, probably not, as that ought be generic for encoding
integers within extensions I guess.)

- section 2: Is "By default, ... SHOULD drop..." correct?
I think what you mean is "By default ... MUST drop" as the
case for not dropping is not the default. Or, you could say
"SHOULD drop except when... " and not have to mention any
default. (Note: I'm only questioning the wording here, not
the semantics, which seems fine.)

- section 6: I didn't read all the references, but is there
anything to be said about possible differences in the
duration for which one is vulnerable to not yet seeing a
revocation for a node that sees this extension, vs a node
that does origin validation itself? If a node having seen
this extension were to remember the origin for a lot longer
than one that does validation itself, then that might be
worth noting here, but I don't know how the relative
timings might pan out, so not sure. (And apologies if this
is covered in the references I didn't check out;-)