#134: Editorial fixes for ND-15
Editorial Comments from Colin :
Section 1.3 ( Applicability, Assumption and Goals)
Consolidation or deletion of a few redundant bullet points
Comment:
1)
o Optimize Neighbor Discovery with a mechanism that is minimal yet
sufficient for the operation in both mesh-under and route-over
configurations.
o Make the host to router interaction the same whether mesh-under or
route-over is used.
*These last two points could probably be consolidated into one point.
Updated text: (Removed the 2nd bullet)
o Optimize Neighbor Discovery with a mechanism that is minimal yet
sufficient for the operation in both mesh-under and route-over
configurations.
2)
o Minimize signaling by avoiding the use of multicast flooding and
reducing the use of link-scope multicast messages.
o Optimize the interfaces between hosts and their default routers.
*This could also also be fit in with the first two points I think
==> We like to keep the text as it is for clarity
3)
o Support for sleeping hosts.
o Minimize the complexity of nodes.
*Point can be deleted, nobody wants complex nodes, and it's already a goal
to
make the mechanism 'minimal', which implies to me the nodes are not as
complex
==> Updated text: Deleted
Section 6.5.4 : (Next hop Determination for the Routers)
Current text:
It is the responsibility of the routing protocol to maintain on-link
information
about its registered neighbors. Tentative NCEs MUST NOT be used to
maintain on-link status.
Comment: NCE undefined
Comment: Refer to 5.6
Proposed Change:
It is the responsibility of the routing protocol of the router to maintain
on-link information
about its registered neighbors. Tentative NCEs MUST NOT be used to
determine on-link status of the registered nodes.
Section 8.2
Current text : ( contains unnecessary bracketed text)
(This is needed to
handle the case when multiple hosts try to register the same IPv6 address
at the same time.)
If no Neighbor Cache entry exists, then
Updated text: Removed brackets
And more updates suggested by Erik as follows:
It is true that we never define "NCE". But the first time we use that
acronym is in section 1.3 hence a reference in 6.5.4 doesn't seem that
useful.
I'd suggest the following edits to make things flow better.
In section 3.5 add "(NCE)" thus change FROM:
The use of explicit registrations with lifetimes plus the desire to
not multicast Neighbor Solicitation messages for hosts imply that we
manage the Neighbor Cache entries slightly differently than in
[RFC4861]. This results in three different types of NCEs and the
types specify how those entries can be removed:
TO:
The use of explicit registrations with lifetimes plus the desire to
not multicast Neighbor Solicitation messages for hosts imply that we
manage the Neighbor Cache entries (NCE) slightly differently than in
[RFC4861]. This results in three different types of NCEs and the
types specify how those entries can be removed:
We also need to cleanup the last bullet in section 1.3. It is a bit out of
place since it says a lot more than a goal or an assumption. I observe
that we have a sentence about mobility in section 3.3.
Thus I suggest in section 1.3 change FROM
If the
node loses connectivity with the default router involunterily,
then the default router does not know the node has moved until it
runs the unreachability detection. In order to optimize the time
for detecting unreachability of a run-away node, a default-router
may use link-layer indication or configure a lower NCE life-time
value and low registration life-time value - so that it can remove
the NCE of the run-away node as soon as possible.
TO
To handle the case when a
node loses connectivity with the default router involunterily,
the node should use a suitably low registration lifetime.
--
---------------------------------------------+------------------------------
Reporter: samita.chakrabarti@… | Owner: zach@…
Type: task | Status: new
Priority: major | Milestone:
Component: format | Version:
Severity: - | Keywords: editorial
---------------------------------------------+------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/134>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
