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:[email protected]] >> Sent: Tuesday, September 15, 2015 9:18 AM >> To: [email protected]; 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 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
