Re: [6tisch] Éric Vyncke's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-12: (with COMMENT)

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

Michael

Thank you for the quick reaction and the changes in the document. I am still in favor of a better phrasing for "that need addressing via unicast Router Solicitation messages", using a sentence around SLAAC would probably be more readable but this is up to you.

Regards and see you in your own country in a couple of weeks ;-)

-éric

On 17/02/2020, 17:01, "Michael Richardson" <[e-mail]> wrote:

    
    These changes are at:
          https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/0a806e63e65f2ef0fe2c4a5086b653d9fb0c3ff6
    and will be in -13 to be posted in a few minutes.
    
    Éric Vyncke via Datatracker <[e-mail]> wrote:
        > -- Abstract -- "announce the presence of the network" makes me
        > wonder... Do nodes announce the network ? or do nodes announced THEIR
        > presence in the network ? or do router nodes announce the network? or
        > am I too unfamiliar with TSCH ?
    
    I have changed the Abstract to say "routers announce".
    Noting that in a 6tisch world, most things are routers.
    
        > -- Section 1.2 -- Please expand "ASN" at first use. I guess that this
        > is not the usual AS Number ;-)
    
        > -- Section 1.3 -- Please add a reference for "broadcast aloha slot".
    
        > Isn't the word "IETF" in "defines a new IETF Information Element (IE)"
        > redundant in an IETF document ?
    
    The name of the Registry is:
        https://www.iana.org/assignments/ieee-std-802.15.4-ietf-ie-subtype-ids/ieee-std-802.15.4-ietf-ie-subtype-ids.xhtml#ieee-std-802.15.4-ietf-ie-subtype-ids-1
        IEEE Std 802.15.4 IETF IE Subtype IDs
    
    I expanded the IE.
    
        > -- Section 2 -- "that need addressing via unicast Router Solicitation
        > messages" is unclear to me... Is to do SLAAC ? or look for an actual
        > router?
    
    Yes, the point is to avoid multicast RS/RAs.
    If for reason, the announcing node is *not* a router, it should not set the R bit.
    Otherwise, it will answer unicast RS.
    
        > Add a reference + acronym expansion to RPL at first use.
    
    Done.
    
        > "This field provides the suffix (IID)" please expand interface ID and,
        > on my side, I do not like naming the IID as a suffix.
    
    I will remove the word suffix, and just say "Interface ID"
    
        > -- Section 5 -- Reading and applying RFC 8126 (how to write IANA
        > considerations) would be beneficial.
    
    okay, I'll review it again and fix this to the standard way.
    
        > == NITS ==
    
        > -- Abstract -- Suggest to expand TSCH at first use.
    
    I'm always uncomfortable with expansions in the Abstract, but I'll do that.
    
        > -- Section 1.3 -- Unsure whether "reasons: First, there" should have a
        > capitalized "First".
    
    I'll remove First :-)
    
        > There are also many acronyms that should be expanded at first use (I
        > stopped commenting about those).
    
    okay, I'll check again and make sure.
    
    -- 
    ]               Never tell me the odds!                 | ipv6 mesh networks [ 
    ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
    ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [