PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering
draft-ietf-pce-inter-layer-req-15

[Ballot comment]
Section 4.6. - Impact on Network Operation seems descriptive and contains no requirements (as do sections 4.1-4.5). If this is the case it should be explicitely stated.

[Ballot comment]
Please consider the questions raised on the Gen-ART Review by
  Ben Campbell on 14-Feb-2011.  He asks about Section 5.2:

  Is there a requirement that the proover must not make a second
  attempt inside a given time window? If so, that was not clear
  from the text.  If there is not such a requirement, are there
  security implications if the proover does send multiple messages
  inside the same tick?  It is not really a one time pad if that
  happens is it?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

To: IETF-Announce 
From: The IESG
Reply-to: ietf@ietf.org
CC:
Subject: Last Call: draft-ietf-pce-inter-layer-req (PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering) to Informational RFC

The IESG has received a request from the Path Computation Element WG
(pce) to consider the following document:

- 'PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer
  Traffic Engineering '
    as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-07. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pce-inter-layer-req-15.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14050&rfc_flag=0

> (1.a) Who is the Document Shepherd for this document?
Julien Meuric
> Has the
> Document Shepherd personally reviewed this version of the
> document and, in particular, does he or she believe this
> version is ready for forwarding to the IESG for publication?
Yes (reviewed and ready).
> (1.b) Has the document had adequate review both from key WG members
> and from key non-WG members?
Yes (version 14 already).
> Does the Document Shepherd have
> any concerns about the depth or breadth of the reviews that
> have been performed?
No concerns.
> (1.c) Does the Document Shepherd have concerns that the document
> needs more review from a particular or broader perspective,
> e.g., security, operational complexity, someone familiar with
> AAA, internationalization or XML?
No concerns.
> (1.d) Does the Document Shepherd have any specific concerns or
> issues with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he
> or she is uncomfortable with certain parts of the document, or
> has concerns whether there really is a need for it. In any
> event, if the WG has discussed those issues and has indicated
> that it still wishes to advance the document, detail those
> concerns here.
No concerns.
> Has an IPR disclosure related to this document
> been filed? If so, please include a reference to the
> disclosure and summarize the WG discussion and conclusion on
> this issue.
No IPR.
> (1.e) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with
> others being silent, or does the WG as a whole understand and
> agree with it?
The WG supports: requirements have been stable for a long time and
a solution I-D is WG document.
> (1.f) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> entered into the ID Tracker.)
No known conflict.
> (1.g) Has the Document Shepherd personally verified that the
> document satisfies all ID nits? (See theInternet-Drafts
> Checklist
> andhttp://tools.ietf.org/tools/idnits/). Boilerplate checks are
> not enough; this check needs to be thorough.
Yes.
> Has the document
> met all formal review criteria it needs to, such as the MIB
> Doctor, media type and URI type reviews?
Yes.
> (1.h) Has the document split its references into normative and
> informative?
Yes.
> Are there normative references to documents that
> are not ready for advancement or are otherwise in an unclear
> state?
No.
> If such normative references exist, what is the
> strategy for their completion? Are there normative references
> that are downward references, as described in [RFC3967]? If
> so, list these downward references to support the Area
> Director in the Last Call procedure for them [RFC3967].
N/A.
> (1.i) Has the Document Shepherd verified that the document IANA
> consideration section exists and is consistent with the body
> of the document?
IANA section is consistent.
> If the document specifies protocol
> extensions, are reservations requested in appropriate IANA
> registries? Are the IANA registries clearly identified? If
> the document creates a new registry, does it define the
> proposed initial contents of the registry and an allocation
> procedure for future registrations? Does it suggest a
> reasonable name for the new registry? See [RFC5226].
N/A.
> If the
> document describes an Expert Review process has Shepherd
> conferred with the Responsible Area Director so that the IESG
> can appoint the needed Expert during the IESG Evaluation?
Not needed.
> (1.j) Has the Document Shepherd verified that sections of the
> document that are written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc., validate correctly in
> an automated checker?
N/A.
> (1.k) The IESG approval announcement includes a Document
> Announcement Write-Up. Please provide such a Document
> Announcement Write-Up? Recent examples can be found in the
> "Action" announcements for approved documents. The approval
> announcement contains the following sections:
> Technical Summary
MPLS and GMPLS networks may be constructed from layered client/server
networks. It is advantageous for overall network efficiency to
provide end-to-end traffic engineering across multiple network
layers. PCE is a candidate solution for such requirements.

This document complements the generic requirements and presents
detailed sets of PCC-PCE communication protocol requirements and PCE
discovery protocol requirements for inter-layer traffic engineering.

> Working Group Summary
No controversy on the I-D.
> Document Quality
Comments sent by reviewers during last call have been addressed. A
solution I-D is currently PCE WG document.