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

Mike

Nothing urgent on my side but I will wait for this new revision before going forward with the publication process to avoid duplicate reviews.

Regards and thank you in advance

-éric

On 14/10/2019, 18:17, "Michael McBride" <[email protected]> wrote:

    Hi Eric,
    
    I spent a fair amount of time addressing your comments and figured we were near the finish line. Such is not the case.  I'll not be able address Gorry's extensive comments by tomorrow or this week. I should have an update sometime next week.
    
    thanks,
    mike
    
    -----Original Message-----
    From: Eric Vyncke (evyncke) <[email protected]> 
    Sent: Monday, October 14, 2019 12:10 AM
    To: Kyle Rose <[email protected]>; [email protected]; [email protected]
    Cc: [email protected]; [email protected]
    Subject: Re: Secdir last call review of draft-ietf-mboned-ieee802-mcast-problems-09
    
    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" <[email protected]> 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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstandards.ieee.org%2Ffindstds%2Fstandard%2F802.11aa-2012.pdf&amp;data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C77e1df14542647effbee08d750758f50%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637066338161419393&amp;sdata=%2BTgTdYtOEqx%2FaVK5%2FKDATO36ZE3%2Ba81GM%2BC9HLfxPro%3D&amp;reserved=0) 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.
        
        
    
    

_______________________________________________
MBONED mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mboned