LDP Specification
RFC 5036

From Gen-ART review of draft-ietf-mpls-rfc3036bis-03.txt 
by David Black. These comments arrived after I already
entered No Objection but seem to need attention.

(1) This draft has a major process problem - Section 2.9 has a normative
dependency on the TCP MD5 signature option.  The maturity variance for
the TCP MD5 signature option in RFC 4278 is primarily for BGP - RFC 4278
has only this to say about LDP (Section 5):

   The Label Distribution Protocol (LDP) [RFC3036] also uses [RFC2385].
   Deployment practices for LDP are very similar to those of BGP: LDP
   connections are usually confined within a single autonomous system
   and most frequently span a single link between two routers.  This
   makes the LDP threat environment very similar to BGP's.  Given this,
   and a considerable installed base of LDP in service provider
   networks, we are not deprecating [RFC2385] for use with LDP.

While that text indicates the IESG's inclination to grant a maturity
variance for TCP MD5's usage in LDP, it does not actually grant the
variance.  The LDP draft attempts to sidestep this by making RFC 2385
a non-normative reference (Section 9.2).  That approach is clearly
wrong, as Section 2.9 says:

   This section specifies a mechanism to protect against the introduc-
   tion of spoofed TCP segments into LDP session connection streams.
   The use of this mechanism MUST be supported as a configurable option.

   The mechanism is based on use of the TCP MD5 Signature Option speci-
   fied in [RFC2385] for use by BGP.

The "MUST" in the quoted text requires that RFC 2385 be a normative
reference.  Hence, the IESG appears to need to grant an explicit standards
maturity variance for TCP MD5's use in LDP if Section 2.9 is to remain
in the LDP draft.  Granting that variance is probably the proverbial
"right thing" to do, but it does appear to be necessary to do so.

(2) Section 3.6.1.1 allows the U bit to be clear for a vendor-private
TLV, so that if the TLV is not understood, the entire message is
rejected.  This appears to allow mandatory vendor-private extensions,
which has been an IESG concern in the past.  If mandatory vendor-
private TLV elements are not to be allowed, this section would need
to require that the U bit always be set for a vendor-private TLV.  An
analogous issue occurs for the U bit in vendor-private messages in
Section 3.6.1.2, but could be addressed by requiring a sender to
continue if a vendor-private message is rejected.

Also see
http://www.alvestrand.no/ietf/gen/reviews/draft-ietf-mpls-rfc3036bis-03-black.txt
for nits

Bill Fenner has posted a new implementation survey in the form of
an e-mail that lists the results of an e-mail poll that the chairs
made. Its borderline whether this really qualifies as a good implementation
report, but I'm not sure I should hold a discuss any longer because
we weren't really missing the whole report, just the answer to the
question of whether it referred to 3036 or the bis document.

I strongly concur with Scott's concerns about the implementation report.  I am not holding a discuss because I believe they have been heard.