Comments regarding fragmentation/reassembly:

* Comparing the different (IPv4, IPv6, UDP-Notif) ways of fragmentation
  and reassembly: All use a single flag to encode that a fragment is the
  last one. IPv6 and UDP-Notif use a 32-bit message ID, IPv4 only a 16-bit
  one. IPv4 and IPv6 use an byte offset for ordering, UDP-Notif uses a
  segment number.
  For IP level fragmentation, the ID field is per src/dst addr, protocol
  triple, for UDP-Notif, per UDP session. So this is much better and
  OK in my view.
* I assume that the Segment Number cannot wrap around. But this needs to
  be stated.
* I also assume that segments of a single message can be received in any order.
  However, this is not stated. So it should be made clear.
* How long should fragments be stored before they are discarded. That should
  be stated.
* That would make this solution at least as good as the IP level ones.
  It would also be similar to what is provided by draft-ietf-tsvwg-udp-options,
  section 11.4.
* Section 4.1 states:
  "Implementations of the mechanism SHOULD provide a configurable
   max-segment-size option to control the maximum size of a payload."
* I wonder how the sender side knows, what the receiver is able to process.
  It might make sense to exchange this information at the beginning of
  the communication.

Major issue:
* Using the suggested protocol results in a high bandwidth using UDP based
  communication. It is really suggested to use some sort of congestion
  control. However, the document arguments that this is not needed, since
  the protocol is used only on "managed networks" as stated in Section 5.1.
  What confuses me is that in Section 6, the document discusses the use
  of the protocol in "open or unsecured" networks. How does this relates
  to "managed networks"? In my understanding, this does not fit. Do you
  really not need some congestion controller?
  I would expect to see some sort of circuit breaker, but have not seen
  a description of it.

Minor issues:
* Section 3.2
  I guess all binary fields in the header shown are expected to be transmitted
  and received in network byte order (big endian), but I would prefer to make
  this explicit.
* Section 3.2
  Is it allowed that the Message ID wraps around? It seems so, but I think it is
  better to make that explicit.
* Section 4.1
  The length field in the UDP header is limited to 65535 bytes, therefore the
  UDP payload is limited to 65535 - 8 bytes, which is 65527 bytes. This is smaller
  than stated in the first sentence. In addition to that, when using IPv4, the size
  is even 20 bytes smaller, since the IPv6 header contains a 16-bit field holding
  the total length of the IPv4 packet.
* Section 4.2
  What should happen if the Private Encoding Option is present, but the S-bit is
  not set? What should happen if the S-bit is set, but the Private Encoding Option
  is not present?