The Generalized TTL Security Mechanism (GTSM) for the Label Distribution Protocol (LDP)
draft-ietf-mpls-ldp-gtsm-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-07-17
|
09 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2012-07-16
|
09 | (System) | IANA Action state changed to No IC from In Progress |
2012-07-16
|
09 | (System) | IANA Action state changed to In Progress |
2012-07-16
|
09 | Cindy Morgan | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2012-07-16
|
09 | Cindy Morgan | IESG has approved the document |
2012-07-16
|
09 | Cindy Morgan | Closed "Approve" ballot |
2012-07-14
|
09 | Adrian Farrel | Ballot approval text was generated |
2012-07-14
|
09 | Adrian Farrel | Ballot approval text was generated |
2012-07-14
|
09 | Adrian Farrel | Ballot writeup was changed |
2012-07-03
|
09 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
2012-07-03
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-03
|
09 | Carlos Pignataro | New version available: draft-ietf-mpls-ldp-gtsm-09.txt |
2012-06-19
|
08 | Samuel Weiler | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Brian Weis. |
2012-06-07
|
08 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-06-06
|
08 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-06-06
|
08 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-06-06
|
08 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-06-06
|
08 | Stewart Bryant | [Ballot Position Update] New position, Yes, has been recorded for Stewart Bryant |
2012-06-06
|
08 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2012-06-05
|
08 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2012-06-05
|
08 | Sean Turner | [Ballot discuss] RFC 5082 says there's a MUST for authentication but doesn't say what mechanism - and that's fine. LDP's authentication mechanism, TCP-MD5, must be … [Ballot discuss] RFC 5082 says there's a MUST for authentication but doesn't say what mechanism - and that's fine. LDP's authentication mechanism, TCP-MD5, must be a configurable option (i.e., not always used). Doesn't using GSTM with LDP invoke a requirement to *use* the authentication mechanism (i.e., upgrade from a configurable option)? |
2012-06-05
|
08 | Sean Turner | Ballot discuss text updated for Sean Turner |
2012-06-05
|
08 | Sean Turner | [Ballot discuss] RFC 5086 says there's a MUST for authentication but doesn't say what mechanism - and that's fine. LDP's authentication mechanism, TCP-MD5, must be … [Ballot discuss] RFC 5086 says there's a MUST for authentication but doesn't say what mechanism - and that's fine. LDP's authentication mechanism, TCP-MD5, must be a configurable option (i.e., not always used). Doesn't using GSTM with LDP invoke a requirement to *use* the authentication mechanism (i.e., upgrade from a configurable option)? |
2012-06-05
|
08 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner |
2012-06-05
|
08 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks |
2012-06-05
|
08 | Stephen Farrell | [Ballot comment] (1) 5082 has a MUST for authentication if negotiating GSTM. I don't get why this "built-in" negotiation, which seems to me to be … [Ballot comment] (1) 5082 has a MUST for authentication if negotiating GSTM. I don't get why this "built-in" negotiation, which seems to me to be added post-facto, gets around this need for strong authentication. I'm not going to insist that you define such authentication, (be nice if someone did though), but I do think you need to say you're not adhering to the MUST from 5082. (2) When receiving an LDP Link Hello with G=1, what checks are to be made on the TTL for that packet? If you don't enforce GSTM on that, then presumably attacks could be mounted with a Link Hello that has G=0, defeating the negotiation (hence point (1) above I guess;-). Why is this ok? If you're really taking a "leap of faith" here, then that's probably fine, but should be stated IMO. In any case I think you need to be clear about whether the TTL on this packet needs checking or not. nits: - typo in section 3? "(i.e.,g G=1)" - s/g//? - typo in section 5: s/may cause LDP peering session/may cause an LDP peering session/ |
2012-06-05
|
08 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2012-06-05
|
08 | Barry Leiba | [Ballot comment] Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- 2.1 -- The … [Ballot comment] Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- 2.1 -- The G flag is meaningful only if the T flag is set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt. What happens if it isn't? SHOULD means, basically, MUST unless you fully understand the consequences... so what are the consequences, so that an implementor might have a chance to understand them? ======== Other comments; no need to respond to these. Take them or modify them as you please: -- 1 -- Therefore, GTSM can fully benefit LDP protocol peering session established using Basic Discovery. I don't understand this sentence; maybe there's a word missing. But it also seems awkward. Does it mean this?: NEW Therefore, GTSM can provide full benefit to an LDP protocol peering session that was established using Basic Discovery. That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration. But you just said that RFC 5082 said not to do that. I understand what you're getting at, so maybe this will make it clear?: NEW That is, the desire to use GTSM (i.e., its negotiation mechanics) is enabled by default without any configuration, while retaining the spirit of the advice in RFC 5082. |
2012-06-05
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-06-04
|
08 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy |
2012-06-04
|
08 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-06-04
|
08 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2012-06-02
|
08 | Carlos Pignataro | New version available: draft-ietf-mpls-ldp-gtsm-08.txt |
2012-05-30
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-05-29
|
07 | Adrian Farrel | Placed on agenda for telechat - 2012-06-07 |
2012-05-29
|
07 | Adrian Farrel | State changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2012-05-29
|
07 | Adrian Farrel | Ballot approval text was generated |
2012-05-29
|
07 | Adrian Farrel | Ballot approval text was generated |
2012-05-29
|
07 | Adrian Farrel | Ballot has been issued |
2012-05-29
|
07 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2012-05-29
|
07 | Adrian Farrel | Ballot writeup was changed |
2012-05-29
|
07 | Adrian Farrel | Created "Approve" ballot |
2012-05-29
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-05-29
|
07 | Carlos Pignataro | New version available: draft-ietf-mpls-ldp-gtsm-07.txt |
2012-05-29
|
06 | Adrian Farrel | State changed to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead |
2012-05-29
|
06 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-05-18
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
2012-05-18
|
06 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
2012-05-17
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Mary Barnes |
2012-05-17
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Mary Barnes |
2012-05-16
|
06 | Pearl Liang | IANA has reviewed draft-ietf-mpls-ldp-gtsm-06, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there … IANA has reviewed draft-ietf-mpls-ldp-gtsm-06, which is currently in Last Call, and has the following comments: IANA understands that, upon approval of this document, there are no IANA Actions that need completion. |
2012-05-15
|
06 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Generalized TTL Security Mechanism (GTSM) … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP)) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP)' 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 2012-05-29. 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 Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. This technique improves security and is used by many protocols. This document defines the GTSM use for the Label Distribution Protocol (LDP). This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-gtsm/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-gtsm/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-05-15
|
06 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2012-05-15
|
06 | Adrian Farrel | Last call was requested |
2012-05-15
|
06 | Adrian Farrel | Ballot approval text was generated |
2012-05-15
|
06 | Adrian Farrel | State changed to Last Call Requested from AD Evaluation::AD Followup |
2012-05-15
|
06 | Adrian Farrel | Last call announcement was changed |
2012-05-15
|
06 | Adrian Farrel | Last call announcement was generated |
2012-05-15
|
06 | Adrian Farrel | Last call announcement was generated |
2012-05-15
|
06 | Adrian Farrel | Ballot writeup was changed |
2012-05-14
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-05-14
|
06 | Carlos Pignataro | New version available: draft-ietf-mpls-ldp-gtsm-06.txt |
2012-04-30
|
05 | Adrian Farrel | Hello authors of draft-ietf-mpls-ldp-gtsm, I have conducted my usual AD review of your draft in response to the publication request from the WG. This, … Hello authors of draft-ietf-mpls-ldp-gtsm, I have conducted my usual AD review of your draft in response to the publication request from the WG. This, of itself, is not reason to induce panic :-) My review has yielded a number of questions and nits. All of the points are open for discussion and I am not mandating changes. But I think that there are enough issues here to warrant a new revision. I have put the document into "revised I-D" state and look forward to a new version or a lively email debate. Thanks, Adrian --- I am confused by whether you propose GTSM to be enabled by default. Section 1 says... GTSM specifies that it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol Section 1.2 says... GTSM and will require (statically or dynamically) disabling GTSM. See Section 3. Section 3 says... The reason GTSM is enabled for Basic Discovery by default Indeed, 5082 says... 3. Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis. In fact, I don't think GTSM is enabled by default in your document. I think what you have is that the desire to use GTSM (i.e., the negotiation to use it) is enabled by default in implementations of your spec. But this is subtly different from what the text says. --- Can you tidy the English in Section 1. Suggested... OLD GTSM specifies that it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol; this document specifies having a built-in dynamic GTSM capability negotiation for LDP to suggest the use of GTSM, provided GTSM is not enabled unless both peers can detect each others' support for GTSM procedures and agree on its usage as described in this document. NEW GTSM specifies that it should not be enabled by default; this facilitates backward-compatibility with the unmodified protocol. This document specifies a dynamic negotiation for the an LDP peer to suggest the use of GTSM. GTSM will be used as specified in this document provided both peers on an LDP session can detect each others' support for GTSM and agree to use it. END Note the change s/SHOULD NOT/should not/. This text in Section 1 is not defining any protocol behavior and comes before the citation of RFC 2119. It doesn't need to use upper case. --- You need to do some work to expand acronyms on first use if they are not listed with an asterisk at: http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt I found: LSR --- Is it time to define an IANA registry for the common Hello parameters bit fields? Had one existed, you would not have needed to update 5036. If you create one now, future bit users will not have to update your RFC. --- Section 2.1 The G flag is meaingful only if T and R flags are set to 0 (which must be the case for Basic Discovery), otherwise, the value of G flag SHOULD be ignored on receipt. This is clear for the T flag: the use of GTSM is not supported for targeted (extended) Hellos. Why is this the case for the R flag? The use of the R flag is making a request, not demanding use. It might be the normal case that you would not set the R flag unless you were more than one hop away, but it does not follow that this is the case, does it? As indicated in RFC 5036, a Hello receiver that does not support targeted Hellos ignores the request (i.e., the R flag). That would clear it to support the G flag. --- Section 2.1 Any LSR not supporting GTSM for LDP, as defined in this document, would continue to ignore the G flag, independent of T and R flags' value, as per Section 3.5.2 of [RFC5036]. I think you need to cover two cases. As it happens the behavior you are asking for is the same, but I think you need to call out the two cases separately: 1. An LSR that does not recognise the G flag. 2. An LSR that does recognise the G flag but does not support GTSM (either through implementation or configuration). --- Section 2.2 Firstly, LSRs using LDP Basic Discovery [RFC5036] send LDP Hello messages to link-level multicast address (224.0.0.2 or "all routers"). Such messages are never forwarded beyond one hop and assumed to have their IP TTL or Hop Count = 1. This assumption is, I think, new in your document. I can't find anything about this in 5036 (although I may have missed it). I suspect you need to change this from an assumption to a RECOMMENDation --- Section 2.2 An LSR that is capable of applying GTSM procedures to the subsequent TCP/LDP peering session MUST set the G flag (for GTSM) to 1 in Common Hello Parameter TLV in the LDP Link Hello message [RFC5036]. "capable" is such an interesting word :-) And the text here is interesting. Does this cut into the discussion of defaults above? What you are saying is that a device that has been coded to support GTSM has to negotiate its use regardless of operator preferences. Why? How would the following look? Unless configured otherwise, an LSR that supports GTSM sets the G flag (for GTSM) to 1 in Common Hello Parameter TLV in the LDP Link Hello message [RFC5036]. --- Section 2.2 An LSR, upon receiving an LDP Link Hello message, would recognize the presence of G flag (in Common Hello Parameter TLV) only if it supports GTSM for LDP, as specified in this document. This is not true :-( You are updating 5036 so all new implementations will recognise the G flag whether or not they support GTSM. --- Section 2.2 If an LSR recognizes the presence of G flag with the value =1 in the received LDP Link Hello message, then it MUST enforce GTSM for LDP in the subsequent TCP/LDP peering session with the neighbor that sent the Hello message, as specified in Section 2.3 of this document. Again, this does not offer the operator any control or choice in the matter. Why is the use of GTSM not configurable? --- Section 2.2 If an LSR that has sent the LDP Link Hello with G flag = 1, then the LSR MUST set IP TTL or Hop Count = 255 in the forthcoming TCP Transport Connection(s) with that neighbor (e.g., LSR2). Please see Section 2.3 for more details about the TCP transport connection specifics. Why is this MUST? What if the peer has responded with G=0 indicating it doesn't support (or want to use) GTSM? Surely, in that case, the local LSR can set any TTL. BTW Why is this paragraph in Section 2.2? --- I think the mentions of "LSR2" in sections 2.2 and 2.3 are a little unnecessary. --- Are we missing a discussion of what happens if the value of G changes on a subsequent Hello? --- Section 3 Typo s/en the third case/In the third case/ --- Section 5 Suppose I touch the setting of the G flag in transit? That means that LDP Hello security is more important, right? --- Section 5 Shouldn't you make reference to the security section of 5082. In particular, you need to highlight the things GTSM does not protect against. --- I believe your document should give stronger hints than the generic comments in 5082 about what should be done with an LDP message that "fails" a GTSM TTL check. This is appropriate because you are writing a protocol-specific application of GTSM. |
2012-04-30
|
05 | Adrian Farrel | State changed to AD Evaluation::Revised ID Needed from AD Evaluation |
2012-04-30
|
05 | Adrian Farrel | Ballot writeup was changed |
2012-04-30
|
05 | Adrian Farrel | Ballot writeup was generated |
2012-04-30
|
05 | Adrian Farrel | State changed to AD Evaluation from Publication Requested |
2012-04-25
|
05 | Amy Vezza | (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 requests that The Generalized TTL Security Mechanism (GTSM) for Label Distribution Protocol (LDP) Is published as an RFC 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 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 Generalized TTL Security Mechanism (GTSM) describes a generalized use of a packets Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify that the packet was sourced by a node on a connected link, thereby protecting the router's IP control-plane from CPU utilization based attacks. The original work on GTSM were done in the RTG Working Group. This document defines the GTSM use for Label Distribution Protocol (LDP). The GTSM technique improves security and is used by many protocols. This specification uses a bit reserved in RFC 5036 and therefore updates RFC 5036. 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? - This document has been through a pretty normal working group process, with no discontent and strong support. The document was last called in the MPLS working group, and information about this last call were copied to the rtgwg. 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 know plans to implement this specification. A request has been sent to the MPLS working mailing list for further information, and this section will be updated if we have positive responses or the time allocated to respond to the request terminates. Ther are indications from vendors tht this will be implemnted. Since this is based on RFC 5082 and LDP is a pretty straightforward protocol the review ?process has not led to an major changes in the document. One of the co-authors of this document is also a co-author of RFC5082. LDP was also highlighted in RFC 5082 as one of the potential protocols that the would benefite from a GTSM mechanis.. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? - Loa Andersson is the document shepherd - Adrian Farrel is 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. - Since the document shepherd is also one of the working group chairs, the main shepherd review coincided with the wg chair review prior wg last call the document. Additional shepherd initiated review is limited to check of the wg chair comments and comments on the working group list has been correctly addressed and all nits resolved. The shepher/wg chair also to initiative to copy the wg last call to the rtgwg. (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 disclosures on this document, and the authors has confirmed that they are not aware of any IPRs for this document. Neither are there IPR claims on RFC5082. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. - No IPR disclsures. (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? - Working group last call concluded April 11th and the shepherd write up is written Apr 18th. There has been enough discussion on this draft on the list and at meetings, there has been no diverging opinions and the support is solid. (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. (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. - No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. - No such formal review required, though I assume that the Security Directorate will take a look at the document as a normal part of the IESG review. (13) Have all references within this document been identified as either normative or informative? - Yes, and correctly split. (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? - No. (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. (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. - RFC 5036 is updated. This is correctly described on the title page. (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 requests to IANA to assign code points or create registries. (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 registries specified. (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. |
2012-04-25
|
05 | Amy Vezza | Note added 'Loa Andersson is the document shepherd (loa@pi.nu).' |
2012-04-25
|
05 | Amy Vezza | Intended Status changed to Proposed Standard |
2012-04-25
|
05 | Amy Vezza | IESG process started in state Publication Requested |
2012-04-25
|
05 | (System) | Earlier history may be found in the Comment Log for draft-asati-pignataro-mpls-ldp-gtsm |
2012-04-11
|
05 | Carlos Pignataro | New version available: draft-ietf-mpls-ldp-gtsm-05.txt |
2011-11-14
|
04 | (System) | New version available: draft-ietf-mpls-ldp-gtsm-04.txt |
2011-08-26
|
03 | (System) | New version available: draft-ietf-mpls-ldp-gtsm-03.txt |
2011-08-22
|
02 | (System) | New version available: draft-ietf-mpls-ldp-gtsm-02.txt |
2011-06-12
|
01 | (System) | New version available: draft-ietf-mpls-ldp-gtsm-01.txt |
2011-05-20
|
00 | (System) | New version available: draft-ietf-mpls-ldp-gtsm-00.txt |