Definitions of Managed Objects for IP Traffic Flow Security
draft-ietf-ipsecme-mib-iptfs-11

# Internet AD comments for {draft-ietf-ipsecme-mib-iptfs-05}
CC @ekline

## Comments

### S4.1, and elsewhere

* Tracking "incomplete" packets made me wonder: should there be a counter
  for number of packets fragmented?

# Routing AD comments for draft-ietf-ipsecme-mib-iptfs-08

## COMMENTS

### Section 4.2

You have "TFS bit rate may be specified at layer 2 wire rate" and "TFS bit rate may be specified at layer 3 packet rate". Shouldn't that be "as", not "at"? I did go looking for insight in ipsecme-yang but it just made me think that document has the same (looks to me like a) bug.

### Section 6

I'm a little mystified why "For the implications regarding write configuration" considering this is a read-only MIB? (Which the very next paragraph goes on to say.) The same applies a few paragraphs down where you talk about "who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module" -- isn't it really just who can GET (read) the objects? And the same for the "Further" bullet point.

## NITS

- s/paccket/packet/

Thank you for writing this document. I found it well written and easy to read...

I have a few nits and similar to contribute to (hopefully) make the document even better. Feel free to incorporate them or not, no reply needed...

"Note an IETF MIB model for IPsec was never standardized however the
   structures here could be adapted to existing proprietary MIB
   implementations where SNMP is used to manage networks."
P: "Note that an..." 
P: "was never standardized, however..."


"The value for each entry must remain constant at least
from one re-initialization of entity's network management
system to the next re-initialization."
P: "of the entities..." (unless this makes it too long)

"wire rate.  On
 transmission, target bandwidth/bit rate in bps for iptfs
 tunnel.  This rate is the nominal timing for the fixed
 size packet. If congestion control is enabled the rate"
C: Throughout the document there seems to be an odd mix of single and double-spaces (hey! I did note that this section is nits :-))

"information that IP traffic flow security obscures such as the true activity of the flows using IP traffic flow security."
P: "obscures, such as..."

Thanks for addressing my discuss points.

Thanks to Brian Trammell for his TSVART review and I agree with this observations.

Thank you, Don, for quickly addressing my DISCUSS and COMMENT points from my ballot. I sincerely hope that this discussion has improved the document.

Please do not forget to also update the tree with the right OID prefix ;-) but I am trusting you and the AD, Roman.

For archive: the previous DISCUSS ballot is at https://mailarchive.ietf.org/arch/msg/ipsec/sbb3MSPy8XwkHPIZCNt9ZRCd6BQ/

Regards

-éric

# GEN AD review of draft-ietf-ipsecme-mib-iptfs-

CC @larseggert

Thanks to Joel Halpern for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/5gau5fsdf6JutMgWnPRn9R_HVto).

## Comments

### Section 3, paragraph 3
```
     This document specifies an extensible operational model for IP-TFS.
     It reuses the management model defined in
     [I-D.ietf-ipsecme-yang-iptfs].  It allows SNMP systems to read
     operational objects (which includes configured objects) from IPTFS.
```
The document uses IPTFS, IP-TFS, tfs, iptfs, Iptfs - please pick one and use it
consistently.

### Boilerplate

This document uses the RFC2119 keywords "RECOMMENDED", "NOT RECOMMENDED",
"MUST", "MUST NOT", "MAY", "OPTIONAL", "SHALL NOT", "SHOULD", "NOT
RECOMMENDED", "SHALL", "REQUIRED", and "SHOULD NOT", but does not contain the
recommended RFC8174 boilerplate. (It contains some text with a similar
beginning.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

### URLs

These URLs point to tools.ietf.org, which has been taken out of service:

 * https://tools.ietf.org/html/rfcXXXX

## 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. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

I support Zahed's DISCUSS.

Thanks to Brian Trammell for the TSVART review.

Hi,

Thanks for this document.  Please can you add an RFC editor's note to ensure that the MIB Module and MIB tree are suitably updated once IANA has assigned a code point for the iptfsMIB.

I support Eric's comment that Guage32 (or possibly even CountedBasedGauge64 defined in RFC 2856) may be a better choice than Counter64 for the l2FixedRate and l3FixedRate.  However, I also appreciate that there is probably also a strong desire to keep the MIB entirely consistent with the YANG.

I noted that the IANA considerations section is requesting an OID code point for both the iptfs and ipsec MIBs, but it wasn't clear to me why ipsec was being registered here, since the isn't any ipsec MIB being defined in this document.  Is this registration left over from an earlier draft, or does it serve some other purpose?

Regards,
Rob