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 Last Call comments you may receive.

Document: draft-ietf-pwe3-static-pw-status-08
Reviewer: Ben Campbell
Review Date: 2011-10-04
IETF LC End Date: 2011-10-05

Summary: The draft is almost ready for publication as a proposed standard, but there are a few minor issues and editorial issues that need addressing first.

Major issues:

None

Minor issues:

-- 5.3:

Has the work group considered how the retransmit scheme and 30 second refresh default will scale to very large deployments? Seems like this could result in a lot of retransmissions.

-- 5.3, last paragraph: " This will cause the PE sending the all clear message to stop sending, and to continue normal operation."

Where is that specified? Can you offer a reference?

-- 5.3.1, 1st paragraph: "The receiving PE will then set its timeout timer according to the timer value that is in the packet received, regardless of what timer value it sent."

It's probably worth making a normative statement here, since it seems like this could easily result in an argument if the PEs disagree on the timer value.

-- 5.3.1, 2nd paragraph:

Please elaborate on "match exactly". What uniquely matches a message to an ack? How do you compare them?

"… the sender PE MUST use the new timer value received."

Doesn't this contradict the previous paragraph that lets the sender disagree? Is the subsequent treated different than the first attempt? (If so, is there a state machine that could be elaborated on?)

-- 5.3.2:

I don't understand the guidance here. Are you saying a PE should send status even when it can't?

-- 5.5, 1st paragraph: "… MUST be supported by both T-PEs to be enabled."

How does one T-PE know another supports this?

-- 5.5, last paragraph:

This could use some elaboration. What is the purpose of having to send both ways?



Nits/editorial comments:

-- general: 

IDNits returns some comments. I think something about the header format is confusing it.

-- abstract:

Please expand BFD on first mention

-- Section 2:

Please expand LDP and PE on first mention. (even though they are in the terminology section, since they are mentioned here before that section.)

-- section 2: "… without control plane."

Missing article ("a" or "the")

-- section 4:

Please expand PSN, MPLS-TP, and BFD on first mention.

-- section 5.1, 2nd to last paragraph: "...PW OAM Message code"

Missing "the"

-- section 5.1, last paragraph:

This seems redundant with the IANA considerations section.

-- 5.2, 1st paragraph: "PW Status messages are indicated…"

Indicated by what? (passive voice obscures responsible actor).

-- same paragraph: "PW Status TLV defined in [RFC4447].  The PW Status TLV format is as follows:"

I'm confused is defined in 4447 and just repeated here, or defined here? If the first, please be very clear about that, so there's no question about where the normative definition lives. For example: "PW Status TLV defined in [RFC4447], and is repeated here for the reader's convenience:"

-- 5.2, last paragraph: "PW OAM Status Messages MUST NOT be used as a connectivity verification method."

That sounds like it belongs in the "applicability" section.

-- 5.3, 2nd paragraph: "...will be transmitted immediately."

Transmitted by what? (passive voice obscures responsible actor).

-- 5.3.1, 1st paragraph: "The timer value set in the reply packet SHOULD then be used as the new transmit interval."

By what? (passive voice obscures responsible actor).

-- 5.3.1, last paragraph: "standard procedures"

Reference?

-- 5.5.1, last paragraph: "If Bit "B" is set , then the T-PE can receive S-PE bypass status messages in the G-ACH. If Bit "B" is not set the T-PE MUST NOT send S-PE bypass status messages in the G-ACH."

I think the sender and receiver are mixed up here. The text seems to say if the bit is set you may receive but if the bit is not set you must not send?

-- 8 : IANA Considerations

It would help to include the formal definition tables here, or reference them here. Also, can you include the URLs for each registry?

0x0022 appears to be already assigned to MPLS-TP CC message.

"Pseudowire Switching Point PE TLV Type""

I don't find that registry.  Did you mean sub-type?

0x16 appears to be already assigned to "Stack capability"