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

[Michael Richardson <[e-mail]>]

I am reading:
   https://www.rfc-editor.org/authors/rfc9032-rfcdiff.html (side-by-side)

These are my comments, and I see that almost all of them should be taken with
a grain of salt.  I grew up in a bilingual Canadian province (EH!) with the
highest Tim Horton's per-capita and nobody actually taught me English in school.
(Mon Francais est aussi un poutine)


You changed:
    Neighbor Discovery (ND) could even more scarce.
to  Neighbor Discovery (ND) could be even scarcer.

My limited experience with many readers is that although "scarcer" is a word
and means exactly what we need it to, that it isn't as well understood.

You changed:
   1.  Use of a multicast slot by even a non-malicious unauthenticated
       node for a Router Solicitation (RS) may overwhelm that time slot.

   2.  It may require many seconds of on-time before a new pledge
       receives a Router Advertisement (RA) that it can use.

to:

1.  Use of a multicast slot by even a non-malicious unauthenticated
    node for an RS may overwhelm that timeslot.
2.  It may require many seconds of on-time before a new pledge
    receives an RA that it can use.

I had explicitely expanded RS and RA a second time here, because I found that
many Layer 2 knowledgeable reasons were not as familiar with these Layer 3
terms, but that saying it again helped them get it.
I know that this goes against "define it the first time", but I felt that the
Introduction needed to be more easily understood.

You changed "an RPL" to "a RPL" in:
    is to serve as a RPL parent [RFC6550] within a particular network

and this just sounds wrong to me.  I dunno...

I'm pretty happy with the entire document as you've edited so..

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