Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field
draft-ietf-mpls-cosfield-def-08
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2020-01-21
|
08 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
|
2018-12-20
|
08 | (System) | Received changes through RFC Editor sync (changed abstract to 'The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. … Received changes through RFC Editor sync (changed abstract to 'The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]') |
|
2017-05-16
|
08 | (System) | Changed document authors from "Loa Andersson" to "Loa Andersson, Rajiv Asati" |
|
2015-10-14
|
08 | (System) | Notify list changed from mpls-chairs@ietf.org, draft-ietf-mpls-cosfield-def@ietf.org to (None) |
|
2009-03-18
|
08 | (System) | IANA Action state changed to No IC from In Progress |
|
2009-02-25
|
08 | Cindy Morgan | State Changes to RFC Published from RFC Ed Queue by Cindy Morgan |
|
2009-02-25
|
08 | Cindy Morgan | [Note]: 'RFC 5462' added by Cindy Morgan |
|
2009-02-25
|
08 | (System) | RFC published |
|
2008-12-23
|
08 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2008-12-22
|
08 | (System) | IANA Action state changed to In Progress |
|
2008-12-22
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2008-12-22
|
08 | Amy Vezza | IESG has approved the document |
|
2008-12-22
|
08 | Amy Vezza | Closed "Approve" ballot |
|
2008-12-19
|
08 | (System) | Removed from agenda for telechat - 2008-12-18 |
|
2008-12-18
|
08 | Cindy Morgan | State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan |
|
2008-12-18
|
08 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded by Mark Townsley |
|
2008-12-18
|
08 | David Ward | [Ballot Position Update] New position, Yes, has been recorded by David Ward |
|
2008-12-17
|
08 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
|
2008-12-17
|
08 | Dan Romascanu | [Ballot Position Update] New position, Yes, has been recorded by Dan Romascanu |
|
2008-12-17
|
08 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
|
2008-12-17
|
08 | Tim Polk | [Ballot comment] Abstract s/current use of the EXP this field/current use of this field/ Section 1. Introduction s/after the work on the document were started/after … [Ballot comment] Abstract s/current use of the EXP this field/current use of this field/ Section 1. Introduction s/after the work on the document were started/after the work on the document was started/ Section 3. Use of the TC field s/have different TF fields from the rest/have different TC fields from the rest/ |
|
2008-12-17
|
08 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
|
2008-12-17
|
08 | Ron Bonica | [Ballot Position Update] New position, Yes, has been recorded by Ron Bonica |
|
2008-12-17
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
|
2008-12-16
|
08 | Lars Eggert | [Ballot comment] Section 1.2, paragraph 7: > The EXP field has been renamed to the TC field, and thus all > … [Ballot comment] Section 1.2, paragraph 7: > The EXP field has been renamed to the TC field, and thus all > references in RFC 3270 to EXP field SHOULD be taken to refer > to the TC field. I think the "SHOULD" here needs to be a "MUST" - otherwise it leaves the option of not using the new name. (And I don't believe an RFC2119 term is appropriate here, so it should be a lowercase "must".) Similar phrasings occur in Sections 2.3 and 2.4, and they should be changed accordingly. |
|
2008-12-16
|
08 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
|
2008-12-15
|
08 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
|
2008-12-15
|
08 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
|
2008-12-14
|
08 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
|
2008-12-06
|
08 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Radia Perlman. |
|
2008-12-05
|
08 | Ross Callon | [Ballot Position Update] New position, Yes, has been recorded for Ross Callon |
|
2008-12-05
|
08 | Ross Callon | Ballot has been issued by Ross Callon |
|
2008-12-05
|
08 | Ross Callon | Created "Approve" ballot |
|
2008-12-05
|
08 | Ross Callon | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Ross Callon |
|
2008-12-05
|
08 | Ross Callon | Placed on agenda for telechat - 2008-12-18 by Ross Callon |
|
2008-12-05
|
08 | (System) | New version available: draft-ietf-mpls-cosfield-def-08.txt |
|
2008-12-04
|
08 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
|
2008-12-01
|
08 | Amanda Baber | IANA Last Call comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2008-11-25
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Radia Perlman |
|
2008-11-25
|
08 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Radia Perlman |
|
2008-11-20
|
08 | Cindy Morgan | Last call sent |
|
2008-11-20
|
08 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
|
2008-11-20
|
08 | Ross Callon | Last Call was requested by Ross Callon |
|
2008-11-20
|
08 | (System) | Ballot writeup text was added |
|
2008-11-20
|
08 | (System) | Last call text was added |
|
2008-11-20
|
08 | (System) | Ballot approval text was added |
|
2008-11-20
|
08 | Ross Callon | State Changes to Last Call Requested from Publication Requested by Ross Callon |
|
2008-11-20
|
08 | Ross Callon | PROTO write-up by George Swallow: draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track. (1.a) Who is the Document Shepherd for this … PROTO write-up by George Swallow: draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? George Swallow is the document shepherd. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document is well reviewed it has been wg last called in the mpls, ccamp, pwe3, l2vpn and tsvwg as well as in the ITU-T ad-hoc team on mpls-tp. We have freceived a positive response from the ITU-T ad-hoc team (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? no (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. no (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? very solid (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) no (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? yes - there is four informational RFCs (RFC 3272, RFC 3469, RFC 3564 and RFC 3985) that are listed as ormative references. This is because this document makes manadatory changes to these RFCs, the working group, the working group chairs and the authors are uncertain of the correct way to handle this, but will have no problem moving these to informative referenceds by a RFC Editor note. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. the references are split into normative and informative references, however see 1.g above (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists, but there are no requests for IANA allocations. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The documents is text document written in plain ascii. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The early MPLS documents defined the form of the MPLS Label Stack entry. This include a three bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" field, it was not named the "Class of Service" (CoS) field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field".) In doing so it also updates documents that define the current use of the EXP this field. Comment: The document addresses a problem that we been aware for a long time, but that has become urgent only when we started work closely with ITU-T on MPLS-TP. At the core the document is a simple name change, but also contains some consequent updates to existing RFCs. 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? No controversies other than what name to chose for the field, at the final wg last call we had 100% backing of the choosen name . Traffic Class (TC). 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? Since this is basically a name change of one of the fields in a MPLS Label Stack entry. The question abotu implementaions are out of scope. |
|
2008-11-20
|
08 | Ross Callon | PROTO write-up by George Swallow: draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track. (1.a) Who is the Document Shepherd for this … PROTO write-up by George Swallow: draft-ietf-mpls-cosfield-def-07.txt be published as an IETF stream RFC on the Standards Track. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? George Swallow is the document shepherd. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document is well reviewed it has been wg last called in the mpls, ccamp, pwe3, l2vpn and tsvwg as well as in the ITU-T ad-hoc team on mpls-tp. We have freceived a positive response from the ITU-T ad-hoc team (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? no (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. no (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? very solid (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) no (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? yes - there is four informational RFCs (RFC 3272, RFC 3469, RFC 3564 and RFC 3985) that are listed as ormative references. This is because this document makes manadatory changes to these RFCs, the working group, the working group chairs and the authors are uncertain of the correct way to handle this, but will have no problem moving these to informative referenceds by a RFC Editor note. (1.h) Has the document split its references into normative and informative? 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 strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. the references are split into normative and informative references, however see 1.g above (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists, but there are no requests for IANA allocations. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The documents is text document written in plain ascii. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. The early MPLS documents defined the form of the MPLS Label Stack entry. This include a three bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" field, it was not named the "Class of Service" (CoS) field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field".) In doing so it also updates documents that define the current use of the EXP this field. Comment: The document addresses a problem that we been aware for a long time, but that has become urgent only when we started work closely with ITU-T on MPLS-TP. At the core the document is a simple name change, but also contains some consequent updates to existing RFCs. 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? No controversies other than what name to chose for the field, at the final wg last call we had 100% backing of the choosen name . Traffic Class (TC). 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? Since this is basically a name change of one of the fields in a MPLS Label Stack entry. The question abotu implementaions are out of scope. |
|
2008-11-20
|
08 | Ross Callon | Draft Added by Ross Callon in state Publication Requested |
|
2008-11-18
|
07 | (System) | New version available: draft-ietf-mpls-cosfield-def-07.txt |
|
2008-11-17
|
06 | (System) | New version available: draft-ietf-mpls-cosfield-def-06.txt |
|
2008-10-17
|
05 | (System) | New version available: draft-ietf-mpls-cosfield-def-05.txt |
|
2008-07-07
|
04 | (System) | New version available: draft-ietf-mpls-cosfield-def-04.txt |
|
2008-07-04
|
03 | (System) | New version available: draft-ietf-mpls-cosfield-def-03.txt |
|
2008-06-11
|
02 | (System) | New version available: draft-ietf-mpls-cosfield-def-02.txt |
|
2008-06-04
|
01 | (System) | New version available: draft-ietf-mpls-cosfield-def-01.txt |
|
2008-05-19
|
00 | (System) | New version available: draft-ietf-mpls-cosfield-def-00.txt |