Skip to main content

A YANG Data Model for IP Traffic Flow Security
draft-ietf-ipsecme-yang-iptfs-11

Yes

Roman Danyliw

No Objection

John Scudder
Zaheduzzaman Sarker
(Alvaro Retana)

Note: This ballot was opened for revision 07 and is now closed.

Roman Danyliw
Yes
Erik Kline
No Objection
Comment (2022-08-24 for -09) Not sent
# Internet AD comments for {doc-rev}
CC @ekline

## Comments

* I concur with Eric's Discuss.
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment (2022-08-25 for -09) Sent
The first question of the shepherd writeup was not completely answered.

Do you need BCP 14 (Section 1.1) at all?  You don't seem to use it anywhere.
Paul Wouters
No Objection
Comment (2022-08-23 for -09) Sent
# Paul Wouters, Security AD, comments for draft-ietf-ipsecme-yang-iptfs-08
CC @paulwouters

## COMMENTS

### bytes vs octets

The document describes counters in packets and octets, however usually these counters are exposed as packets and bytes. It even presents this to the user as bytes:

       leaf tx-octets {
         type yang:counter64;
         config false;
         description
           "Outbound Packet bytes";
       }

Why not use "bytes" instead of "octets" everywhere? For example RFC 9061 has:

       leaf bytes {
         type uint64;
         default "0";
         description
           "If the IPsec SA processes the number of bytes
            expressed in this leaf, the IPsec SA expires and
            SHOULD be rekeyed.  The value 0 implies
            infinite.";
       }

It also does not use "octets"
Warren Kumari
No Objection
Comment (2022-08-23 for -09) Sent
Thank you very much to the authors and WG for this document, and to the OpsDir reviewer (Sarah Banks) for the OpsDir review.
Zaheduzzaman Sarker
No Objection
Éric Vyncke
(was Discuss) No Objection
Comment (2022-08-31 for -10) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-yang-iptfs-08

CC @evyncke

Thank you for the work put into this document and for addressing my previous DISCUSS and COMMENT points (kept below for archiving only)

Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus even if there is no justification for the intended status. 

I hope that this review helps to improve the document,

Regards,

-éric


## Previous DISCUSS kept for archiving

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:

### Section A.2 wrong prefix size ?

```
             <i:local-prefix>2001:DB8::0/16</i:local-prefix>
             <i:remote-prefix>2001:DB8::1:0/16</i:remote-prefix>
```

Beside the lack of RFC 5952 (see my comment below), is it on purpose that both prefix with a /16 are identical ? The authors probably mean a different prefix size rather than /16.
## Previous COMMENTS kept for archiving

### Useless BCP 14 template ?

As indicated by id-nits, the BCP 14 template is included but there is no normative 'upper case' language in the document.

### Section A.2

Please ensure to follow RFC 5952 to represent IPv6 addresses, i.e., lowercase and maximum 0 compression.

## NITS

### Spelling of yang

s/yang/YANG/ at least in the abstract.

## 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
Alvaro Retana Former IESG member
No Objection
No Objection (for -09) Not sent

                            
Andrew Alston Former IESG member
No Objection
No Objection (2022-08-25 for -09) Not sent
Thanks for the document, I too support Éric's discuss on this.
Lars Eggert Former IESG member
No Objection
No Objection (2022-08-23 for -09) Sent
# GEN AD review of draft-ietf-ipsecme-yang-iptfs-08

CC @larseggert

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

## Comments

### Boilerplate

This document uses the RFC2119 keywords ['SHOULD NOT', 'OPTIONAL', 'REQUIRED',
'SHOULD', 'NOT RECOMMENDED', 'MAY', 'SHALL NOT', 'MUST', 'MUST NOT',
'RECOMMENDED', 'SHALL'], 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 is being deprecated:

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

### Grammar/style

#### Section 2, paragraph 4
```
t the packet-size and timing independently from any receiver. Both direction
                             ^^^^^^^^^^^^^^^^^^
```
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

## 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
Robert Wilton Former IESG member
(was Discuss) No Objection
No Objection (2022-08-31 for -10) Sent
Discuss cleared.  Thanks for accommodating my suggestions.