Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation
RFC 6662

Please include in the document some information about the nature of the experiment.

Some 2119 and like comments:

3.2.1.  Data Collection

   The PCN-egress-node MUST meter the PCN-traffic it receives in order

MUST is wrong here. "needs to"

   Informative note:

What does the word "Informative" add here? I think you should strike it.

3.3

   A compliant Decision Point MUST implement both mechanisms

Why? What is the interoperability problem or damage to the network if I don't implement both?

3.3.3 - I don't understand the interoperability or damage implications of most of the SHOULDs in this section, especially the "notify management" ones. Even the timer ones:

   A centralized Decision Point SHOULD start a timer t-sndFail when it
   sends a request for the estimated value of PCN-sent-rate to a given
   PCN-ingress-node.  If the Decision Point fails to receive a response
   from the PCN-ingress-node before t-sndFail reaches the configurable
   value T-crit, the Decision Point SHOULD repeat the request...

The second SHOULD is probably right. The first SHOULD is at least redundant and I think more likely just misused. The interoperability concern is when to repeat the request, which is when t-sndFail reaches T-crit. That the Decision Point starts the timer on send is either obvious (how else would it know), or it's an implementation choice (it determines resends in some other way), but either way it's not the *starting* of the timer that's the protocol instruction.

This document contains quite a bit of requirements terminology. Are we sure that
Informational is appropriate? Did the WG consider making this a standards-track
Applicability Statement (Section 3.2 of RFC 2026)?

s6: This is similar to Stephen's comment: Because RFC 5559 doesn't use the term "decision point" explicitly, I think that adding some text along the lines of "The decision point is considered to be part of a PCN-node; therefore, the decision point is considered to be trusted for truthful decisions."  This makes it clear that s6.3.1 of RFC 5559 applies.

s4.2.1: I find it a little odd that you say you're paraphrasing two sections but there's 2119 language in this draft where there was none in RFC 5559.  Granted it's mostly MAY this and MAY that so it's not that big of a deal, but there is a MUST and a NOT RECOMMENDED.  Are you really paraphrasing the text from RFC 5559 in that case?

s1.1: Need to add NOT RECOMMENDED to the key words.

- The security considerations section doesn't note the inherent
vulnerability if the decision point is separated from the enforcement
point(s). That is, the enforcement points (in/egress nodes) have to
have an interface that could be called from some malicious node. Even
if the PDP/PEP protocol is not in scope here, this scheme means that
problem exists and there are clear DoS vectors implicit in that. RFC
5559 which is referenced from this does say that "The signalling
between the PCN-boundary-nodes must be protected from attacks" so I
guess this is not discuss-worthy.

- Total nit: t-recvFail is not a great name for a time - too easy to
mistake for a subtraction, I'd suggest t_recvFail if it makes no
difference. (And same for other names.)