draft-ietf-ccamp-lmp-08.txt

[Ted Hardie <hardie@qualcomm.com>]

DISCUSS

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: