Last Call Review of draft-ietf-pwe3-iccp-stp-04
review-ietf-pwe3-iccp-stp-04-genart-lc-carpenter-2015-09-15-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-pwe3-iccp-stp-04.txt
Reviewer: Brian Carpenter
Review Date: 2015-09-15
IETF LC End Date: 2015-09-23
IESG Telechat date:

Summary: Ready with issues
--------

Comment:
--------

It's impossible for a reviewer who is not expert in the details
of 802.1Q to check many details in this draft, so I didn't.

Major Issues:
-------------

The draft does not properly explain the theory of operation.
The messages are defined but it is not explained when a spanning
tree is formed. Section 4 does not help with this. I think it
should be explained at the end of the Use Case section.

The main normative reference appears to be IEEE 802.1Q-2005. The current
standard is IEEE 802.1Q-2014, which appears to be very different.
I think this should be discussed in the text to avoid confusion.

> 3.6. STP Synchronization Data TLV
...
> When the total size of the TLVs to be transmitted
> exceeds the maximal size of a fragment, these TLVs SHOULD be divided
> into multiple sets, delimited by multiple pairs of STP
> Synchronization Data TLVs, and filled into multiple fragments.

There needs to be discussion of what happens if a fragment
is lost.

Minor Issues:
-------------

> 3.2.1. STP Disconnect Cause sub-TLV
...
>       - Disconnect Cause String
>
>        Variable length string specifying the reason for the disconnect,
>        to be used for operational purposes.

Should it be specified whether this is ASCII, UTF-8,...?

> 3.3.1. STP System Config
...
>       - MAC Address

Excuse my ignorance, but are there any scenarios where this would need
to be EUI-64?

Nits:
-----

Please expand Spanning Tree Protocol in the main title.

Abbreviation PE used but not defined. Also, "provider edge" means an edge,
which is an abstract concept, not a device. If the draft is discussing
specific devices, it should say "PE device" or "PE router" or "PE switch".

Abbreviation AC used but not defined.

Abbreviation CE used but not defined.