Skip to main content

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