Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pwe3-iccp-stp-04

[Brian E Carpenter <[e-mail]>]

Hi Mingui,

Thanks for your reply. Your proposed changes look good to me.

Regards
   Brian

On 17/09/2015 14:18, Mingui Zhang wrote:
> Hi Brian, 
> 
> Thanks for your careful review! Please see my responses in-line below.
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[e-mail]]
>> Sent: Tuesday, September 15, 2015 9:18 AM
>> To: [e-mail]; General Area Review Team
>> Subject: Gen-ART Last Call review of draft-ietf-pwe3-iccp-stp-04
>>
>> 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.
> 
> Sure. This will be added.
> 
>>
>> 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.
> 
> The text related to the reference will updated. 
> 
>>
>>> 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.
> 
> Since there is "Request Number", the lost fragment can be identified and be re-requested. This will be clarified.
> 
>>
>> 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,...?
> 
> Sure. According to RFC 7275, UTF-8 will be used.. 
> 
>>
>>> 3.3.1. STP System Config
>> ...
>>>       - MAC Address
>>
>> Excuse my ignorance, but are there any scenarios where this would need to be
>> EUI-64?
> 
> The document defines it to be the 48-bit MAC. It is in consistency with RFC 7275. I think EUI-64 could be supported in the future with a protocol version update.
> 
>>
>> 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.
> 
> These nits will be corrected.
> 
> Thanks,
> Mingui
>