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@xxxxxxxxx> wrote: > > 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 =- > > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
