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., /