Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-17

[Ballot discuss]
I hope these are quick to resolve.

In Sec. 6.1.1, it says:
"1. If "Dual-stack capability" TLV is present and remote preference
        does not match with the local preference (or does not get
        recognized), then the LSR MUST discard the hello message and
        log an error.

        If LDP session was already in place, then LSR MUST send a fatal
        Notification message with status code [Transport Connection
        mismatch, IANA allocation TBD] and reset the session.
"
I am concerned about the operational impact of this.  Is there really a reason
to drop traffic due to a mismatch?  Wouldn't it be better to leave an existing
LDP session up until a peer explicitly needs to bring it down? 

In Sec 7, it says
"The procedures defined in section 6.1 SHOULD result in setting up
  the LDP session in preferred AFI only after the loss of an existing
  LDP session (because of link failure, node failure, reboot etc.)."

which seems to be in direct conflict with the actual behavior specified that can cause
an existing LDP session to be torn down.



In Sec 6.1.1:

In (3), it says
" However, if IPv6 hellos are also received at any time from
  that neighbor, then the neighbor is deemed as a non-
  compliant Dual-stack LSR (similar to that of 3c below),
  resulting in any established LDPoIPv4 session being reset
  and a fatal Notification message being sent (with status
  code of 'Dual-Stack Non-Compliance', IANA allocation TBD)."

Can you clarify what "at any time" means?  Is this since the interface came
up?  I really feel that this needs better description.  As it is, this could be since
the router booted - and if a neighboring router was IPv4 only and was then
upgraded/replaced to become IPv6 only - one would never have an LDP
connection.  That's not acceptable.

[Ballot comment]
I agree with Joel's (Tim's) question on why a 5036bis was not created.  Strictly from a writing perspective, that approach seems straightforward and would make a single LDP specification.  But, this is a non-blocking comment and I will happy as long as this information gets published in some fashion.

[Ballot comment]
From Tim Chown's opsdir review. I would like to discuss the possiblility of appendix coving the changes mad by this document or what seems like a minor effort to make this the wholesale replacement of 5036.

this does not rise to the level of a discuss, who knows we may get there. Thanks.

From Tim Chown:

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed
in last call may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments just like
any other last call comments.

Summary: this document is Ready with Issues.

This document describes updates to the Label Distribution Protocol as
described in RFC 5036 (and GTSM elements in RFC 6720), to clarify and
correct the described or implied behaviour in IPv4-only, IPv6-only and
dual-stack deployments.

Issues:

* This draft describes a number of ambiguities in particular in dual-stack
behaviour, with at least eight such issues being listed in section 1. When
reading this draft, in conjunction with RFC 5036, I personally find it quite
tricky to apply the updated rules/guidance described here to the existing
text in RFC 5036, due to the rather patchy nature of the document. I would
therefore suggest that the authors consider a complete revision to
RFC 5036 (as happened from RFC 3036), rather than having the
clarifications / corrections ‘dangling’ in this additional text. I appreciate
that such a revision may be considered overkill, so at the very least this
document should include a clear list of changes / updates, perhaps as
an appendix.

* The general principles of the dual-stack / IPv4 / IPv6 operation should
be stated early in the document - these are conveyed piece by piece as
you read through the document, but it would be helpful to have them
clearly stated up front.

* There is an amount of repetition through the document. I suspect that in
the 15 revisions there have been changes made which have caused this.
If the document progresses as a standalone document, this should be
corrected where possible.  As it stands, the document feels disjoint in
places, and doesn’t flow anywhere near as well as it could.

Nits:

* The specification language section (section 2) should be moved earlier in
the document, given abbreviations described therein are used prior to their
definition.

* In 5.1 may wish to mention the IANA registry for IPv6 multicast addresses
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

* Last para of 5.1 - why are IPv6 LDP link Hellos to be transmitted first?
It would be useful to state the reason.

* There are various places in the draft that talk about address selection,
e.g. in 5.1 and in 5.2; I think these are all consistent with RFC 6724, so
perhaps that RFC should be used / cited here?

* The set of rules in 6.1 repeats some parts of the earlier sections, but not
entirely, e.g. the rule in the last para of 5.1 is not included in 6.1.

* In 6.1.1, para 2, state here that this inclusion of the new TLV is a MUST;
this is currently only stated a further page on.

* In 6.1.1 point 3a) this is a little confusing because earlier the document
talks about sending both IPv4 and IPv6 Hello messages, and part c) seems
to duplicate parts a) and b) ?

Tim

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-mpls-ldp-ipv6-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has some questions about the actions requested in the IANA Considerations
section of this document.

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the TLV Type Name Space subregistry of the Label Distribution Protocol (LDP) Parameters registry located at:

https://www.iana.org/assignments/ldp-namespaces/

a new TLV type is to be registered as follows:

Value: [ TBD-at-registration ]
Description: Dual-Stack capability
Reference: [ RFC-to-be ]
Notes/Registration Date:

IANA notes that the authors request that the Value to be used for this new TLV type come from the IETF Consensus/LDP base protocol range of the name space.

Question: the current text has an incorrect registration procedure for
the "TLV Type Name Space" registry:

The 'Dual-Stack capability' parameter requires a code point from the
  TLV Type Name Space.  [RFC5036] partitions the TLV Type Name Space
  into 3 regions:  IETF Consensus region, First Come First Served
  region, and Private Use region.  The authors recommend that a code
  point from the IETF Consensus range be assigned to the 'Dual-Stack
  capability' TLV.

The registry does not have a range using First Come First Served.  Can the authors
please correct the above text in the IC section of this document?

Second, in the Status Code Name Space subregistry of the Label Distribution Protocol (LDP) Parameters registry located at:

https://www.iana.org/assignments/ldp-namespaces/

a new status code is to be registered as follows:

Range/Value: [ TBD-at-registration ]
E:
Description: Transport Connection Mismatch
Reference: [ RFC-to-be ]

IANA Question --> What should the value of "E:" be for this registration?

IANA notes that the authors request that the value for this new status code come from the IETF Consensus range of the name space.

Third, also in the Status Code Name Space subregistry of the Label Distribution Protocol (LDP) Parameters registry located at:

https://www.iana.org/assignments/ldp-namespaces/

a new status code is to be registered as follows:

Range/Value: [ TBD-at-registration ]
E:
Description: Dual-Stack Non-Compliance
Reference: [ RFC-to-be ]

IANA Question --> What should the value of "E:" be for this registration?

Question: We see that this document has one single placeholder 'TBD' for different
assignments, i.e. 'Dual-Stack Non-Compliance' and 'Transport Connection Mismatch'.
There is no placeholder for another requested assignment 'Dual-Stack capability'. 
Do the authors require all new assignments should get the same value?
If not, would it be more clear to have three different placeholders for three
different assignments?

IANA notes that the authors request that the value for this new status code come from the IETF Consensus range of the name space.

IANA understands that these three actions are the only ones required to be completed
upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Updates to LDP for IPv6) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Updates to LDP for IPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-12-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  The Label Distribution Protocol (LDP) specification defines
  procedures to exchange label bindings over either IPv4, or IPv6 or
  both networks. This document corrects and clarifies the LDP behavior
  when IPv6 network is used (with or without IPv4). This document
  updates RFC 5036 and RFC 6720.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ipv6/ballot/


No IPR declarations have been submitted directly on this I-D.

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.

2014-09-30
This version is dated 2014-09-30.

      The MPLS working group request that

                          Updates to LDP for IPv6
                        draft-ietf-mpls-ldp-ipv6-10
2014-09-30
                        draft-ietf-mpls-ldp-ipv6-14

      í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
  rough?

      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.

2014-09-30
      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
      compatible.

      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.

2014-09-30
      We are aware of at least two implementations of this draft.

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.

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

2014-09-30
      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!

2014-09-30
      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
disclosures.

      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.

2014-09-30

      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!

2014-09-30
      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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      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.

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.

2014-09-30
This version is dated 2014-09-30.

      The MPLS working group request that

                          Updates to LDP for IPv6
                        draft-ietf-mpls-ldp-ipv6-10
2014-09-30
                        draft-ietf-mpls-ldp-ipv6-14

      í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
  rough?

      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.

2014-09-30
      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
      compatible.

      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.

2014-09-30
      We are aware of at least two implementations of this draft.

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.

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

2014-09-30
      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!

2014-09-30
      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
disclosures.

      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.

2014-09-30

      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!

2014-09-30
      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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      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.

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.

2014-09-30
This version is dated 2014-09-30.

      The MPLS working group request that

                          Updates to LDP for IPv6
                        draft-ietf-mpls-ldp-ipv6-10
2014-09-30
                        draft-ietf-mpls-ldp-ipv6-14

      í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
  rough?

      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.

2014-09-30
      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
      compatible.

      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.

2014-09-30
      We are aware of at least two implementations of this draft.

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.

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

2014-09-30
      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!

2014-09-30
      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
disclosures.

      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.

2014-09-30

      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!

2014-09-30
      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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

      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.

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.

2014-09-30
This version is dated 2014-09-30.

      The MPLS working group request that

                          Updates to LDP for IPv6
                        draft-ietf-mpls-ldp-ipv6-10
2014-09-30
                        draft-ietf-mpls-ldp-ipv6-14

      í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
  rough?

      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.

2014-09-30
      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 tht 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 genral the Shepherd and wg chairs belive that implementations should be RFC 5036
      compatible.

      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.

2014-09-30
      We are aware of at least two implementations of this draft.

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.

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

2014-09-30
      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!

2014-09-30
      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
disclosures.

      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.

2014-09-30

      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!

2014-09-30
      Having said that, it is also likely that we will see the comments
      from the short wglc repeated in IETF LC.

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

      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.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

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

      The MPLS working group request that

                          Updates to LDP for IPv6
                        draft-ietf-mpls-ldp-ipv6-10

      í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

  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 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
  rough?

      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.

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 MB Doctor or Media Type reviews are necessary.

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.

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

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

      No such concerns!

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

      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. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

      No such threats!

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

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

Record of AD review

===

Hello shepherd, authors, and chairs.

I have read through this draft and have a number of comments. Many of them are style issues, and some are just editorial, but a few are technical.

Since I am not an LDP expert, it worries me that my relatively rapid review should uncover technical concerns. Of course, I might be wrong and you can convince me that no change was needed. But if I am right then the relatively long list of acknowledgements and the high revision number for this document don't add up to much.

Since my review has been quite cursory yet has raised so many comments, I am inclined to return the document to the working group for further work.

What do you all think?

Thanks,
Adrian

===

It would be nice if someone could do a pass for English to tidy it up.

---

Thanks for the clear statement that this updates 5036.

In some of the sections (3 through 9) you make it very clear what the
updates are. In other sections you do not make a clear statement and it
is hard to work out what is descriptive text, what is normative but no
different from 5036, hat is a change to normative text, and what is new
normative text.

I think this needs to be done. The reader needs to be able to apply the
changes described here to their copy of 5036.

---

Please make a careful check of the use of upper and lower case key words.
There are multiple cases where the use of lower case terms in close
proximity to upper case terms makes one question what is descriptive and
what is normative.

---

Section 2

  LDPv4    - LDP for enabling IPv4 MPLS forwarding
  LDPv6    - LDP for enabling IPv6 MPLS forwarding

These terms are out of alignment with the fact that LDP has a version
number itself.

But in any case, the term "IPv4 MPLS forwarding" seems odd to me. Once
you are forwarding MPLS, you don't know (or care) what the payload is.
You are maybe more concerned with packet classification (i.e., IPv4
forwarding into MPLS)?

---

Section 2

  LSR      - Label Switch Router

s/Switch/Switching/

---

Section 2

  LSPv4    - IPv4-signaled Label Switched Path [RFC4798]
  LSPv6    - IPv6-signaled Label Switched Path [RFC4798]

This suggests that an LSP can only be signaled using IPv4 or IPv6 for
the whole of its path. Figure 3 in 1.1.1 clearly shows this is not the
case.

---

Section 3 (and probably elsewhere)

  This document proposes to modify this rule by also including a /128

Please don't "propose" things in text you intend to place in an RFC.

---

Section 3

While the original text was wrong by saying "/32" I think it was trying
to make a point that is potentially lost in your revised text. The point
is that is the Address Prefix FEC is a /28 that includes the an address
of the particular egress router that the packet must traverse, that is
not enough for selecting the LSP.

Thus an exact match is needed. You can say "exact match" or "/32 for
IPv4 or /128 for IPv6", but I think your text risks losing this
distinction.

---

Section 4

I don't see any mention of "LSR-Id" in 5036 section 2.2.2. What *is*
mentioned is the "router Id" and even that is referenced with "such as".

I don't see what change is actually needed. Even after your new text, it
remains the case that the LDP Id is made up as "The first four octets
identify the LSR and must be a globally unique value, such as a 32-bit
router Id assigned to the LSR.  The last two octets identify a specific
label space within the LSR."

Furthermore, your text attempts to clarify the case for IPv4 as well,
and I don't recall a survey to verify your use of "typically".

May I draw your attention to the definition of "Router ID" in RFC 2328.

Can I also draw your attention to RFC 4990 which, while targeting
GMPLS, discusses the issue of 32 bit LSR IDs in IPv6 networks.

---

Section 4

You are modifying
OLD
  An LSR MUST advertise the same transport address in all Hellos that
  advertise the same label space.  This requirement ensures that two
  LSRs linked by multiple Hello adjacencies using the same label spaces
  play the same connection establishment role for each adjacency.
NEW
  For a given address family,
  an LSR MUST advertise the same transport address in all Hellos that
  advertise the same label space.  This requirement ensures that two
  LSRs linked by multiple Hello adjacencies using the same label spaces
  play the same connection establishment role for each adjacency.
END

I see why you want to do this, but you have created a problem that
breaks the second sentence since you are suggesting that two different
transport addresses can be advertised for the same label space (one v4
and one v6). But the role in the adjacency is achieved by comparing
addresses.

Consider Alice and Bob with v4 addresses a4 and b4, and v6 addresses a6
and b6.  If a4b6 then won't Alice and Bob have different
roles for the different Hello adjacencies in the different families?

So, while 5036 has this wrong, I don't believe you have fixed it.

---

Section 4

  This document reserves 0.0.0.0 as the LSR-Id, and prohibits its
  usage.

Pardon?
Is there a reason for this?
Did anyone check how this impacts existing implementations and
deployments? It appears from 5036 that 0 is a valid LSR-Id.

(BTW. Using dot notation is not very valid given that this is not an
IPv4 address.)

---

Section 5.1

  This document specifies the usage of link-local scope e.g.
  FF02:0:0:0:0:0:0:2 as the destination multicast IP address in IPv6
  LDP Link Hellos. An LDP Hello packet received on any of the other
  destination addresses must be dropped. Additionally, the link-local
  IPv6 address MUST be used as the source IP address in IPv6 LDP Link
  Hellos.

Good to specify which address to use.
Did the WG do a survey to find out whether you are breaking deployed
implementations by requiring that the other addresses be dropped?  Why
is it necessary to drop them?

---

Section 5.1

  Also, the LDP Link Hello packets must have their IPv6 Hop Limit set
  to 255, and be checked for the same upon receipt before any further
  processing, as specified in Generalized TTL Security Mechanism
  (GTSM)[RFC5082]. The built-in inclusion of GTSM automatically
  protects IPv6 LDP from off-link attacks.

Why isn't this text normative?
What must be done after the check has failed?
Anyway, why isn't it in Section 9?

---

Section 5.1

    An implementation should prefer sending IPv6 LDP link Hellos
    before sending IPv4 LDP Link Hellos on a dual-stack interface, if
    possible.

Why isn't this text normative.
Why "if possible" given "should"?

---

Section 5.1

You have

  More importantly, if an interface is a dual-stack LDP interface
  (e.g. enabled with both IPv6 and IPv4 LDP), then the LSR must
  periodically send both IPv6 and IPv4 LDP Link Hellos (using the same
  LDP Identifier per section 4) on that interface and be able to
  receive them. This facilitates discovery of IPv6-only, IPv4-only and
  dual-stack peers on the interface's subnet.

and

  Lastly, the IPv6 and IPv4 LDP Link Hellos MUST carry the same LDP
  identifier (assuming per-platform label space usage).

I think this is a duplication.

---

Section 5.2

  Suffice to say, the extended discovery mechanism (defined in section
  2.4.2 of [RFC5036]) doesn't require any additional IPv6 specific
  consideration, since the targeted LDP Hellos are sent to a pre-
  configured (unicast) destination IPv6 address.

  The link-local IP addresses MUST NOT be used as the source or
  destination IPv6 addresses in extended discovery.

Why do you say that no additional consideration is needed, and then
describe one?

---

The header text in Section 6 lead me to expect sections discussing

    1. Transport connection establishment
    2. Session initialization

But I found

    6.1. Transport connection establishment
    6.2. Maintaining Hello Adjacencies
    6.3. Maintaining LDP Sessions

These sections are fine, but the heading text was misleading.

---

Section 6.3

  Needless to say that the procedures defined in section 6.1 should
  result in preferring LDPoIPv6 session only after the loss of an
  existing LDP session (because of link failure, node failure, reboot
  etc.).

If it is needless to say it, then don't.

---

Section 7

  An LSR MUST NOT allocate and advertise FEC-Label bindings for link-
  local IPv6 address, and ignore such bindings, if ever received.

Does that mean "MUST NOT ignore"? It seems to!
Please rewrite the text to clearly say what must and must not be done
when.

---

Section 7

    1. An LSR MUST NOT send a label mapping message with a FEC TLV
        containing FEC Elements of different address family. In other
        words, a FEC TLV in the label mapping message MUST contain the
        FEC Elements belonging to the same address family.

This appears to say that *all* FEC Elements of the same address family
must be contained in the same FEC TLV. Is that what you intended?

---

Section 7 has

  An LSR MAY constrain the advertisement of FEC-label bindings for a
  particular address family by negotiating the IP Capability for a
  given AFI, as specified in [IPPWCap] document.

That makes IPPWCap a normative reference.

It would also be nice to qualify the "MAY" with why an implementation
might want to do that.

---
           
Section 9

  This document recommends enabling Generalized TTL Security Mechanism
  (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport
  connection over IPv6 (i.e. LDPoIPv6).

This is actually the only evidence of this recommendation.
Other discussion of GTSM seems to use 5082 as the reference.

---

Section 11 should mention the off-link attacks that Section 5.1 claims
to provide protection against.

---

Section 11 says

  Moreover, this document allows the use of IPsec [RFC4301] for IPv6
  protection, hence, LDP can benefit from the additional security as
  specified in [RFC4835] as well as [RFC5920].

I found this odd. There is no previous mention of the use of IPsec in
this document, so in what way does "this document allow" that wasn't
already allowed?

I'm also a little surprised that IPsec would be used to protect a TCP-
based protocol such as LDP. What does KARP have to say on this topic?

---

Section 11 should point to Section 9.

---

Please check carefully which of your references should be normative.
If you say "do this like it is described in [foo]" then [foo] is
normative.

---

I agree with the Appendix and for that reason think that RFC 5036's
promotion to Draft Standard was probably premature.  But we are
where we are.

Did the working group consider a revision to 5036 to make it consistent?

Did the working group consider whether it would be better to wait for
implementation experience with these changes before updating 5036?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

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

      The MPLS working group request that

                          Updates to LDP for IPv6
                        draft-ietf-mpls-ldp-ipv6-10

      í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

  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 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
  rough?

      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.

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 MB Doctor or Media Type reviews are necessary.

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.

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

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

      No such concerns!

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

      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. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

      No such threats!

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

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