I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other (post) Last Call comments you may receive. Document: draft-ietf-mpls-tp-ethernet-addressing-07 Reviewer: Martin Thomson Review Date: 2013-04-19 IETF LC End Date: 2013-02-18 (!) IESG Telechat date: 2013-04-25 Summary: This document is almost ready for publication as proposed standard. There are some minor issues Major issues: None Minor issues: The structure of the document is odd. The individual pieces of explanation are good, it's just that different bits are revealed in a strange order. If the intent is to describe a method of selecting an Ethernet address to attach to MPLS-TP packets, I would have thought that structuring the document to correspond to the prioritization of methods would make sense. That is, from what I can infer: If unicast, use a unicast address (MUST for multipoint attachment, SHOULD for others) 1. from G-ACh, if available 2. from static configuration, if operationally feasible otherwise, for point-to-point links you can use 3. the IANA-assigned special address 4. FF-FF-FF-FF-FF-FF Reordering might help with understanding the process. If multicast/broadcast LSPs, there doesn't seem to be any actual recommendations or advice in the document. There is only an admonition to use encapsulation, which is probably necessary for other reasons anyhow. So it's not clear how Section 3, paragraph 1 is relevant to this document. It doesn't offer any guidance on how one might select an appropriate Ethernet address for those frames. Presumably these could be unicast, multicast or broadcast depending on routing requirements for the LSP, in which case maybe there is no good advice to give. If there really is no good advice to give, or there is no intent to provide advice for multicast/broadcast LSPs, a statement to that effect would be helpful. Section 3, Paragraph 2 just reiterates parts of Section 2, it could be removed. S5: I can't reconcile "The advertised information SHOULD be persistent across restarts." with "Received advertisements MUST be discarded across restarts." S4, pp5: Why force a mapping to EUI-64? Is canonicalization important for some reason? S4, pp5: The paragraph beginning with "In the event a GAP message is not received within the previously received associated Lifetime, ..." is a little confusing (and I'm familiar with G-ACh already). This could be clearer. Maybe: "A node could cease transmission of G-ACh advertisements, or cease to include a Source MAC Address TLV in advertisements, either of which cause the TLV lifetime to elapse. After the Source MAC Address TLV lifetime has elapsed, this value SHOULD no longer be used to select a MAC address; the node SHOULD return to selecting MAC addresses as though no advertisements were received." S7.3: IETF review is a pretty high bar. (Sadly, I missed this on G-ACh, or I would have made the same comment.) Did you consider allowing IESG Approval as an alternative? Nits/editorial comments: There are a couple of lowercase instances of RFC2119 keywords that could be confusing. The very last line of S4, the second last sentence of S2. Consider alternative wordings for these statements. S2, pp3: s/i.e. /i.e., /