Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)
RFC 5541

Note: This ballot was opened for revision 06 and is now closed.

(Ross Callon) Yes

(David Ward) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

Lars Eggert (was Discuss) No Objection

Comment (2009-01-15)
No email
send info
Section 4., paragraph 4:
>    - residual bandwidth on link L is denoted r(L)
>    - maximum reservable bandwidth on link L is denoted R(L).

  I assume that r(L) is the residual bandwidth that is available for
  reservation and not the instantaneous available capacity on a link,

Section 5., paragraph 3:
>      Type 5 (suggested value to be assigned by IANA) : Load of the most
>      loaded link.

  Similar to my previous comment, does load here refer to the
  (normalized) amount of reserved capacity, or to actual instantaneous
  load levels? If the latter, what are the timing/accuracy bounds on
  that information, and how are they guaranteed?

  Document needs to be spell-checked.

(Pasi Eronen) No Objection

(Russ Housley) No Objection

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(Magnus Westerlund) No Objection

Comment (2009-01-14)
No email
send info

The abstract is fairly long and seems to be more an introduction than a abstract.

Section 6.1:

One of the data entries of the PCE Objective Function registry is Defining RFC. Considering that you have FCFS policy that allow any registrations then "Defining RFC" may not be the best column name. Reference and contact Person seems to be what should be present. Where Contact Person for the Consensus part is not required, but Reference is, and the the FCFS where Reference is recommended(?) and Contact is required. 

I would also note that IETF consensus does not longer exist as policy in RFC 5226, it is called IETF Review instead.