Link Management Protocol (LMP)
RFC 4204

       Section 16.1 says:

                   o Security mechanism should provide for well defined key
                       management schemes. The key management schemes should be well
                       analyzed to be cryptographically secure. The key management
                       schemes should be scalable.

       I think that automated key management SHOULD be provided.

       Section 16.2 recommends the use of AH in tunnel mode. I would greatly 
 prefer ESP in tunnel mode, even if confidentiality is not turned on. In my 
 opinion, ESP with integrity-only security associations is better.

       In section 16.2, the term "crypto channel" is not clear. Usually, it 
 means "IPsec security association." Yet, sometimes it refers to both the 
 IKE SA as well as the IPsec SA. I think that IKE SA and IPsec SA can be used.

       In section 16.2, please change "man-in-the middle attacks" to 
 "man-in-the-middle attacks."

       Section 16.2 says:

             Digital signature based authentication is not prone to such
             problems. It is recommended using digital signature based
             authentication mechanism where possible. If pre-shared key based
             authentication is required, then aggressive mode SHOULD be used.
             IKE pre-shared authentication key values SHOULD be protected in a
             manner similar to the user's account password.

       Please change "recommended" to upper case.

In section 3.2.1, there is a recommendation for setting
 the default values for the HelloInterval to 150ms and
 the HelloDeadInterval to 500ms. The text seems to
 indicate that the same default is used when you pass
 the traffic over an IP network as when you are
 directly connected. This seems low in the presence
 of a multi-hop IP network, as you seem likely to end
 up in Degraded state unnecessarily. Language indicating
 how to judge a deviation from this default would
 be very useful.

 The draft does not seem to be clear on what happens
 if a TestStatusSuccess or TestStatusFailure message
 is lost in flight; the current language could be read
 to indicate that the same TestStatusAck message
 would be sent in both cases (5.0, just above 5.1)

 In section 8, Graceful Restart, it is not clear whether
 Multicast discovery is re-done on interfaces which
 have had Interface_Ids discovered through
 that method, or whether these are also assumed
 to remain stable.

 In section 12.1, how are bits which
 are currently reserved later assigned?


 Notes:

 In the introduction, paragraph 2 the use of "neighboring" is
 non-trivially different from the usual, so defining it would
 be a good idea.

 The first SHOULD occurs before the Terminology definition.

 In LMP overview the statement "All LMP packest are run over
 UDP with an LMP port number [except in some cases]" would
 be better if "Except in for test messages, which may be limited
 by the transport mechanism to in-band messaging, all LMP..."

 In section 3. there is a requirement for a unique 32-bit
 non-zero integer, but no specification for how to ensure uniqueness.

 In Section 3.0, is a unicast source address used for the multicast
 packet?

 In section 3.1, the nodes MAY continue to retransmit Config messages
 both when Node_Ids are equal and when a ConfigNack with unacceptable
 alternate values is received. Some justification for *why*it would 
 seems
 useful.

 In Section 3.2.1, it notes that "if other methods are used to indicate
 bi-directional control channel connectivity", but there are no pointers
 to other methods; if none are currently specified, it might be
 useful to change the language to indicate that.

 Is the Verify_Id monotonically increasing, or random?

 In 6.0, "procedure can be used to rapidly isolate link failures" seems
 to mean data link failures, and it might be better to be more precise.

 In Section 7, the statement "Note that the 32-bit Message_Id value MAY 
 wrap"
 does not need an RFC 2119 MAY, since it is a statement of fact, not
 an interoperability point.

 In 11.3.1, there is a ligatured ae in the text for Down:

      The LMP Message Type name space should be allocated as follows:
      pursuant to the policies outlined in [RFC2434], the numbers in the
      range 0-127 are allocated by Standards Action, 128-240 are allocated
      through an Expert Review, and 241-255 are reserved for Private Use.

It might be good to expand on expert review just a bit. Is the
intention that anyone can get one an allocation? Allocations only for
stuff that will clearly eventually be published as an RFC? What sort
of review is the expert expected to do? The more text one can give
here, the less confusion there will be later should people disagree
with the decision of the expert.

      The LMP Sub-object Class name space should be allocated as follows:
      pursuant to the policies outlined in [RFC2434], the numbers in the
      range of 0-127 are allocated by Standards Action, 128-247 are
      allocated through an Expert Review, and 248-255 are reserved for
      Private Use.

seems wrong. the sub-object assignment policy should be determined by
the Class. I.e., when you create a class, you define what the policy
should be for sub-classes. For some sub-classes, FCFS might be fine,
for others maybe only standards action. One-size fits all doesn't seem
right. I'd suggest something like:

      The policy for allocating values out of the LMP Sub-object Class
      name space is part of the defintion of the specific Class
      instance. When a Class is defined, its definition must also include
      a description of the policy underwhich sub-objects are allocated.

note: that also means this needs to be done for all of the sub-objects
that are defined in this document.

      The LMP Object Class type name space should be allocated as follows:
      pursuant to the policies outlined in [RFC2434], the numbers in the
      range 0-111 are allocated by Standards Action, 112-119 are allocated
      through an Expert Review, and 120-127 are reserved for Private Use.

ditto