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

[Don Fedyk <[e-mail]>]

Hi Eric 

Thanks for you Review. We have posted an updated draft 07 to address your comments. 
Note I Revalidated the MIB with the changes, but I realized I didn’t update the tree in the draft. So, I have one pending change, but I will wait and see if we satisfied your points.    

See [Don] Below. 

Thanks
Don 

-----Original Message-----
From: É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.

[Don] This was a holdover from the initial draft.  
We have updated to be consistent with the IANA requests and your comment. 

BTW Thank you for helping us clarify where this should be placed. 

----------------------------------------------------------------------
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.
```
[Don] we updated to:
adapted to existing proprietary MIB
implementations where SNMP is used to manage networks.

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 ?

[Don] OK Roman had requested this comment and I looked for MIB examples and found none. But as I updated the YANG, I found the sourcecode tag and used that for a mib and nothing seem to complain.  We may be the only MIB that ever used this though.

`mailto:ekinzie.labn.net` is probably wrong ;-)
[Don] Fixed. 

`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 ?

[Don] We updated this CounterBasedGauge64 - Does this satisfy your point? SNMP has a richer set of types.   

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

[Don] Thanks we updated this an noted. 

### 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).
[Don] We moved the YANG to informative. We left the IP-TFS core draft as normative since it is the source for the attributes.  

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