#127: Optional/Mandatory language
As part of LC review on nd-13 some issues on the optional/mandatory
language have been brought up:
From Carsten's review:
{{{
Some of the language around optional/mandatory is unclear (this is a
superset of Jongsoo Jeong's point). Saying that message X is optional is
meaningless. The specification must be clear for each kind of node
whether (or in what circumstances) that node is expected to be able to
generate message X and/or understand/act on message X.
Simple example: 6CO cannot be "optional" if there is context the hosts are
expected to act on and which they haven't received through some pre-
configuration.
}}}
The solution for this could be to do a review of the optional language,
and create a matrix for each node type and what messages they are able to
process.
From Samita:
{{{
In the draft, we have defined ABRO, 6CO, multihop DAD as
optional. But what is the recommendation to the implementers? Is it
equivalent to SHOULD or MAY? Does it need any clarification that they
SHOULD be implemented ?
}}}
The authors recommend that the optional features SHOULD be implemented,
but this needs to be discussed in the WG.
--
--------------------------------+-------------------------------------------
Reporter: z...@… | Owner: z...@…
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: nd | Version:
Severity: - | Keywords:
--------------------------------+-------------------------------------------
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/127>
6lowpan <http://tools.ietf.org/6lowpan/>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
