Hi Authors,

Thank you for working on this document. And thanks to Tommy Pauly, and Joe 
Touch for providing their reviews.

Here is my review that is divided between COMMENTs and NITs. I expect the 
COMMENTs to be resolved before the document is sent for IETF Last Call.

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 1, paragraph 1
>    IP Flow Information Export (IPFIX) [RFC7011] is a protocol that is
>    widely deployed in operators networks for traffic management
>    purposes

Would it be fair to say, that IPFIX is used for traffic monitoring and not 
directly traffic management?

Section 2, paragraph 2
>    This document uses the IPFIX-specific terminology (e.g., Flow)
>    defined in Section 2 of [RFC7011].  As in [RFC7011], these IPFIX-
>    specific terms have the first letter of a word capitalized.
>
>    Also, this document uses the terms defined in Section 3 of
>    [I-D.ietf-tsvwg-udp-options].

It would help to identify which terms are being used from each of the documents 
in this draft. Also, is the rule that the IPFIX specific terms have the first 
letter captilized? What about udpOptions?

Section 5, paragraph 3
>                    Figure 2: An Example of udpOptions IE

Can the description be expaned to say "An Example of udpOptions with EOL and 
APC options?

Section 5, paragraph 10
>      udpSafeExperimentalOptionExID IE:
>
>      MSB                                                          LSB
>                           1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              0x9858           |             0xE2D4            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      udpUnsafeExperimentalOptionExID IE:
>
>                           1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              0xC3D9           |             0x9658            |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>               Figure 3: Example of UDP Experimental option IEs


This example is not clear or confusing. The explanation above talked about SAFE 
and UNSAFE Experimental options. How is the range of 0-191 for SAFE or the 
range of 192-255 encoded in these values? Or if they are not, because they come 
part of the UDP options, then how about showing what the UDP options field 
looks like? In other words, can Example 2 and Example 3 be combined to show a 
more complete example?

No reference entries found for these items, which were mentioned in the text:
[URL_IANA_UDP_OPTIONS] and [URL_IANA_UDP_ExIDs].

Note, the following comment is boilerplate output from the review tool I use. 
However, it is true that draft-ietf-tsvwg-udp-options currently is in WG LC and 
does not have the intended RFC status set, and thus the message. Also note that 
this document will result in MISREF state unless the other document moves 
forward and gets approved as an RFC.

DOWNREF [I-D.ietf-tsvwg-udp-options] from this Proposed Standard to
draft-ietf-tsvwg-udp-options of unknown standards level. (For IESG discussion.
It seems this DOWNREF was not mentioned in the Last Call and also seems to not
appear in the DOWNREF registry.)

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

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.

Section 5, paragraph 1
>    Given UDP kind allocation in Section 10 of
>    [I-D.ietf-tsvwg-udp-options] and the option mapping defined in
>    Section 4.1 of this document, fewer octets are likely to be used for
>    Flows with mandatory UDP options.

Inconsistent use of the term Kind. Sometimes it is used with a captial K but 
other times it is used with a small k.

Document references draft-ietf-tsvwg-udp-options-28, but -32 is the latest
available revision.

Document references draft-ietf-opsawg-ipfix-tcpo-v6eh-08, but -10 is the latest
available revision.

Mahesh Jethanandani
mjethanand...@gmail.com






_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to