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

["Prof. Diego Dujovne" <[e-mail]>]

Jean,
         I have read it, I did not catch any missing items, so I approve
the text as it is.
Regards,

                            Diego Dujovne

Le jeu. 13 mai 2021 à 18:21, Jean Mahoney <[e-mail]> a écrit :

> Diego, Michael,
>
> Thank you for your quick responses! We have updated the document based on
> your feedback:
>
>    https://www.rfc-editor.org/authors/rfc9032.txt
>    https://www.rfc-editor.org/authors/rfc9032.pdf
>    https://www.rfc-editor.org/authors/rfc9032.html
>    https://www.rfc-editor.org/authors/rfc9032.xml
>    https://www.rfc-editor.org/authors/rfc9032-diff.html
>    https://www.rfc-editor.org/authors/rfc9032-auth48diff.html
>
> We'll await further word from you regarding other AUTH48 changes and/or
> approval.
>
> Best regards,
> RFC Editor/jm
>
> On 5/12/21 6:54 PM, Prof. Diego Dujovne wrote:
>
> Dear all,
>                I answer below.
> Regards,
>
>             Diego
>
> Le mer. 12 mai 2021 à 18:15, Michael Richardson <[e-mail]> a
> écrit :
>
>>
>> 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)
>>
>>
> Neither am I a native speaker, so I am glad to learn from your suggestions.
>
>
>>
>> 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.
>>
>>
> Agreed.
>
>
>> 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.
>>
>
> I agree. I see that "an" is used because of the pronunciation of the
> acronyms RA and RS.
>
>
>>
>> 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...
>>
>
> In RFC 6550 it is used as "a RPL", because it is pronounced RPL as "ripl"
> I guess.
>
>
>>
>> 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
>>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl
> (56 2) 676 8125
>
>

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125