[Ballot comment]

Thanks for addressing my discuss points.

I've left the comments below since I've not had a chance to check
if they were addressed or not. Feel free to let me know if there's
anything else to talk about wrt those. (But they're comments so
only if you want to talk about 'em:-)

Stephen.

used to be discuss point #2:
1.3 - Why would probabilistic uniqueness of non-EUI-64-derived
addresses not be sufficient in some networks? If it is, then the
"must be either assigned or checked" seems wrong.

I didn't update the comments below for -19

General - The logic as to why mesh-under and route-over are the
most important topologies is not explained here and I don't see why
its most valuable to tackle this problem in a topology-specific
manner. It's also a shame that 1.3 needs to have all nodes
implementing this to get any benefit and that each node must be
part of only one network. (The latter is particularly unfortunate
given that sleeping node wake times might cause such a condition
over time.) However, this is maybe not actually a problem since the
protocol doesn't seem to be really specific to those topologies -
is that right? If so, then I'd suggest weakening the language to
say that e.g. the authors or WG are more interested in those
topologies, but that the protocol might work in other contexts too.

Various places: - What's a non-transitive wireless link?

Abstract - is a bit awkwardly written, some polish could usefully
be applied.

1.1 - I don't get the relevance of the "primarily two types" of
lowpan topology on p5. Only the last sentence of that paragraph
seems relevant or necessary. Similarly with section 1.2 which,
other than introducing terminology seems unnecessary.

1.3 - A number of the goals say "optimize" - is that meant to mean
"improve" or "make the best"? In the latter, case, that would seem
to require more work, e.g. to be able to compare approaches via
metrics or something. Since I don't think that's really needed, I'd
say s/optimize/improve/g would be more correct. (Similarly for
s/minimize/reduce/)

1.4 - I don't know why the following assumption is needed: "A
6LoWPAN is configured to share one or more global IPv6 address
prefixes to enable hosts to move between routers in the 6LoWPAN
without changing their IPv6 addresses." Why is it necessary to say
this? (The spec would be clearer if that were clear I think.)

1.4 - please don't use the reference as part of the sentence
"[I-D.ietf-6lowpan-hc]" being the one that stood out - surely that
has a name?

1.5 - I can't parse the first sentence.

3.2 - s/required/REQUIRED/g? and is it clear what it means to
"REQUIRE" something of a lowpan? (Rather than a node)

3.3 - "suspects" seems too vague, suggest giving at least one
precise (common) condition, and if necessary saying there may be
others too

3.3. "The registration can fail (an ARO option returned to the host
with a non-zero Status)..." the parenthetic clause isn't clear
there. Suggest splitting the sentence.

3.4 - What's context dissemination? Maybe needs a forward ref?

3.5 - How does packet loss impact on "successfully registers with"?
(Just wondering.)

4.3 - where is "sequence number arithmetic" defined?

5.3 - What are "theses packets"? Maybe a way to get a few PhDs?
That'd be nice:-)

5.3 - Where is "binary exponential backoff" defined?

5.4.3 - Where is the Default router lifetime defined?

5.5.3 - What does "no more default routers" mean?

5.8.1 - seems wrong to say a host should consider how quickly
topology changes, how'd it know in general?

6.2 - initialising an interface "more or less" like something is a
vague for a spec.

8.1.2 - "similarly" seems vague

13 - The introductory text here is confusing - what's this section
for really? Does "deploy" mean "use"? I'd prefer the latter term.