Re: [secdir] Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you Kyle for the review: nits are nits but let's fix them when the last call ends (later today).

Dear authors, I would appreciate it if a new revision was uploaded on Tuesday 15th (i.e. after the last call expiration) fixing all issues detected in the last call (see Gorry's email dated 2nd October) and Kyle's one below.

Once done, I will proceed with the publication process

Regards and thank you in advance

-éric (shepherding AD for this document)


On 14/10/2019, 05:33, "Kyle Rose via Datatracker" <[e-mail]> wrote:

    Reviewer: Kyle Rose
    Review result: Has Nits
    
    I have reviewed this document as part of the security directorate's ongoing
    effort to review all IETF documents being processed by the IESG.  These
    comments were written primarily for the benefit of the security area directors.
     Document editors and WG chairs should treat these comments just like any other
    last call comments.
    
    I marked this "ready with nits" because I see no serious security or privacy
    considerations, but I'm confused by the wording in section 7, which begins:
    
    q( This section will provide some recommendations about the usage and
    combinations of the multicast enhancements described in Section 4 and Section
    5. )
    
    and then proceeds to provide little in the way of such recommendations. Maybe
    the phrasing here is just awkward?
    
    Nits:
    
    Reference dot11aa
    (https://standards.ieee.org/findstds/standard/802.11aa-2012.pdf) gives me a
    404. Maybe I simply lack the appropriate decoder ring?
    
    The IETF meeting network is referenced three times in section 5.1. For example,
    
    q( The distribution of users on wireless networks / subnets changes from one
    IETF meeting to the next (e.g SSIDs are renamed, some SSIDs lose favor, etc). 
    This makes utilization for particular SSIDs difficult to predict ahead of time,
    but usage can be monitored as attendees use the different networks. )
    
    This feels like a non-sequitur. Maybe some introductory text about using the
    IETF meetings as an exemplar would make this read a little better, but it seems
    like the advice to operators here should be generic and not connected to
    particular goals for network connectivity at IETF meetings.