Media Access Control (MAC) Address Withdrawal over Static Pseudowire
draft-ietf-pals-mpls-tp-mac-wd-03

Clearing based on the text for -03.
Thanks for addressing my Discuss.

I have some comments that, while non-blocking, I would like to see addressed before publication.

1. Section 3. (MAC Withdraw OAM Message)  I don't understand why "when sequence number wraps, all MAC addresses are flushed".  Presumably, the wrap in the sequence number would be the result of a new MAC List TLV, so why would all the addresses be flushed and not just the ones on the list?  What am I missing?

2. Section 4.1. (Operation of Sender)  "…if a need to send a new MAC withdraw message with updated sequence number arises then retransmission of the older unacknowledged withdraw message MUST be suspended and retransmit time for the new sequence number MUST be initiated."  That sounds fine to me, but I have a related question.  Should the contents of the withdraw message include both the un-ack'ed list as well as the new addresses?  It is not clear from the text above.  I ask this in light of the text in Section 3 that reads: "The receipt of same or lower sequence number message is responded with ACK but does not cause removal of MAC addresses."  IOW, if the un-ack'ed list is not included in the new message then those addresses may not be withdrawn.

3. Also in 4.1. "The 'R' reset bit is set in the first MAC withdraw…"  I'm assuming the Sequence Number with the R-bit set will always be 1, is that true?  Does the text mean that there will in fact be a MAC List TLV if the R-bit is set?  Later in Section 4.2 it says that a message "…with 'R' bit set…MAC withdraw message processing is performed as described above."   All this seems problematic due to the text ("above") that says: "If the sequence number in the received message is smaller than or equal to the value in the register, the MAC TLV(s) is/are not processed."  IOW, of the R-bit is set (assuming Sew Number = 1), then the Seq Number will be smaller than whatever was received before and the MAC TLV will not be processed.  The logic doesn't seem to work for me..

4. Security Considerations.  I traced all the way back to RFC4385, where it hints at the ability of an attacker to disrupt the PW by misusing the associated channel..but couldn't find an authoritative reference to whether spoofing or changing the messages in flight is an issue.  I'm worried about the ability of someone to, for example, inject/modify the MAC List, or simply change the R-bit setting.  I may just be paranoid, so please point me in the right direction.

Just total nit-level stuff here, mostly unexpanded abbreviations that should be expanded.  

Note to responsible AD: While "MAC", by itself, still needs to be expanded (because of multiple possible meanings), "MAC address", as a unit, probably qualifies for flagging in the RFC Editor's abbreviation list as not requiring expansion.

-- Abstract --
PW, VPLS, H-VPLS
(Because the abstract has to stand alone.)

-- Introduction --
PBB.  It would also help to have a forward pointer to Section 2, though I honestly don't know how to do that without having it look silly.

-- Section 2 --
For MPLS, "Multiprotocol" (one word, no capital "P") is the preferred spelling.
For PW, "Pseudowire" (no capital "W") is the preferred spelling.

-- Section 3 --
H-VPLS

-- Section 4.2 --

   A MAC withdraw message with 'R' bit set MUST be processed by
   resetting the send and receive sequence number first.

I suggest making it "the send-and-receive sequence number" (with hyphens), so no one thinks there are two sequence numbers (and gets confused by it not being "numbers").

Just a few editorial comments:

- Please expand PW, H-VPLS and PBB-VPLS on first mention. (The abbreviation list is helpful, but it's still good to expand them in place on first mention.)

- section 1, first paragraph:

s/withdrawl/withdrawal

- section 3: "A single bit (called A-bit) is set to indicate if a MAC withdraw message is for ACK"

I don't understand what this means, and I don't find any further explanation of the A-Bit. Do you mean to say that the MAC withdraw message requires an ACK? Isn't that always true? If the A-bit is already defined elsewhere, a citation would be helpful.

- Paragraph starting with "Only half of the sequence number space is used. "

It seems odd to find that between the descriptions of the A and R bits. Does it relate to the A-Bit, or does it stand alone? (I gather the latter.)

- There's an empty "Informative References" section.

I agree with the Gen-ART review from Ralph Droms; there are points where this document could be clearer. The one case that I felt personally strongly about was the part about what number the sequence numbers must start from. The text makes the reader wonder if one should read it literally, or if the starting number is handled differently. It would be better to be explicit.

I have balloted no-obj for this document, but would very much like to see the discussion with Ralph continue and some changes based on the comments adopted.

I also agree with the SecDir review (Stephen already provided a link) and would like to see the security considerations specific to this draft added.

- The secdir review [1] raised a few points that deserve a
response I think, did I miss the response? 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06097.html

- Where in the referenced RFCs in the security considerations
is the DoS potential of MAC address withdrawal covered?