Excellent, thanks! 

On 1/16/20, 5:03 PM, "Michael Richardson" <mcr+i...@sandelman.ca> wrote:

    Tim Evens via Datatracker <nore...@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+i...@sandelman.ca>, Sandelman Software Works
     -= IPv6 IoT consulting =-
    
    
    
    

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to