Subject: Deborah Brungard's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)

From: Deborah Brungard via Datatracker <[email-masked]>
Date: Tue, 25 Jun 2019 11:12:49 -0700

Deborah Brungard has entered the following ballot position for
draft-ietf-rtgwg-enterprise-pa-multihoming-08: No Objection

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-rtgwg-enterprise-pa-multihoming/

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

Much thanks for a very comprehensive document!

Similar to Alvaro's (F),  I find a couple of sentences confusing.

I think it would be very helpful to clarify the scope of this document (in
this document), especially as Alvaro notes, the same working group
is progressing a PS document with another solution.

Examples:

- Abstract: I find the sentence "attempts..complete" solution a bit in conflict.
"Attempts" - either it does or doesn't. "complete" is questionable as it is focused
on a set of use cases. Suggest:

This document attempts to define a complete solution to this problem
/s/
This document examines currently available mechanisms for providing a solution
to this problem for a broad range of enterprise topologies.

- Section 4:
"The method described in the current document is functionally equivalent, but it is
intended to be easier to understand for enterprise network operators."
I don't find the justification "easier to understand for enterprise network operators" to be
convincing. Especially if there is already a PS document being progressed in the same working
group. Hopefully the PS document will also be easy to understand for both operators and vendors.
Suggest a better qualifier, even simply:
but it is intended to be easier to understand for enterprise network operators
/s/
but it is based on application of existing mechanisms for the described scenarios