Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)
draft-ietf-mpls-ldp-applicability-label-adv-03
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-10-03
|
03 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-08-18
|
03 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-08-13
|
03 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-07-22
|
03 | (System) | RFC Editor state changed to EDIT from MISSREF |
2014-05-01
|
03 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-04-30
|
03 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-04-29
|
03 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-04-29
|
03 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-04-28
|
03 | (System) | RFC Editor state changed to MISSREF |
2014-04-28
|
03 | (System) | Announcement was received by RFC Editor |
2014-04-28
|
03 | (System) | IANA Action state changed to In Progress |
2014-04-28
|
03 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-04-28
|
03 | Cindy Morgan | IESG has approved the document |
2014-04-28
|
03 | Cindy Morgan | Closed "Approve" ballot |
2014-04-24
|
03 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2014-04-24
|
03 | Adrian Farrel | Ballot approval text was generated |
2014-04-24
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-04-23
|
03 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-04-23
|
03 | Adrian Farrel | Ballot writeup was changed |
2014-04-23
|
03 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-04-23
|
03 | Dan Romascanu | Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu. |
2014-04-23
|
03 | Ted Lemon | [Ballot comment] FEC should be expanded on first use. Otherwise, this document looks fine to my untrained eye. :) |
2014-04-23
|
03 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-04-23
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-04-23
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-04-22
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-04-22
|
03 | Benoît Claise | [Ballot comment] This document updates [RFC5036] to make that fact clear, as well as updates [RFC3212], [RFC4447], … [Ballot comment] This document updates [RFC5036] to make that fact clear, as well as updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to indicate Hopefully, the RFC editor will expand those RFCs into their respective titles, to improve readability. Sorry, I don't know by heart the LDP-related RFC numbers :-) Note: no need to reply to this comment. |
2014-04-22
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-04-21
|
03 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-04-21
|
03 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-04-18
|
03 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-04-18
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Wicinski. |
2014-04-17
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-04-16
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2014-04-16
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Dan Romascanu |
2014-04-15
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-04-15
|
03 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2014-04-14
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2014-04-11
|
03 | Adrian Farrel | Ballot has been issued |
2014-04-11
|
03 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-04-11
|
03 | Adrian Farrel | Created "Approve" ballot |
2014-04-11
|
03 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2014-04-11
|
03 | Adrian Farrel | Placed on agenda for telechat - 2014-04-24 |
2014-04-11
|
03 | Adrian Farrel | (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? … (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? The MPLS working group request that: Applicability of LDP Label Advertisement Mode draft-ietf-mpls-ldp-applicability-label-adv-01.txt is published as an RFC on the Standards Track. This document updates the behavior of two standard tracks RFCs and therefore needs to be on the 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 An LDP speaker negotiates the label advertisement mode with its LDP peer at the time of session establishment. Although different applications sharing the same LDP session may need different modes of label distribution and advertisement, there is only one type of label advertisement mode that is negotiated and used per LDP session. This document clarifies the use and the applicability of session's negotiated label advertisement mode, and categorizes LDP applications into two broad categories of negotiated mode-bound and mode-independent applications. The document updates RFC5036 and RFC4447 to remove any ambiguity and conflict in the area of using correct label advertisement mode for a given application. 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? There is a strong support for this document in the working group and it has been has been well reviewed. 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? We do not know any implementations, but a poll has been sent to the working groups requesting information. The write-up will be updated as soon as we have this information. Update of the Shepherd Write-up 2014-01-29 The AD evaluation and the following discussion between the AD, shepherd, document authors and the working group chairs resulted in changes to the document of such a scope that it was agreed to do a short working group last call to give the working group a chance to evalaute the changes. This short working group last call ended 2014-01-29, The only comment we had support that we progress the document with the changes introduced during the AD evaluation. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document shepherd. Adrian Farrel is/will be the responsible AD. (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 document shepherd have reviewed the document when the document poll to become a working group document and again before before working group last call. The document shepherd believes it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. (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. No such concerns! (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. There are no IPR claims filed against this document. Before the working group last call started the working group chairs sent a mail to the working group and the authors, asking any members of the working group whom were aware of IPRs to speak up and requiring the authors either to indicate if they were aware of IPRs or say that they were not. Three out of four authors have said that they are not aware of any IPR claims. The fourth author (Luca Martini) has told the shepherd in a unidirectional mail that he is not aware of an IPR claims on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR claims filed against this document. (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 working group is behind this document. It has been well discussed and reviewed. (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.) No such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are 2 warnings on pre-RFC5378 work (since the document updates RFC5036 and RFC4447), however thers is no direct duplica of text from the documents so it is the shepherd opinion that the disclaimer is not needed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no such formal review criteria. (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? All normative references are to existing RFCs. (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. No downward references. (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. No changes to existing RFCs with respect to status. (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). IANA is requested to add a column to an existing registry to track how the codepoints are used (as described in this document). That work has led to a long discussion with IANA during IETF last call and that discussion revealed some bugs in the FCFS part of the registry that have now been fixed and correlated back into this draft. (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. No new IANA 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. No formal language. |
2014-04-11
|
03 | Adrian Farrel | Ballot approval text was generated |
2014-04-11
|
03 | Adrian Farrel | Ballot writeup was changed |
2014-04-11
|
03 | Adrian Farrel | Ballot writeup was changed |
2014-04-02
|
03 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-04-02
|
03 | Kamran Raza | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2014-04-02
|
03 | Kamran Raza | New version available: draft-ietf-mpls-ldp-applicability-label-adv-03.txt |
2014-03-13
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Magnus Nystrom. |
2014-03-09
|
02 | Adrian Farrel | New revision needed to address IANA issues |
2014-03-09
|
02 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2014-03-09
|
02 | Adrian Farrel | Changed consensus to Yes from Unknown |
2014-02-24
|
02 | Dan Romascanu | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu. |
2014-02-24
|
02 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-02-20
|
02 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2014-02-20
|
02 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-ldp-applicability-label-adv-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-mpls-ldp-applicability-label-adv-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has questions about the actions requested in the IANA Considerations section of this document. IANA understands that, upon approval of this document, there is a single action which IANA needs to complete. IANA understands that it is the intent of this document to update the "Forwarding Equivalence Class (FEC) Type Name Space" registry under the "Label Distribution Protocol (LDP) Parameters" registry located at: http://www.iana.org/assignments/ldp-namespaces/ IANA further understands that it is the intent of the document to update the existing registry by adding a new column titled "Label advertisement discipline" to the existing registry. In section 2.2 of the current document the authors provide a table of label advertisement disciplines to be used for currently defined LDP FEC types. IANA Question: Is the new "Label advertisement discipline" column optional? IN another word, should the value "Not applicable" must be used for a (new) registration that has not defined the "Label advertisement discipline"? IANA Question --> the table in section 2.2 does not appear to cover all of the existing LDP FEC types that appears to be assigned after this version draft-ietf-mpls-ldp-applicability-label-adv-02 was published (2014-01-20). For instance, FEC types 0x09 and ox10 are not available in the table provided in Section 2.2. In addition, it appears that some FEC types have been the subject of early assignment in this registry. How do the authors intend to provide values for the new "Label advertisement discipline" column for those registrations? IANA Question --> in section 2.2 the authors state "The above table also lists the RFC (in which given FEC type is defined), and hence this document updates all the above listed RFCs." Does this mean that in the updated registry, [RFC-to-be ] should replace the listed RFCs as the reference for the associated registrations? IANA understands that the update to the registry, "Forwarding Equivalence Class (FEC) Type Name Space" under the "Label Distribution Protocol (LDP) Parameters" registry located at: http://www.iana.org/assignments/ldp-namespaces/ is the only action 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 only to confirm what actions will be performed. |
2014-02-17
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2014-02-17
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Wicinski |
2014-02-13
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2014-02-13
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to Dan Romascanu |
2014-02-13
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2014-02-13
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Magnus Nystrom |
2014-02-10
|
02 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-02-10
|
02 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Label Advertisement Discipline for LDP … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Label Advertisement Discipline for LDP FECs) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Label Advertisement Discipline for LDP FECs' 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 2014-02-24. 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 label advertising behavior of an LDP speaker for a given FEC is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC 5918, and RFC 6388 by specifying the label advertisement mode for all currently defined FECs. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-adv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-applicability-label-adv/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-02-10
|
02 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-02-09
|
02 | Adrian Farrel | Last call was requested |
2014-02-09
|
02 | Adrian Farrel | Ballot approval text was generated |
2014-02-09
|
02 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation |
2014-02-09
|
02 | Adrian Farrel | Last call announcement was changed |
2014-02-09
|
02 | Adrian Farrel | Last call announcement was generated |
2014-02-09
|
02 | Adrian Farrel | Last call announcement was generated |
2014-02-09
|
02 | Adrian Farrel | Ballot writeup was changed |
2014-01-29
|
02 | Adrian Farrel | Re-entering AD Evaluation for latest version of the document |
2014-01-29
|
02 | Adrian Farrel | State changed to AD Evaluation from AD Evaluation::External Party |
2014-01-28
|
02 | Loa Andersson | (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? … (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? The MPLS working group request that: Applicability of LDP Label Advertisement Mode draft-ietf-mpls-ldp-applicability-label-adv-01.txt is published as an RFC on the Standards Track. This document updates the behavior of two standard tracks RFCs and therefore needs to be on the 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 An LDP speaker negotiates the label advertisement mode with its LDP peer at the time of session establishment. Although different applications sharing the same LDP session may need different modes of label distribution and advertisement, there is only one type of label advertisement mode that is negotiated and used per LDP session. This document clarifies the use and the applicability of session's negotiated label advertisement mode, and categorizes LDP applications into two broad categories of negotiated mode-bound and mode-independent applications. The document updates RFC5036 and RFC4447 to remove any ambiguity and conflict in the area of using correct label advertisement mode for a given application. 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? There is a strong support for this document in the working group and it has been has been well reviewed. 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? We do not know any implementations, but a poll has been sent to the working groups requesting information. The write-up will be updated as soon as we have this information. Update of the Shepherd Write-up 2014-01-29 The AD evaluation and the following discussion between the AD, shepherd, document authors and the working group chairs resulted in changes to the document of such a scope that it was agreed to do a short working group last call to give the working group a chance to evalaute the changes. This short working group last call ended 2014-01-29, The only comment we had support that we progress the document with the changes introduced during the AD evaluation. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document shepherd. Adrian Farrel is/will be the responsible AD. (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 document shepherd have reviewed the document when the document poll to become a working group document and again before before working group last call. The document shepherd believes it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. (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. No such concerns! (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. There are no IPR claims filed against this document. Before the working group last call started the working group chairs sent a mail to the working group and the authors, asking any members of the working group whom were aware of IPRs to speak up and requiring the authors either to indicate if they were aware of IPRs or say that they were not. Three out of four authors have said that they are not aware of any IPR claims. The fourth author (Luca Martini) has told the shepherd in a unidirectional mail that he is not aware of an IPR claims on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR claims filed against this document. (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 working group is behind this document. It has been well discussed and reviewed. (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.) No such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are 2 warnings on pre-RFC5378 work (since the document updates RFC5036 and RFC4447), however thers is no direct duplica of text from the documents so it is the shepherd opinion that the disclaimer is not needed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no such formal review criteria. (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? All normative references are to existing RFCs. (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. No downward references. (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. No changes to existing RFCs with respect to status. (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). No IANA allocation requested. (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. No new IANA 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. No formal language. |
2014-01-21
|
02 | Adrian Farrel | Further working group last call being held |
2014-01-21
|
02 | Adrian Farrel | State changed to AD Evaluation::External Party from AD Evaluation::AD Followup |
2014-01-20
|
02 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-01-20
|
02 | Kamran Raza | New version available: draft-ietf-mpls-ldp-applicability-label-adv-02.txt |
2013-09-04
|
01 | Adrian Farrel | Early AD-review discussions with the authors indicate that significant revision is needed. |
2013-09-04
|
01 | Adrian Farrel | State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::Point Raised - writeup needed |
2013-08-21
|
01 | Adrian Farrel | In discussion with document authors |
2013-08-21
|
01 | Adrian Farrel | State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation |
2013-08-18
|
01 | Adrian Farrel | Ballot writeup was changed |
2013-08-18
|
01 | Adrian Farrel | Ballot writeup was generated |
2013-08-18
|
01 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2013-07-10
|
01 | Cindy Morgan | (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? … (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? The MPLS working group request that: Applicability of LDP Label Advertisement Mode draft-ietf-mpls-ldp-applicability-label-adv-01.txt is published as an RFC on the Standards Track. This document updates the behavior of two standard tracks RFCs and therefore needs to be on the 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 An LDP speaker negotiates the label advertisement mode with its LDP peer at the time of session establishment. Although different applications sharing the same LDP session may need different modes of label distribution and advertisement, there is only one type of label advertisement mode that is negotiated and used per LDP session. This document clarifies the use and the applicability of session's negotiated label advertisement mode, and categorizes LDP applications into two broad categories of negotiated mode-bound and mode-independent applications. The document updates RFC5036 and RFC4447 to remove any ambiguity and conflict in the area of using correct label advertisement mode for a given application. 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? There is a strong support for this document in the working group and it has been has been well reviewed. 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? We do not know any implementations, but a poll has been sent to the working groups requesting information. The write-up will be updated as soon as we have this information. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Loa Andersson is the document shepherd. Adrian Farrel is/will be the responsible AD. (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 document shepherd have reviewed the document when the document poll to become a working group document and again before before working group last call. The document shepherd believes it is ready for publication. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. (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. No such concerns! (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. There are no IPR claims filed against this document. Before the working group last call started the working group chairs sent a mail to the working group and the authors, asking any members of the working group whom were aware of IPRs to speak up and requiring the authors either to indicate if they were aware of IPRs or say that they were not. Three out of four authors have said that they are not aware of any IPR claims. The fourth author (Luca Martini) has told the shepherd in a unidirectional mail that he is not aware of an IPR claims on this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR claims filed against this document. (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 working group is behind this document. It has been well discussed and reviewed. (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.) No such threats. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are 2 warnings on pre-RFC5378 work (since the document updates RFC5036 and RFC4447), however thers is no direct duplica of text from the documents so it is the shepherd opinion that the disclaimer is not needed. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no such formal review criteria. (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? All normative references are to existing RFCs. (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. No downward references. (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. No changes to existing RFCs with respect to status. (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). No IANA allocation requested. (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. No new IANA 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. No formal language. |
2013-07-10
|
01 | Cindy Morgan | Intended Status changed to Proposed Standard |
2013-07-10
|
01 | Cindy Morgan | IESG process started in state Publication Requested |
2013-07-10
|
01 | (System) | Earlier history may be found in the Comment Log for draft-raza-mpls-ldp-applicability-label-adv |
2013-07-10
|
01 | Cindy Morgan | Document shepherd changed to Loa Andersson |
2013-07-10
|
01 | Loa Andersson | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2013-07-10
|
01 | Loa Andersson | Changed document writeup |
2013-03-21
|
01 | Loa Andersson | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2013-03-21
|
01 | Loa Andersson | Annotation tag Other - see Comment Log set. |
2013-03-21
|
01 | Loa Andersson | IETF WG state changed to In WG Last Call from WG Document |
2013-02-14
|
01 | Loa Andersson | IPR poll issued. |
2013-02-14
|
01 | Loa Andersson | WG Last Call has ended, we only had supportive comments :)! |
2013-02-14
|
01 | Kamran Raza | New version available: draft-ietf-mpls-ldp-applicability-label-adv-01.txt |
2012-08-08
|
00 | Kamran Raza | New version available: draft-ietf-mpls-ldp-applicability-label-adv-00.txt |