IETF conflict review for draft-aranda-dispatch-q4s
conflict-review-aranda-dispatch-q4s-00

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    rfc-ise@rfc-editor.org,
    draft-aranda-dispatch-q4s@ietf.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-aranda-dispatch-q4s-09

The IESG has completed a review of draft-aranda-dispatch-q4s-09 consistent
with RFC5742.

The IESG has no problem with the publication of 'The Quality for Service
Protocol'  as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in WG
IPPM, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-aranda-dispatch-q4s/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-aranda-dispatch-q4s/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
Balloting  Yes, since there's no conflict with IETF work.

While reviewing, I did notice some areas where the document could perhaps
use more polish:

It discusses handling the "user's location" or updates thereto, as well as carrying
an explicit "public-address" attribute, but does not discuss the usability of IP addresses
as PII and the corresponding privacy considerations.

UTF-8 is used for human-readable strings but I didn't see mention of normalization or
other internationalization considerations.

There's a 505 "Version not supported" error code but not much of a clear mechanism
for actually performing version negotiation.

The default max content length of 1000 bytes doesn't match up with any natural transport limits
I'm aware of, and in fact is larger than an IPv4 network is guaranteed to be able to carry.

Similarly, when we read that "all BWIDTH requests sent MUST be 1 kilobyte in length (UDP payload
length by default" it's unclear how that would work on a network with MTU  smaller than 1kb,
and what the "UDP  payload length by default" refers to.

Section 9.6.1 talks about cases when "TCP packets are lost" but TCP is a stream protocol,
not a packet-based one, and more relevantly, provides reliable transport, so loss of carried
TCP data is detectable only as connection hang/timeout.

[Ballot comment]
No objection, however, I'd be curious how this document got to the ISE. Was this ever presented at dispatch (as the name indicates) or somewhere? Does anybody now?