Re: [6tisch] [Gen-art] Genart last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

Tim, thanks for your review. Michael, thanks for your response. I entered a DISCUSS ballot to check on the address generation mechanism for use with SLAAC.

Best,
Alissa

> On Jan 16, 2020, at 8:21 PM, Tim Evens (tievens) <tievens@cisco.com> wrote:
> 
> Excellent, thanks! 
> 
> On 1/16/20, 5:03 PM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
> 
>    Tim Evens via Datatracker <noreply@ietf.org> wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
> 
>    Thank you.
> 
>> In section 1.2,
>> "These slots are rare, and with 10ms
>> slots, with a slot-frame length of 100, there may be only 1 slot/s
>> for the beacon."
> 
>> IMO, this could be reworded to increase clarity. For example, "Considering 10ms
>> slots and a slot-frame length of 100, these slots are rare and could result in
>> only 1 slot for a beacon."
> 
>    Reworded as you suggest:
> 
>     There is a limited number of timeslots designated as a broadcast slot by
>     each
>     -router in the network. These slots are rare, and with 10ms slots, with a
>     slot-frame length of
>     -100, there may be only 1 slot/s for the beacon.
>     +router in the network. Considering 10ms slots and a slot-frame length of
>     100,
>     +these slots are rare and could result in only 1 slot/s for a broadcast,
>     which
>     +needs to be used for the beacon.  Additional broadcasts for Router
>     +Advertisements, or Neighbor Discovery could even more scarce.
> 
>> In section 1.3,
>> "At layer 3, [RFC4861] defines a mechanism by which nodes learn about
>> routers by listening for multicasted Router Advertisements (RA)."
> 
>> Would it be possible to reword to not use "multicasted?"  For example,
>> "by receiving multicast Router Advertisements (RA)."
> 
>    done.
> 
>> "no RA is heard within a set time, then a Router Solicitation (RS) may
>> be multicast,"
> 
>> "may be sent as multicast" might be more clear.
> 
>    done.
> 
>> In section 2,
>> "proxy priority  this field indicates the willingness fo the sender to
>> act as join proxy.  Lower value indicates greater willingness"
> 
>> Typo "fo"
> 
>    fixed.
> 
>> IMO, it would be clearer if the field name in the protocol header
>> matches the description for it. For example, "Proxy priority (proxy prio)"
> 
>    okay.
> 
>> In Section 4,
>> "An interloper with a radio sniffer would be able to use the network
>> ID to map out the extend of the mesh network."
> 
>> extend or extent?
> 
>    extent, thank you catching that.
> 
>    All this in -07 about to be published.
> 
> 
> 
>    --
>    Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>     -= IPv6 IoT consulting =-
> 
> 
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art