[Dots] Suresh Krishnan's Discuss on draft-ietf-dots-data-channel-28: (with DISCUSS and COMMENT)

[Suresh Krishnan via Datatracker <[e-mail]>]

Suresh Krishnan has entered the following ballot position for
draft-ietf-dots-data-channel-28: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 4.3

The processing requirements for the tcp flags bitmask is not at all clear.
Specifically how should an implementation use the values in the flags, operator
and the bitmask fields in the tcp subtree to figure out if a given packet
matches. An example here could be very helpful.

"Bitmask values can be encoded as a 1- or 2-byte bitmask."

How? The bitmask field is a uint16. How would a client indicate a 1 byte
bitmask?

[Also note that there are *nine* flags defined for TCP including the
experimental NS bit that occurs as bit 7 of Octet 12 and a 1 byte bitmask will
not catch them all]


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

How does the flags field in the ipv4 match subtree interact with the bits in
the fragment side? I can easily see that someone can make a mistake due to this
redundancy and come up with something that is not coherent. e.g. bit "more"
under flags is set and bit "lf" under fragment-> type is also set .