[I2nsf] John Scudder's No Objection on draft-ietf-i2nsf-consumer-facing-interface-dm-27: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-i2nsf-consumer-facing-interface-dm-27: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/



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

# John Scudder, RTG AD, comments
draft-ietf-i2nsf-consumer-facing-interface-dm-27 CC @jgscudder

Thanks for this work. Since my expertise with YANG is rudimentary at best, my
review was necessarily pretty limited. I did note a few things that seem
underspecified or ambiguous, although for all I know some of my comments would
be trivially answered by reference to the YANG module if I were better at
reading it. For that reason, I haven't chosen to make any of these DISCUSSes,
although otherwise I might have done so for the first comment.

## COMMENTS

### Section 3, Priority

I don't see any explanation of what the semantics of "priority" are, other than
the tautological definition given here (essentially, it says "the priority is
the priority"). Is "priority" explained in one of the normative references? I
did spend a little while looking and didn't find anything. If not, it seems as
though its semantics need to be explained here.

My guess is that rules are matched in priority order, with lower priorities
being matched first, and that matching terminates after the first match occurs.
I would also guess that order is undefined among rules with equal priorities.
But none of this is stated, and I think it needs to be.

There is also no example that uses 'priority' which might otherwise have helped
(although the definition should be able to stand without reference to examples
in any case).

### Section 3.1, what is a security event?

This is a little bit of a nit perhaps, but

   based on a security event (i.e., system event and system alarm).

Parsing the parenthetical closely, I would conclude that a security event is
defined as the concatenation of both a system event and a system alarm, in
other words, both must be present, which seems a little surprising. Maybe
that's what you mean, or maybe you mean "or" instead of "and"?

I might have been able to work this out for myself if an example were provided
that used 'event', but unfortunately, there isn't one.

### Section 5.2, multiple instances

I can't make out what this sentence means: "If multiple instances of content
are defined, it should match all contents somewhere in the session stream." One
problem is the disagreement in number -- "multiple instances of content" is
plural, and "it" is singular. I wouldn't pick on the grammar nit, except the
disagreement in number makes it hard for me to work out what the referent of
"it" is.

In general, I can't work out exactly what this paragraph is telling me to do.
Maybe an implementor working in this area wouldn't have problems, but on the
face of it, it seems like it should be made clearer.

### Section 6.1, time typedef

I was a little surprised you had to typedef time and day for yourself, I would
have imagined there would be some well-known base types for these you could
reference... but see my disclaimer. :-/

But since you did define your own time, I am curious if you think the
definition is clear enough. Your description says,

      "The time type represents an instance of time of zero-duration
       in the specified timezone that recurs every day.";

It would seem desirable to provide a reference for the semantics instead of
just relying on the reader to guess (through familiar usage, I suppose). Your
regex looks close to, but not quite the same as, RFC 3339 §5.6's 'full-time'.
The differences I can see offhand are that you don't permit lower-case 'z', 
you restrict the range on the time-offset to +/- 14:00 whereas 3339 looks to
permit the full +/- 23:59 range, and you make the TZ optional. The latter point
means your current description doesn't really cover the possible range of
inputs. I presume UTC is the default if TZ isn't specified, but you don't state
this, and it's not the only imaginable option, e.g. I suppose an implementor
might choose to use the local time zone if you leave it to their imagination.

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