Shepherd writeup

This document was returned to the working group and the authors after 
AD evaluation and some very late comment. The document has been updated and
a refresh of the Shepherd Writeup is necessary. The Shepherd has chose to do
this refresh creating a zebra document, i.e. the new information has been 
introduced into the earlier "white" document as "black" stripes. The "black"
stripes are preceeded by "2014-09-30"

Changes are expected over time. This version is dated 24 February 2012.

This version is dated 2014-09-30.

      The MPLS working group request that

                          Updates to LDP for IPv6

      ís published as an RFC on the standards track

(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 Label Distribution Protocol (LDP) specification defines procedures
      to exchange label bindings over either IPv4, or IPv6 or networks that 
      uses both IPv4 and IPv6. This document corrects and clarifies the LDP 
      proceedures and behaviors when IPv6 network is used (with or without IPv4). 

      In doing so this document updates RFC 5036 and needs to be published
      on Standards Track-

      It should be published as a Proposed Standard, the document header says
      "Standards track"!.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

     The LDP [RFC5036] specification defines procedures and messages for
     exchanging FEC-label bindings over either IPv4 or IPv6 or networks deploying
     both  types of technologies (e.g. dual-stack networks).

     Although LDP is defined in RFC5036 so that it may be used over IPv4 
     and/or IPv6, RFC 5036 really does not really allow for interoperable
     implementations of LDP over IPv6. In this respect RFC 5036 is too
     under-specified to be implemented over IPv6.

     Consequently, this document list 7 deficiencies in RFC5036 (see the Introduction)
     that needs to be addressed to allow interoperable LDP implementations in 
     IPv6 networks
     The documen and also specifies how these deficiencies should be adressed
     in regards to IPv6 usage. In general there can be said that RFC 5036 lack
     in detail, rules and procedures for using LDP in IPv6 enabled  networks 
     (IPv6-only or Dual-stack networks).

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 

       This document has a rather long history even though  it is a document that is
       focused to address a limited scope of issues - some of the issues are in 
       themselves of considerable complexity

       The first individual version of this draft was published in February 2008,
       it was well received, but the timing was a bit unfortunate, it was about the same
       time as the start of the MPLS-TP work and the MPLS wg were a bit swamped
       by a large number of MPLS-TP drafts.

       However, we had a good discussion on the list and the document was accepted 
       as a working group document in November 2010. Followed by a good discussion,
       and the wglc in Aug 2011 were uneventful due to that the  issues had been
       addressed. However after reposting a new version there were some questions 
       put to the working group and that generated further comments. One of these
       comments turned out to be hard to resolve given the disagreement between the
       authors and reviewers.. It had to do  with the number of LDP Hello
       adjacencies needed to be kept and maintained on the receiver side between 
       a pair LSRs with both IPv4 and IPv6 stacks, it did take us quite a long  time 
       to resolve this.

       When we had the resolution we did a short working group last call on the
       changes that been introduced between the two working group last calls. 
      This short wglc call only received supportive comments. The current version 
      is agreed upon by all parties.

       However it would not be this document if we had not received a new set of 
       comments outside the scope of the short working group last call. The comments 
       are supportive and will improve the document. A new version has been posted 
       addressing these comments.

       The document was returned to the wg and the authors due to comments during 
       the AD Evaluation and late comments.

       These comments were resolved and were verified (mostly) in a short wglc (July 12, 2014).
       However there were comments claiming that "some" implementations were not 
       RFC 5036 compatible and started to flap LDP sessions. In one case we have been able 
       to verify that this a temporary issue that has been resolved.

       It was proposed that this document should be fixed so that both RFC 5036 compatible
       and non-comptible implementations would work.
       In general the Shepherd and wg chairs belive that implementations should be RFC 5036

       Some text has been added to this document to address the comment(s). see section 8
       paragraph 2.

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?

       A mail has been sent to the working group asking for implementations and
       the shepherd write-up will be updated as we receive this information.
       So far this implementation poll has resulted in that we know of one 
       implementation under way.

       The key reviewers are all mentioned in the acknowledgment section.

       There are significant vendor and operator interest in this draft. 

       No MIB Doctor or Media Type reviews are necessary.

       We are aware of at least two implementations of this draft.


  Who is the Document Shepherd? Who is the Responsible Area

       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.

      The document shepherd has reviewed the document several times, before
      the wg adoption poll and both wglc's. But also while resolving the outstanding

      The Shepherd reviewed the document prior to the short wglc, and has also had
      the oportunity to review the document several times (the entire document and
      in part) during the discussion after the short wglc.

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

      No such concerns! 

      However see the response to question 9.

(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 such reviews needed.

(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, all the outstanding issues have been resolved.

(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.

      All the authors has stated on the working group mailing list that they
      unaware of an IPR related to this document.

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

      There are no IPR disclosures relevant to 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?

      It has taken time, but the working group does now support this document.


      We have not been able to fully converge on the last comment, the Shepherd
      and wg chairs are convinced that version -14 represent the working group
      consensus and think we should progress the document now.

(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!

      Having said that, it is also likely that we will see some of the comments
      from the short wglc repeated in IETF LC.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be

       The document passes the nits tool clean.

       The nits tool gives a warning about IP addresses not compliant to 
       and RFC3849: however the IP addresses in the document are not
       examples in the sense defined in these RFCs.

       The nits tool also point that we use a "disclaimer for pre-RFC5378 work".
        For the time being this disclaimer is correct, but for reasons partly
       outside the scope of this document we have started process to see if
       if the authors/contributors to RFC 3036, RFC 5036 and this document
       are willing to grant the BCP 78 rights to the IPR trust.

       We have identified 17 authors and contributors to RFC 3036, RFC 5036 and
       draft-ietf-mpls-ldp-ipv6 that needs to grant the BFC 78 rights for these documents
       to the IETF Trust.

       So far there are two (2) that we have are not certain that  we have managed to 
       find mail addresses to; there are eight (8) that have not yet responded to the mail
       sent out; and  seven (7) that have responded that they are willing to grant their
       BCP 78 rights. Considering that  this has been done during the Holiday season
       it is not bad.

       The shepherd write-up will be updated as further responses are received.

       Note: that if we fail to receive acknowledgment from all, we can still go ahead 
       keeping the  pre-BCP boilerplate 78 in the document.

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

      No such reviews necessary

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

      Yes they have been 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?

      All normative references as to existing standards track 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.

      This document updates RFC5036, this is well captured in the Abstract and
      and in the Introduction.

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

      There are no requests for IANA actions in this document.

(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 that require Expert Review. 

(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 sections written in formal language.