Re: [C310] AUTH48 [JM]: RFC 9032 <draft-ietf-6tisch-enrollment-enhanced-beacon-14.txt> NOW AVAILABLE

[Michael Richardson <[e-mail]>]

[e-mail] wrote:
    > 1) <!--[rfced] Based on Michael's reply on the c310 list, we have
    > updated this title as follows. Please review.

    > Original: IEEE 802.15.4 Information Element encapsulation of 6TiSCH
    > Join and Enrollment Information

    > Current: Encapsulation of 6TiSCH Join and Enrollment Information
    > Elements

    > Also, should the abbreviated title (which appears in the running header
    > of the PDF file) be updated? Seems "ICMP" is not mentioned within the
    > document.

    > Current: IE for ICMPv6

I guess this is historical, because the first versions of the document could
carry arbitrary ICMPv6 payloads!

So, the abbreviated title should probably be "Enroll Beacon"

    > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
    > the title) for use on https://www.rfc-editor.org/search.
    -->

BRSKI
Enroll
zero-touch
DODAG balancing
LLN balancing

    > 3) <!-- [rfced] Would the following improve the readability of the
    > sentence?  We found Section 4.5.2 to provide a better overview of EB
    > roles (https://www.rfc-editor.org/rfc/rfc8180#section-4.5.2).  Should
    > the section number here be changed?

    > Current: As explained in Section 6 of [RFC8180], the EB has a number of
    > purposes: synchronization of the Absolute Slot Number (ASN) and Join
    > Metric, carrying the timeslot template identifier, carrying the channel
    > hopping sequence identifier, and indicating the TSCH slotframe.

    > Perhaps: As explained in Section 4.5.2 of [RFC8180], the EB has a
    > number of purposes: it carries synchronization information such as the
    > Absolute Slot Number (ASN) and Join Metric and identifiers for the
    > timeslot template and the channel hopping sequence, and it indicates
    > the TSCH slotframe.
    -->

Yes.

    > 4) <!-- [rfced] In the following sentence, perhaps "Join Proxy" instead
    > of "Join Assistant" is meant?

    > Current: 3.  A new pledge may have to receive many EBs before it can
    > pick an appropriate network and/or closest Join Assistant to attach to.
    -->

Yes, please change.  JA was a term used in earlier minimal-security drafts.
(I still prefer it, but consensus was for Join Proxy)

    > 5) <!--[rfced] How may this be rephrased to clarify and to avoid using
    > the citation as an adjective?

    > Current: The PANID is part of the [IEEE.802.15.4] Layer 2 header: it is
    > ...

    > Perhaps: The PANID is part of the Layer 2 header as defined in
    > [IEEE.802.15.4]: it is ...
    -->

Okay.

    > 6) <!-- [rfced] Please clarify this sentence. Does "conceived of in a
    > similar fashion as" mean "considered similar to"?

    > Current: The PANID provides a context similar to the Extended Service
    > Set ID (ESSID) in 802.11 networking and can be conceived of in a
    > similar fashion as the 802.3 Ethernet VLAN tag in that it provides
    > context for all Layer 2 addresses.

    > Perhaps: The PANID provides a context similar to the Extended Service
    > Set ID (ESSID) in 802.11 networking and can be considered similar to
    > the 802.3 Ethernet VLAN tag in that it provides context for all Layer 2
    > addresses.
    -->

Yes, that's better.


    > 7) <!-- [rfced] We note that the following is inconsistently
    > capitalized. How would you like it to be capitalized?

    > PAN priority field - 3 instances pan priority field - 3 instances
    -->

"PAN" needs to be in upper case.  It stood for Personal Area Network,
from a time when 802.15.4 was going to be all about wearables, but at this
point it's just "PAN".

    > 8) <!-- [rfced] May we capitalize "reserved" here to match the
    > formatting of the rest of the definition list?

    > Current: res: reserved bits MUST be ignored upon receipt and SHOULD be
    > set to 0 when sending.

    > Perhaps: res: Reserved bits MUST be ignored upon receipt and SHOULD be
    > set to 0 when sending.

Yes, I like it capitalized like this.

     > Or perhaps: res: Any reserved bits MUST be ignored upon receipt and
     > SHOULD be set to 0 when sending.
     -->

    > 9) <!-- [rfced] In the sentence below, is perhaps "Join Proxy" instead
    > of "enrollment proxy" meant?

    > Current: A priority of 0x7f indicates that the announcer should never
    > be considered as a viable enrollment proxy.
    -->

So, we renamed the document from Join to Enrollment, because "Join" means
something different to ROLL WG types.
In ROLL documents yet to arrive at the RPC, both terms are used in the same
document.

It would be better to leave this field as Enrollment Proxy.
If I could have convinced 6tisch-minimal-security to change too, I would be
happier.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide