LDP Capabilities
draft-ietf-mpls-ldp-capabilities-04

[Ballot comment]
The name of the U bit would have been nice to have in the doc.

I agree with the issues other people have raised.

[Ballot comment]
I think that this DISCUSS can be cleared up with an RFC editor note:

In Section 3, you should say that the U bit tells a LDP speaker how to behave if it does not support this capability (u stands for unsupported?)

In Section 3, why does the F-bit exist if it must always be set to 0? If it might be set to 1 at some future time, shouldn't you tell us what to do when that happens?

In Section 3.1, you might want to enumerate the exiting protocol extensions that could act as capability TLVs.

[Ballot comment]
The advice on future documents that actually name and define capabilities, seems to be incomplete.  Perhaps its clear to the authors, but I don't understand which IANA registry future capabilities would be listed in. 

It would also be good to advise those future capabilities defining documents, to specify whether the capability is even appropriate for being advertised mid-session.  Some capabilities might require dropping a session.

Note that the email address in the draft for Bob Thomas is out of date. He can be reached at either of: bobthomas@alum.mit.edu and bobt727@yahoo.com. I will add an RFC editor's note to fix this in the draft.

[Ballot comment]
Since the intention is to publish an RFC that will be current, it would be advisable to remove present tense text from the Abstract that will actually refer to the past. Thus, suggest you delete...

At present, LDP has no
mechanism for advertising such enhancements at LDP session
initialization time.  There is also no mechanism to enable and
disable enhancements after the session is established.

There is similar text in the Introduction that I would also recommend you to delete.

-----

It would be wise to include a reference (informative) to draft-ietf-mpls-mpls-and-gmpls-security-framework in section 11

[Ballot discuss]
Hopefully this can be cleared with a simple exchange of email.

In section 3.1 you state that the "FT Session TLV" fomr RFC 3479 can be treated as a Capability Parameter. Yest the FT Session TLV already assigns meaning to the first bit of the fifth octet (the R-bit in section 8.2 of RFC 3479) and this seems to conflict in meaning with the S-bit in the Capablity Parameter TLV you define in section 3.

I suspect that this may be resolved by some clarification of "play the role of."

[Ballot discuss]
Hopefully this can be cleared with a simple exchange of email.

In section 3.1 you state that the "FT Session TLV" fomr RFC 3479 can be treated as a Capability Parameter. Yest the FT Session TLV already assigns meaning to the first bit of the fifth octet (the R-bit in section 8.2 of RFC 3479) and this seems to conflict in meaning with the S-bit in the Capablity Parameter TLV you define in section 3.

I suspect that this may be resolved by some clarification of (play the role of."

[Ballot discuss]
Hopefully this can be cleared with a simple exchange of email.

In section 3.1 you state that the "FT Session TLV" fomr RFC 3479 can be treated as a Capability Parameter. Yest the FT Session TLV already assigns meaning to the first bit of the fifth octet (the R-bit in section 8.2 of RFC 3479) and this seems to conflict in meaning with the S-bit in the Capablity Parameter TLV you define in section 3.

[Ballot comment]
Since the intention is to publish an RFC that will be current, it would be advisable to remove present tense text from the Abstract that will actually refer to the past. Thus, suggest you delete...

At present, LDP has no
mechanism for advertising such enhancements at LDP session
initialization time.  There is also no mechanism to enable and
disable enhancements after the session is established.

There is similar text in the Introduction that I would also recommend you to delete.

I think adding capability/extension discovery mechanism to a protocol is important, so I am almost tempted to vote Yes for this document, except for I don't have much clue about MPLS.

I wonder if there is any use for disabling extensions. When designing a similar extension in IMAP the Lemonade WG decided against such feature.

IANA Last Call comments:

IANA has a question:

- Do you need a registry of capability-advertisement TLVs?


Action 1:

Upon approval of this document, the IANA will make the following
assignments in the "Label Distribution Protocol (LDP)" registry at
http://www.iana.org/assignments/ldp-namespaces
sub-registry "MESSAGE TYPE NAME SPACE"

Value Name Reference
---------- ----------------------------- ---------
TBD (0x0202) Capability
[RFC-mpls-ldp-capabilities-02]


Action 2:

Upon approval of this document, the IANA will make the following
assignments in the "Label Distribution Protocol (LDP)" registry at
http://www.iana.org/assignments/ldp-namespaces
sub-registry "TLV TYPE NAME SPACE"

Range Name Reference
---------- ----------------------------- ---------
TBD (0x0304) Returned TLVs
[RFC-mpls-ldp-capabilities-02]

TBD (0x0506) Dynamic Capability Announcement
[RFC-mpls-ldp-capabilities-02]


Action 3:

Upon approval of this document, the IANA will make the following
assignments in the "Label Distribution Protocol (LDP)" registry at
http://www.iana.org/assignments/ldp-namespaces
sub-registry "STATUS CODE NAME SPACE"

Range/Value E Description Reference
------------- ----- ---------------------- ---------
TBD 0 Unsupported Capability
[RFC-mpls-ldp-capabilities-02]
(0x0000002C)


We understand the above to be the only IANA Actions for this
document.

PROTO writeup by Loa Andersson:

Requested Publication Status: Proposed Standard

------------------------------------------------------------------------

    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

Both mpls wg co-chairs reviewed this version of the ID. Based on the WG comments, we believe the ID is ready for publication.

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, the document has been through wg last call with good and constructive comments, it has also been reviewed by subject-matter experts who are WG members.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

No.

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

    1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No. The internet-draft was produced by working group members with experience from LDP implantations and testing.


    1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

This document represents the WG consensus as a whole: the WG as a whole understands and agrees with it.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

    1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

There are no ID nits issues per the automated ID nits check.

    1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

No.

    1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

    1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

--- Technical Summary

    This document is an extension to the standards track RFC 5036, and
    defines methods to enable new capabilities at initiation of the LDP
    session or during operation; it also includes a mechanisms to
    disable such capabilities at any time during operation.

    This is driven by that a large number of enhancements to the LDP
    have been proposed, some of these enhancements have been implemented,
    and some are advancing toward standardization. It is also highly likely that
    additional enhancements will be proposed in the future.

--- Working Group Summary

    The Working Group has consensus to publish this document as a
    Proposed Standard.

--- Protocol Quality

    The document has been reviewed by experts form the MPLS working
    group as well as being last called in the working, the comments received
    from the experts and the working has been addressed and the document
    updated.

--- Implementations

    We know of at least one implementation of the specification.

Loa and George