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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sun, 16 Feb 2020 08:11:57 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document: it seems simple and easy :-)

Nevertheless, please find below some non-blocking COMMENTs (and I would
appreciate a response from the authors) and NITS.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- 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 ?

-- 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 ?

-- Section 2 --
"that need addressing via unicast Router Solicitation messages" is unclear to
me... Is to do SLAAC ? or look for an actual router?

Add a reference + acronym expansion to RPL at first use.

"This field provides the suffix (IID)" please expand interface ID and, on my
side, I do not like naming the IID as a suffix.

-- Section 5 --
Reading and applying RFC 8126 (how to write IANA considerations) would be
beneficial.

== NITS ==

-- Abstract --
Suggest to expand TSCH at first use.

-- Section 1.3 --
Unsure whether "reasons: First, there" should have a capitalized "First".

There are also many acronyms that should be expanded at first use (I stopped
commenting about those).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Feb 2020 17:00:55 +0100

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 <[email-masked]> 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".

    > 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.

    > -- 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  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 17 Feb 2020 18:05:21 +0000

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" <[email-masked]> wrote:

    These changes are at:

    

    
    
    I expanded the IE.

    
    
    Done.

    

    

    
    I'll remove First :-)