Don
You were faster than the light ;-)
Indeed, the changes are ok for me and, more important, I do believe that they
have improved the document. I also noticed that the tree is not updated, but I
will trust you (and your AD) on this point. I will clear my DISCUSS shortly.
Thank you for your reply and your work
Regards
-éric
On 17/10/2022, 19:27, "Don Fedyk" <dfe...@labn.net> wrote:
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 <nore...@ietf.org>
É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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
