Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)
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
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, correct? 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
Abstract: 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.