[IPsec] Éric Vyncke's Discuss on draft-ietf-ipsecme-mib-iptfs-06: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-ipsecme-mib-iptfs-06: Discuss

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-ipsecme-mib-iptfs/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-mib-iptfs-06
CC @evyncke

Thank you for the work put into this document (even if I am balloting a
DISCUSS);

Please find below one blocking DISCUSS points (easy to address), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education).

Special thanks to Tero Kivinen for the shepherd's detailed write-up including
the WG consensus *but* it lacks the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

## DISCUSS

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics:

### Inconsistent intended status & use of experimental code point

This document is standard track, but the OID used in section 4.1 is
'experimental' and in section 4.2 `experimental 500` per
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml. Please request
IANA to assign an OID from the 1.3.6.1.2.1 tree.


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

## COMMENTS

### Section 1

```
   Note an IETF MIB model for IPsec was never standardized however the
   structures here could be adapted to existing MIB implementations.
```

Perhaps clarify "existing MIB implementations" ? I guess this is about
proprietary IPsec MIBs, but clarification will be welcome.

### Section 4.2

Should the construct with `<CODE BEGINS>` be used to allow for easy file
extraction ?

`mailto:ekinzie.labn.net` is probably wrong ;-)

`l2FixedRate`and `l3FixedRate` have 'counter64' type, RFC 2578 section 7.1.10
defines this type as monotically increasing. I understand that there are no
interger64 in RFC 2578 but why not using a different unit than 'bps' for those
two items ?

### Section 5

The IANA section should probably follow more closely RFC 8126, notably
specifying the right registry (e.g., "SMI Network Management MGMT Codes
Internet-standard MIB")

### Section 8.1

Unsure whether I-D.ietf-ipsecme-yang-iptfs (and perhaps I-D.ietf-ipsecme-iptfs)
is a normative reference (i.e., I can implement this I-D MIB without accessing
the YANG module).

## NITS

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