Unanswered Questions in the Path Computation Element Architecture
draft-ietf-pce-questions-08

[Ballot comment]
Thanks for making changes to how draft-ietf-pce-stateful-pce is used/referenced in the document, and I'm convinced that it is now an informational reference only.  I suggest one change to make it clear that the relevant terminology is adequately explained here, and that the stateful-pce draft is only for additional information:

OLD
  Readers are assumed to be thoroughly familiar with terminology
  defined in [RFC4655], [RFC4726], [RFC5440], [RFC5623], [RFC6805],
  and [I-D.ietf-pce-stateful-pce].

NEW
  Readers are assumed to be thoroughly familiar with terminology
  defined in [RFC4655], [RFC4726], [RFC5440], [RFC5623], and
  [RFC6805].  More information about terms related to stateful PCE
  can be found in [I-D.ietf-pce-stateful-pce].

[Ballot discuss]
There was some good points brought up in the SecDir review, with helpful responses (thanks Adrian).

I'd like to see improvements from the SecDir review, still in discussion:
http://www.ietf.org/mail-archive/web/secdir/current/msg04910.html

1. On Ben's first point, could a reference be provided since this draft is discussing stuff that exists (security considerations are included in...)

>> Indeed, this RFC discusses many things that have quite serious
>> security considerations, without mentioning any of them. For example,
>> section 4 "How Do I Find My PCE?" (the very first question) advocates
>> a number of potentially completely insecure mechanisms with no mention
>> of their security properties (or otherwise). This is obviously
>> pervasive, given the stance taken in the security considerations.

2. For Ben's second question, Adrian provided a list of references, are they already planned to be included in the next update?
From Adrian:
> Previous PCE RFCs have given some attention to security concerns in the use of PCE (RFC 4655), PCE discovery (RFC 4674, RFC 5088. RFC 5089), and the PCEP (RFC 4657 and RFC 5440). As such, "PCE Security" was not deemed by the authors to be a previously "unanswered question" and so did not need attention in this document.


From the rest of the discussion, I'd be happy to see the issues called out with references on where to find more information.  This strikes a balance and ensures the security considerations are made known to the user and provides the pointer of where to look.  I agree that we don't need to bloat the draft, but do agree that the issues should be made known.

Thanks!

[Ballot comment]
Nice draft, just found a nit and figured I'd point it out so it doesn't get forgotten.

Nit: In the last sentence of #8, I think "provide" should be "provider".
  In fact, each service provide could
  run its own parent PCE while allowing its child PCEs to be contacted
  by outsider parent PCEs according to configured policy and security.

[Ballot comment]
Just noting that in Sections 4 and 9, ALTO is not the only protocol to use the RFC 4848 mechanism for server discovery -- discovery of a local location information server (RFC 5986) was previously specified this way and was, I believe, the inspiration for the ALTO mechanism.

[Ballot discuss]
This ain't no thang, really... a small procedural point:

---------------------------

  [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE",
              draft-ietf-pce-stateful-pce, work in progress.

              Note as per [RFC4897]
                This reference is to a target document that is not yet
                published as an RFC.  Readers should exercise caution
                since the referenced document might be less stable than
                this document, however the essential description of the
                stateful PCE is considered t be stable at this time.

[Note to RFC Editor: Per RFC 4897, publication of this document does not
need to be held pending the availability of this reference as an RFC.
Please remove this note before publication.]

---------------------------

Methinks you misunderestimate RFC 4897: it is talking about citing a published RFC that's at a lower level of maturity than the source document (see Section 5 of 4897).  It does *not* cover normative references to Internet drafts, nor should it.  This document will have to wait in the RFC Editor queue until the stateful-pce document is ready, and the above notes should be removed (along with the reference to 4897).

[Ballot discuss]
This ain't no thang, really... a small procedural point:

---------------------------

  [I-D.ietf-pce-stateful-pce]
              Crabbe, E., Medved, J., Minei, I., and R. Varga, "PCEP
              Extensions for Stateful PCE",
              draft-ietf-pce-stateful-pce, work in progress.
              Note as per [RFC4897]
                This reference is to a target document that is not yet
                published as an RFC.  Readers should exercise caution
                since the referenced document might be less stable than
                this document, however the essential description of the
                stateful PCE is considered t be stable at this time.

[Note to RFC Editor: Per RFC 4897, publication of this document does not
need to be held pending the availability of this reference as an RFC.
Please remove this note before publication.]

---------------------------

Methinks you misunderestimate RFC 4987: it is talking about citing a published RFC that's at a lower level of maturity than the source document (see Section 5 of 4987).  It does *not* cover normative references to Internet drafts, nor should it.  This document will have to wait in the RFC Editor queue until the stateful-pce document is ready, and the above notes should be removed.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-pce-questions-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Unanswered Questions in the Path Computation Element Architecture) to Informational RFC


The IESG has received a request from the Path Computation Element WG
(pce) to consider the following document:
- 'Unanswered Questions in the Path Computation Element Architecture'
  as 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 2014-07-01. 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.

Abstract


  The Path Computation Element (PCE) architecture is set out in RFC
  4655. The architecture is extended for multi-layer networking with
  the introduction of the Virtual Network Topology Manager (VNTM) in
  RFC 5623, and generalized to Hierarchical PCE (H-PCE) in RFC 6805.

  These three architectural views of PCE deliberately leave some key
  questions unanswered especially with respect to the interactions
  between architectural components.  This document draws out those
  questions and discusses them in an architectural context with
  reference to other architectural components, existing protocols, and
  recent IETF work efforts.

  This document does not update the architecture documents and does not
  define how protocols or components must be used.  It does, however,
  suggest how the architectural components might be combined to provide
  advanced PCE function.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pce-questions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pce-questions/ballot/


No IPR declarations have been submitted directly on this I-D.