IETF conflict review for draft-rprice-ups-management-protocol
conflict-review-rprice-ups-management-protocol-00

The following approval message was sent
From: The IESG
To: Eliot Lear ,
    draft-rprice-ups-management-protocol@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-rprice-ups-management-protocol-13

The IESG has completed a review of draft-rprice-ups-management-protocol-13
consistent with RFC5742.

The IESG has no problem with the publication of 'Uninterruptible Power Supply
(UPS) Management Protocol -- Commands and Responses'
as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in WG
NETCONF, 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-rprice-ups-management-protocol/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-rprice-ups-management-protocol/

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

Thank you,

The IESG Secretary

[Ballot comment]
Thanks for this document, I found it interesting and easy to read. All of my comments other than the last one are minor proofreading or style points.

1. In the Introduction, “a continuous media” makes me sad because of the disagreement in number. I get that this may reflect common usage but it still made me wince. The obvious way to make it conventionally grammatical would be “a continuous media stream” but I suppose that would make the definition recursive. :-( So, I don’t have a good solution to offer but maybe you do; if so that’d be nice.

2. Introduction, “match to client's consumption rate” should be “match the client's consumption rate”.

3. In Section 3.6, “Bittorrent favored peers
  who uploaded as much as they downloaded, so that new Bittorrent users
  had an incentive to significantly increase their upstream bandwidth
  utilization.”

I think you don’t mean “so that”, but just “so” — the implied causal arrow is reversed by the “that”, you mean something like “therefore”, right?

4. In 3.7 you seem to have a stray close brace? “}”

5. In 3.7 you misspelled Craig Labovitz’s name as “Labowitz”. The "v" spelling is correct.

6. Section 5.5.3, s/detction/detection/

7. Section 6.1, s/tansport/transport/

8. Section 6.1, “approaches like the above generally
  experiences”, should be “generally experience” (agreement in number).

9. Section 7, “prevent media steam manipulation” should be “stream”.

10. Section 7.2 has

  The choice of whether to involve intermediaries sometimes requires
  careful consideration.  As an example, when ABR manifests were
  commonly sent unencrypted some networks would modify manifests during
  peak hours by removing high-bitrate renditions in order to prevent
  players from choosing those renditions, thus reducing the overall
  bandwidth consumed for delivering these media streams and thereby
  improving the network load and the user experience for their
  customers.  Now that ubiquitous encryption typically prevents this
  kind of modification, in order to maintain the same level of network
  health and user experience across networks whose users would have
  benefitted from this intervention a media streaming operator
  sometimes needs to choose between adding intermediaries who are
  authorized to change the manifests or adding significant extra
  complexity to their service.

It wasn’t immediately obvious to me as a reader what recourse (other than intermediaries) the media streaming operator would have, regardless of their willingness to add extra complexity.

- Are you implicitly referencing something you’ve touched on elsewhere in the document (an xref would be nice if so),

- or are such “extra complexity” solutions known and published (again, a ref would be nice),

- or known but proprietary special sauce (maybe there’s nothing to be done, although a few words indicating this might be suitable),

- or are you just speculating on the basis that as the saying goes, with enough thrust, even a brick can fly?

[Ballot comment]
Thanks for this document, I found it interesting and easy to read. All of my comments other than the last one are minor proofreading or style points.

1. In the Introduction, “a continuous media” makes me sad because of the disagreement in number. I get that this may reflect common usage but it still made me wince. The obvious way to make it conventionally grammatical would be “a continuous media stream” but I suppose that would make the definition recursive. :-( So, I don’t have a good solution to offer but maybe you do; if so that’d be nice.

2. Introduction, “match to client's consumption rate” should be “match the client's consumption rate”.

3. In Section 3.6, “Bittorrent favored peers
  who uploaded as much as they downloaded, so that new Bittorrent users
  had an incentive to significantly increase their upstream bandwidth
  utilization.”

I think you don’t mean “so that”, but just “so” — the implied causal arrow is reversed by the “that”, you mean something like “therefore”, right?

4. In 3.7 you seem to have a stray close brace? “}”

5. In 3.7 you misspelled Craig Labovitz’s name as “Labowitz”. The "v" spelling is correct.

6. Section 5.5.3, s/detction/detection/

7. Section 6.1, s/tansport/transport/

8. Section 6.1, “approaches like the above generally
  experiences”, should be “generally experience” (agreement in number).

9. Section 7, “prevent media steam manipulation” should be “stream”.

10. Section 7.2 has

  The choice of whether to involve intermediaries sometimes requires
  careful consideration.  As an example, when ABR manifests were
  commonly sent unencrypted some networks would modify manifests during
  peak hours by removing high-bitrate renditions in order to prevent
  players from choosing those renditions, thus reducing the overall
  bandwidth consumed for delivering these media streams and thereby
  improving the network load and the user experience for their
  customers.  Now that ubiquitous encryption typically prevents this
  kind of modification, in order to maintain the same level of network
  health and user experience across networks whose users would have
  benefitted from this intervention a media streaming operator
  sometimes needs to choose between adding intermediaries who are
  authorized to change the manifests or adding significant extra
  complexity to their service.

It wasn’t immediately obvious to me as a reader what recourse (other than intermediaries) the media streaming operator would have, regardless of their willingness to add extra complexity.

- Are you implicitly referencing something you’ve touched on elsewhere in the document (an xref would be nice if so),
- or are such “extra complexity” solutions known and published (again, a ref would be nice),
- or known but proprietary special sauce (maybe there’s nothing to be done, although a few words indicating this might be suitable),
- or are you just speculating on the basis that as the saying goes, with enough thrust, even a brick can fly?