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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Excellent, thanks! 

On 1/16/20, 5:03 PM, "Michael Richardson" <mcr+ietf@xxxxxxxxxxxx> wrote:

    Tim Evens via Datatracker <noreply@xxxxxxxx> 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@xxxxxxxxxxxx>, Sandelman Software Works
     -= IPv6 IoT consulting =-
    
    
    
    

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux