Recommendation to Use the Ethernet Control Word
draft-ietf-pals-ethernet-cw-07
Yes
(Deborah Brungard)
(Suresh Krishnan)
No Objection
(Adam Roach)
(Alexey Melnikov)
(Alissa Cooper)
(Martin Vigoureux)
(Terry Manderson)
Recuse
(Ignas Bagdonas)
Note: This ballot was opened for revision 06 and is now closed.
Deborah Brungard Former IESG member
Yes
Yes
(for -06)
Unknown
Suresh Krishnan Former IESG member
Yes
Yes
(for -06)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -06)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(2018-06-18 for -06)
Unknown
The title of the document is "Use of Ethernet Control Word RECOMMENDED", which hints at the corresponding rfc2119 keyword: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. That seems to be in line with the description in the Introduction: "This document recommends the use of the Ethernet pseudowire control word in all but exceptional circumstances." However, the qualified recommendation is that if "both the ingress PE and the egress PE support the Ethernet pseudowire control word, then the CW MUST be used". What are the "exceptional circumstances"? Should that "MUST" be a "SHOULD"? Should the use be further qualified? This comment is not a showstopper, just a minor misalignment.
Ben Campbell Former IESG member
No Objection
No Objection
(2018-06-19 for -06)
Unknown
Others have mentioned it seems odd that the document says (in several places) that it recommends use of the CW, but section 4 says "MUST". In particular, the document _title_ says RECOMMENDED in all caps, which could be interpreted as an attempt at normative language. I think this is likely to confuse at least some readers. §3: The "recent posting" is from 2016. Calling that "recent" is already a bit dated.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2018-06-15 for -06)
Unknown
In Section 4: The use of both methods on the same PW is not normally necessary and should be avoided unless circumstances require it. The "both" here refers to ELI and FAT PW (as opposed to CW and something), right? Should that be disambiguated or is it clear enough as-is?
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -06)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-06-18 for -06)
Unknown
One minor recommend edit: Given that this drafts updates RFC4448 to a MUST, maybe s/This document recommends /This document requires/
Spencer Dawkins Former IESG member
No Objection
No Objection
(2018-06-20 for -06)
Unknown
In this text, This problem has recently become more serious for a number of reasons. Firstly, due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6 assigned by the IEEE Registration Authority Committee (RAC). Secondly, concerns over privacy have led to the use of MAC address randomization which assigns local MAC addresses randomly for privacy. Random assignment results in addresses starting with one of these two values one time in eight. the problem caused by the second case is explained well, but the problem caused by the first reason is not. Would it be correct to say This problem has recently become more serious for a number of reasons. Firstly, due to the deployment of equipment with Ethernet MAC addresses that start with 0x4 or 0x6 assigned by the IEEE Registration Authority Committee (RAC). Any addresses that start with either of these two values can be misidentified. Secondly, concerns over privacy have led to the use of MAC address randomization which assigns local MAC addresses randomly for privacy. Random assignment results in addresses starting with one of these two values one time in eight. ?
Terry Manderson Former IESG member
No Objection
No Objection
(for -06)
Unknown
Ignas Bagdonas Former IESG member
Recuse
Recuse
(for -06)
Unknown