Thank you for this review! Pascal Thubert (pthubert) <[email protected]> wrote: > Page2 Introduction: there?s an EDNOTE: field. It could be useful but > not necessary to make the proposed addition. Is the author willing to? > Or should a coauthor help?
} EDNOTE: Explain why broadcasts are rare, and why we need them. What the
} Enhanced Beacon is, and what Information Elements are, and how the IETF has a
} subtype for that area. Explain what kind of things could be placed in
} Information Elements, how big they could be, and how they could be
} compressed.
If the WG feels that this section needs to be filled in then I will work with
Diego to fill it in. Clearly less text is easier to review, but I think
that non-6tisch reviewers will need some understanding of why we do what
might be considered layer violations to pack all this L3 and routing
information into a L2 object.
I would prefer to write text like:
"[XYZ] explains how the availability of the broadcast is limited.
[ABC] details how the Enhanced Beacon is already used to do schedule
synchronization"
I would dearly like help from the WG on this text. Now that the architecture
is more stable, perhaps they are just normative architecture document
references?
> Suggestion to also refer to https://tools.ietf.org/html/
> draft-ietf-6tisch-architecture for terminology
Done.
> ?
> At layer 3, [RFC2461] defines a mechanism by
> ?
> Please use RFC 4861
done.
> Section 1.3
> There?s a XXX leftover. What is the intention?
No idea, removed.
> proxy priority the proxy prority value contains a number from 0 to
> 0x7f. Lower numbers are considered to be a higher preference. A
> priority of 0x7f indicates that the announcer should never be
> considered as a viable enrollment proxy. Lower value indicates
> willing to act as a Join Proxy as described in
> [I-D.ietf-6tisch-minimal-security]. Only unenrolled pledges look
> at this value.
> ?
> Maybe indicate first that the field indicates the willingness to act as
> join proxy? Also, a typo (prority).
Fixed.
> P and R bits definition; though it is quite obvious, the description
> does not say that ?R? is the RA bit and that ?P? is the Proxy Address
> bit. Maybe use the term flag, like in? the ?P? flag?.
Okay.
> join-proxy lower-64 if the P bit is set, then 64 bits (8 bytes) of
> address are present. The Link Layer address of the Join Proxy is
> fe80 (as for any Link Layer address), and the bits given in this
> field.
> ?
> I think you mean Link-Local not link layer? What about:
Thank you, good catch.
> join-proxy Interface ID if the P bit is set, then 64 bits (8 bytes)
> of
> address are present. This field provides the suffix of the
> Link_Local
> address of the Join Proxy. The associated prefix is well-known as
> fe80::/64.
> ?
> In a 6tisch network, where RPL is u
> ?
> Missing reference to RFC 6550
added.
> ?
> 2.1. Protocol Example
> Here will be three examples of processing.
> ?
> Do you intend to fill that section?
At this point, I have no example packets, so I will remove that section.
I have posted -02 with these changes.
What lacks now is only a decision on how much text to put in the intro to
explain broadcasts.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
