Martin: Thank you for the review! Authors, Stewart, can you take a look at the issues below?
Jari On Apr 20, 2013, at 2:38 AM, Martin Thomson <[email protected]> wrote: > 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., / > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
