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

Request Review of draft-ietf-pwe3-iccp-stp
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-09-23
Requested 2015-09-11
Authors Mingui Zhang, Huafeng Wen, Jie Hu
Draft last updated 2015-09-15
Completed reviews Genart Last Call review of -04 by Brian Carpenter (diff)
Genart Telechat review of -04 by Brian Carpenter (diff)
Secdir Last Call review of -04 by Shawn Emery (diff)
Assignment Reviewer Brian Carpenter
State Completed
Review review-ietf-pwe3-iccp-stp-04-genart-lc-carpenter-2015-09-15
Reviewed rev. 04 (document currently at 05)
Review result Ready with Issues
Review completed: 2015-09-15

Review
review-ietf-pwe3-iccp-stp-04-genart-lc-carpenter-2015-09-15

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.