Skip to main content

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

Yes

(David Ward)
(Ross Callon)

No Objection

(Chris Newman)
(Cullen Jennings)
(Dan Romascanu)
(Jari Arkko)
(Jon Peterson)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Russ Housley)
(Tim Polk)

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

Lars Eggert
(was Discuss) No Objection
Comment (2009-01-15) Unknown
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.
David Ward Former IESG member
Yes
Yes () Unknown

                            
Ross Callon Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (2009-01-14) Unknown
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.
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection () Unknown