Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)
draft-ietf-pce-association-group-10

[Ballot comment]
I'm always a little reluctant to publish framework documents without any
examples of using that framework (i.e., this document does not define
any association types), but this work seems well thought-out and it
looks like there are a handful of association types in development by
the WG.  Would it be worth listing a few as informational references to
give the reader a broader sense of what associations might be used for?

Thanks for the note in the shepherd writeup about the author count!

Thank you also for the very readable document -- it's clear that the
authors took care to organize the content in a manner accessible to
the reader.

As a general note, do we need to say anything about the multi-byte
integer values being encoded in network byte order?  (Perhaps following
RFC 5440's implicit convention is the right thing to do.)

Section 1

  [RFC6780] defines the RSVP ASSOCIATION object, which was defined in
  the context of GMPLS-controlled Label Switched Paths (LSPs) to be

nit: is this supposed to be  RFC 4872?

Section 3.3

  The dynamically created association can be reported to the PCEP peer
  via the PCEP messages as per the stateful extensions.  While the
  operator-configured association is known to the PCEP peer before
  hand, a PCEP peer could ask for a LSP to join the operator-configured
  association via the stateful PCEP messages.

nit: I suggest s/While/When/, if I understand correctly.

  Multiple types of associations can exist, each with their own
  association identifier space.  The definition of the different
  association types and their behaviours is outside the scope of this
  document.  The establishment and removal of the association
  relationship can be done on a per LSP basis.  An LSP may join
  multiple association groups, of different or of the same association
  type.

Is it possible for an LSP to join multiple association groups of the
same type and then for configuration to be assigned to two groups in a
manner that conflicts?  What procedure is used for conflict resolution
in such a case?

Section 3.4

  Association identifier range for sources other than the PCEP speaker
  (for example an NMS system) is not communicated in PCEP and the
  procedure for operator-configured association range setting is
  outside the scope of this document.

Given the discussion in the rest of the document, it seems that
reserving a specific range for operator configuration (across all
association types) is too rigid to meet the various anticipated use
cases.  Is that a correct assessment?

Section 5.1

  If the Assoc-type is not recognized or supported by the PCEP speaker,
  it MUST ignore that respective Start-Assoc-ID and Range.  If the
  Start-Assoc-ID or Range are set incorrectly, the PCEP session MUST be
  rejected with error type 1 and error value 1 (PCEP session
  establishment failure / Reception of an invalid Open message).

I could maybe see competent engineers disagreeing about which of these
MUSTs would take precedence in a case where both apply.

  The Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE
  TLV in the case of a non-contiguous Operator-configured Association
  Range.  The PCEP speaker originating this TLV MUST NOT carry
  overlapping ranges for an association type.  If a PCEP peer receives
  overlapping ranges for an association type, it MUST consider the Open
  message malformed and MUST reject the PCEP session with error type 1
  and error value 1 (PCEP session establishment failure / Reception of
  an invalid Open message).

This might be a good place to specify the  handling if a
received range would cross the 0xffff boundary.

Section 6.1.1

  The Global Association Source TLV is an optional TLV for use in the
  Association Object.  The meaning and the usage of Global Association
  Source is as per [RFC6780].

Do we want to say Section 4 specifically of 6780?
(Similarly for Extended Association ID.)

Section 6.1.4

  the association group.  In this document, all these fields are called
  'association parameters'.  Note that the ASSOCIATION object MAY

I would humbly suggest s/all these fields are called 'association
parameters'/these fields are collectively called 'association
parameters'/.

Section 6.3.1

  The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path
  Computation Update (PCUpd), Path Computation Report (PCRpt) and Path
  Computation Initiate (PCInitiate) messages.

  When carried in PCRpt message, it is used to report the association
  group membership pertaining to a LSP to a stateful PCE.  The PCRpt
  message are used for both initial state synchronization operations
  (Section 5.6 of [RFC8231]) as well as whenever the state of the LSP
  changes.  The associations MUST be included during the state
  synchronization operations.

I suspect this is just my hazy memory of OPTIONAL, but how does "MUST be
included" match up with "OPTIONAL".

Section 6.4

Do I understand correctly that for dynamically created association
groups, the creation is effected by just using the relevant parameters
in a request(/update/etc.) and there is no need to separately create or
allocate the association?

  If a PCE peer is unwilling or unable to process the ASSOCIATION
  object, it MUST return a PCErr message with the Error-Type "Not
  supported object" and follow the relevant procedures described in
  [RFC5440].  [...]

Does this imply that the P flag in the common header should always be
set for ASSOCIATION objects?

  In case the LSP is delegated to another PCE on session failure, the
  associations (and association information) set by the PCE remains
  intact, unless updated by the new PCE that takes over.

This includes the association source address?

Section 8

  attack vector.  An attacker could report too many associations in an
  attempt to load the PCEP peer.  The PCEP peer responds with PCErr as

"report" in the sense of causing the peer to create state to track them?

Section 12.2

Since the RFC 7525 procedures are RECOMMENDED, I think that reference
needs to be normative.

[Ballot comment]
* Section 6.1.

  Association Source: 4 or 16 bytes - A valid IPv4 or IPv6 address that
  provides scoping for the Association ID.  See Section 6.1.3 for
  details.

If I understand correctly, the length of this field is not really 4 or 16 bytes but rather fully dependent on the ASSOCIATION Object-Type. i.e. you cannot have a 16 byte address here if the Object_Type is 1. If so, it would be good to state this dependence explicitly. Suggest something like

  Association Source: Contains a valid IPv4 address (4 bytes) if  the ASSOCIATION
  Object-Type is 1 or a valid IPv6 address (16 bytes) if  the ASSOCIATION
  Object-Type is 2. It provides scoping for the Association ID.  See Section 6.1.3 for details.

[Ballot comment]
A tiny thing, trivial to fix, and Dhruv has already put it in his working copy:

— Section 2 —

  This document uses the following terms defined in [RFC8051]: Stateful
  PCE, Active Stateful PCE, Passive Stateful PCE, and Delegation.

I think this makes 8051 a normative reference.

[Ballot comment]
Thank you  for the work put into this document. I have two COMMENTs and one nits: all easy to fix

Regards,

-éric

== COMMENTS ==

-- Section 6.1 --

Please state the obvious: unused "Flags" bits MUST be set to 0.

-- Section 6.1.1 --

Figure 5 includes the type and length of the TLV while figure 1 in previous section does not include the type and length field. Or am I misreading the figures ?

== NITS ==

-- Section 4.1 (and others) --

The caption of figure 1 contains "TLV" but it is actually only about the "V" of the "TLV" ;-) See above COMMENT

[Ballot discuss]
A tiny thing, trivial to fix:

— Section 2 —

  This document uses the following terms defined in [RFC8051]: Stateful
  PCE, Active Stateful PCE, Passive Stateful PCE, and Delegation.

I think this makes 8051 a normative reference.

[Ballot comment]
Hi,

thanks for this document, here are a couple of comments/questions.

  The PCEP ASSOC-Type-List TLV is optional.  It MAY be carried within
  an OPEN object sent by a PCEP speaker in an Open message to a PCEP
  peer so as to indicate the list of supported Association types.
This is said twice. (First paragraph of section 4.1) and then in 4.1.1:
  A PCEP speaker MAY include an ASSOC-Type-List TLV within an OPEN
  object in an Open message sent to a PCEP peer in order to advertise a
  set of one or more supported association types.
  The use of ASSOC-Type-List TLV is OPTIONAL.

It doesn't hurt, but you might want to consider saying this only once. Also I note OPTIONAL vs optional

Sending ASSOC-Type-List TLV is optional but it might be mandatory to send some to-be-defined Association types. Isn't that somehow conflicting?

The PCEP OP-CONF-ASSOC-RANGE TLV is optional.
OPTIONAL?

Could you clarify the difference between
a PCEP speaker does not recognize the ASSOCIATION object
and
a PCE peer is ... unable to process the ASSOCIATION
I see that the errors thrown are different.


Nits:
s/protections LSPs/protection LSPs/
s/The Assoc-type MAY appear more than once/A given Assoc-type MAY appear more than once/
s/to uniquely identifying/to uniquely identify/

[Ballot comment]
(1) s/before hand/beforehand/g

(2) §5: "Start-Assoc-ID...The values 0 and 0xffff MUST NOT be used."  What should the receiver do if they are?

(3) §5: "Range...it MUST be such that (Start-Assoc-ID + Range) do not cross the association identifier range of 0xffff."  What should the receiver do if it does?

(4) s/is OPTIONAL and MAY/MAY/g  OPTIONAL = MAY

(5) §9.2: "An implementation SHOULD allow...Further implementation SHOULD allow... To serve this purpose, the PCEP YANG module [I-D.ietf-pce-pcep-yang] includes association groups."  If I-D.ietf-pce-pcep-yang is the mechanism that addresses these Normative statements, then it should be a Normative reference.  I think that it is not necessary to point at I-D.ietf-pce-pcep-yang in this document.

(6) RFC8126 should be a Normative reference.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
- Proposed Standard
- It defines protocol extensions.
- The header says "Standards Track".

(2) 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

  This document introduces a generic mechanism to create a grouping of
  Label Switched Paths (LSPs) in the context of a Path Computation
  Element (PCE).  This grouping can then be used to define associations
  between sets of LSPs or between a set of LSPs and a set of attributes
  (such as configuration parameters or behaviors), and is equally
  applicable to the stateful PCE (active and passive modes) as well as
  the stateless PCE.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
- The document has consensus and defines the base specification for upcoming protocol extensions.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
- Several vendors are co-authors of this document as well as the subsequent ones. Some of them explicitly confirmed it was implemented. Early codepoint allocation was triggered because of implementations requirements.

Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
- N/A

If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
- N/A

Personnel

  Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
- The shepherd's review led to some updates for clarification and nit fix, no particular technical issue to mention.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
- No concern

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
- N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.
- N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
- Yes (cf. document's history in the datatracker)

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
- No

(9) 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 agrees as a whole. Three WG I-Ds already depends on this one, not to mention individual proposals.
- The author list is quite diverse and very representative of the support (vendors, operators); we believe that having 6 names on the front page instead of the recommended 5 is legitimate due to the background work to agree on a common base mechanism for several features (upcoming I-Ds).

(10) 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 publicly available.)
- N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
- Done

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
- N/A

(13) Have all references within this document been identified as
either normative or informative?
- Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
- N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
- N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
- N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
- OK

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
- Only Standards Action is considered.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
- N/A

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
- Proposed Standard
- It defines protocol extensions.
- The header says "Standards Track".

(2) 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

  This document introduces a generic mechanism to create a grouping of
  Label Switched Paths (LSPs) in the context of a Path Computation
  Element (PCE).  This grouping can then be used to define associations
  between sets of LSPs or between a set of LSPs and a set of attributes
  (such as configuration parameters or behaviors), and is equally
  applicable to the stateful PCE (active and passive modes) as well as
  the stateless PCE.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
- The document has consensus and defines the base specification for upcoming protocol extensions.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
- Several vendors are co-authors of this document as well as the subsequent ones. Some of them explicitly confirmed it was implemented. Early codepoint allocation was triggered because of implementations requirements.

Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
- N/A

If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
- N/A

Personnel

  Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
- The shepherd's review led to some updates for clarification and nit fix, no particular technical issue to mention.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
- No concern

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
- N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.
- N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
- Yes (cf. document's history in the datatracker)

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
- No

(9) 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 agrees as a whole. Three WG I-Ds already depends on this one, not to mention individual proposals.
- The author list is quite diverse and very representative of the support (vendors, operators); we believe that having 6 names instead of the recommended 5 is legitimate due to the background work to agree on a common base mechanism for several features (upcoming I-Ds).

(10) 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 publicly available.)
- N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
- Done

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
- N/A

(13) Have all references within this document been identified as
either normative or informative?
- Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
- N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
- N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
- N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
- OK

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
- Only Standards Action is considered.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
- N/A

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-pce-association-group-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are sixth actions which we must complete.

First, in the PCEP Objects registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

http://www.iana.org/assignments/pcep/

The following early allocation will be made permanent and its registration changed to [ RFC-to-be ]:

Object-Class Value Name Reference

40 ASSOCIATION [ RFC-to-be ]
0: Reserved
1: IPv4
2: IPv6

Second, in the PCEP TLV Type Indicators registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

http://www.iana.org/assignments/pcep/

The following early allocations will be made permanent and their registrations changed to [ RFC-to-be ], and we'll update the meaning for value 31:

Value Meaning Reference
29 Operator-configured Association Range [ RFC-to-be ]
30 Global Association Source [ RFC-to-be ]
31 Extended Association ID [ RFC-to-be ]

Third, also in the PCEP TLV Type Indicators registry on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

http://www.iana.org/assignments/pcep/

a single, new registration will be made as follows:

Value: TBD
Description: ASSOC-Type-List
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the ASSOCIATION Flags Field. The new registry will be located on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

http://www.iana.org/assignments/pcep/

The new registry will be managed via Standards Action as defined in RFC 8126. There is a single new registration in the registry as follows:

Bit Description Reference
-------+-------------------------+-------------
0-14 Unassigned
15 R (Removal) [ RFC-to-be ]

Fifth, a new registry is to be created called the ASSOCIATION Type Field. The new registry will be located on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

http://www.iana.org/assignments/pcep/

The new registry will be managed via Standards Action as defined in RFC 8126. There are no initial registrations in the new registry. Each registration in the new registry will have Type, Name and Reference fields.

Sixth, in the PCEP-ERROR Object Error Types and Values registry also on the Path Computation Element Protocol (PCEP) Numbers registry page located at:

http://www.iana.org/assignments/pcep/

The following early allocation will be made permanent and its registration changed to [ RFC-to-be ]:

Error
Type Meaning Reference
------+------------------------------------+-----------
26 Association Error [ RFC-to-be ]
Error-value=0:
Unassigned
Error-value=1:
Association type is not supported
Error-value=2:
Too many LSPs in the association group
Error-value=3:
Too many association groups
Error-value=4:
Association unknown
Error-value=5:
Operator-configured association
information mismatch
Error-value=6:
Association information mismatch
Error-value=7:
Cannot join the association group
Error-value=8:
Association identifier not in range

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-06-06):

From: The IESG
To: IETF-Announce
CC: Julien Meuric , db3546@att.com, pce@ietf.org, pce-chairs@ietf.org, draft-ietf-pce-association-group@ietf.org, julien.meuric@orange.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PCEP Extensions for Establishing Relationships Between Sets of LSPs) to Proposed Standard


The IESG has received a request from the Path Computation Element WG (pce) to
consider the following document: - 'PCEP Extensions for Establishing
Relationships Between Sets of LSPs'
  as Proposed Standard

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 2019-06-06. 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


  This document introduces a generic mechanism to create a grouping of
  Label Switched Paths (LSPs) in the context of a Path Computation
  Element (PCE).  This grouping can then be used to define associations
  between sets of LSPs or between a set of LSPs and a set of attributes
  (such as configuration parameters or behaviors), and is equally
  applicable to the stateful PCE (active and passive modes) as well as
  the stateless PCE.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-pce-association-group/ballot/


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

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
- Proposed Standard
- It defines protocol extensions.
- The header says "Standards Track".

(2) 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

  This document introduces a generic mechanism to create a grouping of
  Label Switched Paths (LSPs) in the context of a Path Computation
  Element (PCE).  This grouping can then be used to define associations
  between sets of LSPs or between a set of LSPs and a set of attributes
  (such as configuration parameters or behaviors), and is equally
  applicable to the stateful PCE (active and passive modes) as well as
  the stateless PCE.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
- The document has consensus and defines the base specification for upcoming protocol extensions.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
- Several vendors are co-authors of this document as well as the subsequent ones. Some of them explicitly confirmed it was implemented. Early codepoint allocation was triggered because of implementations requirements.

Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
- N/A

If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
- N/A

Personnel

  Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
- The shepherd's review led to some updates for clarification and nit fix, no particular technical issue to mention.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
- No concern

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
- N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.
- N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
- Yes (cf. document's history in the datatracker)

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
- No

(9) 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 agrees as a whole. Three WG I-Ds already depends on this one, not to mention individual proposals.

(10) 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 publicly available.)
- N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
- Done

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
- N/A

(13) Have all references within this document been identified as
either normative or informative?
- Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
- N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
- N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
- N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
- OK

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
- Only Standards Action is considered.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
- N/A

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
- Proposed Standard

(2) 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

  This document introduces a generic mechanism to create a grouping of
  Label Switched Paths (LSPs) in the context of a Path Computation
  Element (PCE).  This grouping can then be used to define associations
  between sets of LSPs or between a set of LSPs and a set of attributes
  (such as configuration parameters or behaviors), and is equally
  applicable to the stateful PCE (active and passive modes) as well as
  the stateless PCE.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
- The document has consensus and defines the base specification for upcoming protocol extensions.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
- Several vendors are co-authors of this document as well as the subsequent ones. Some of them explicitly confirmed it was implemented. Early codepoint allocation was triggered because of implementations requirements.

Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
- N/A

If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
- N/A

Personnel

  Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
- The shepherd's review led to some updates for clarification and nit fix, no particular technical issue to mention.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
- No concern

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
- N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.
- N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
- Yes (cf. document's history in the datatracker)

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
- No

(9) 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 agrees as a whole. Three WG I-Ds already depends on this one, not to mention individual proposals.

(10) 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 publicly available.)
- N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
- Done

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
- N/A

(13) Have all references within this document been identified as
either normative or informative?
- Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
- N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
- N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
- N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
- OK

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
- Only Standards Action is considered.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
- N/A

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
- Proposed Standard

(2) 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

  This document introduces a generic mechanism to create a grouping of
  Label Switched Paths (LSPs) in the context of a Path Computation
  Element (PCE).  This grouping can then be used to define associations
  between sets of LSPs or between a set of LSPs and a set of attributes
  (such as configuration parameters or behaviors), and is equally
  applicable to the stateful PCE (active and passive modes) as well as
  the stateless PCE.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
- The document has consensus and defines the base specification for upcoming protocol extensions.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
- Several vendors are co-authors of this document as well as the subsequent ones. Some of them explicitly confirmed it was implemented. Early codepoint allocation was triggered because of implementations requirements.

Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?
- N/A

If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
- N/A

Personnel

  Who is the Document Shepherd?
- Julien Meuric

Who is the Responsible Area Director?
- Deborah Brungard

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
- The shepherd's review led to some updates for clarification and nit fix, no particular technical issue to mention.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
- No concern

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
- N/A

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.
- N/A

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
- Yes (cf. document's history in the datatracker)

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
- No

(9) 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 agrees as a whole. Three WG I-Ds already depends on this one, not to mention individual proposals.

(10) 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 publicly available.)
- N/A

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
- Done

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
- N/A

(13) Have all references within this document been identified as
either normative or informative?
- Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
- N/A

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
- N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
- N/A

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
- OK

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
- Only Standards Action is considered.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
- N/A

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Proposed Standard

(2) 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

  This document introduces a generic mechanism to create a grouping of
  Label Switched Paths (LSPs) in the context of a Path Computation
  Element (PCE).  This grouping can then be used to define associations
  between sets of LSPs or between a set of LSPs and a set of attributes
  (such as configuration parameters or behaviors), and is equally
  applicable to the stateful PCE (active and passive modes) as well as
  the stateless PCE.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
The document has consensus and defines the base specification for upcoming protocol extensions.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) 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? 

(10) 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 publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative or informative?

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Request for posting confirmation emailed to previous authors: Edward Crabbe , Hariharan Ananthakrishnan , Siva Sivabalan , Dhruv Dhody , Ina Minei , pce-chairs@ietf.org, Yosuke Tanaka

Request for posting confirmation emailed to previous authors: Edward Crabbe , Hariharan Ananthakrishnan , Siva Sivabalan , Xian Zhang , Ina Minei , pce-chairs@ietf.org, Yosuke Tanaka