Subject: Re: [6tisch] [IANA #1160596] expert review for draft-ietf-6tisch-enrollment-enhanced-beacon (ieee-std-802.15.4-ietf-ie-subtype-ids)

From: Michael Richardson <[email-masked]>
Date: Fri, 14 Feb 2020 17:20:37 +0100

Tero Kivinen <[email-masked]> wrote:
    > Sabrina Tanamal via RT writes:
    >> As the designated experts for the IEEE Std 802.15.4 IETF IE Subtype
    >> IDs registry, can you review the proposed registration in
    >> draft-ietf-6tisch-enrollment-enhanced-beacon for us? Please see 
    >> 
    >> https://tools.ietf.org/html/draft-ietf-6tisch-enrollment-enhanced-beacon-08

    > I checked the -09 version and it seems the actual contents of the IE
    > is mostly well defined, but description of the some of the fields is
    > not very well defined. For example in section 2 the text:

    > P  if the Proxy Address P-flag is set, then the lower 64-bits of the
    > Join Proxy's link-local address follows the network ID.  If the
    > Proxy Address bit is not set, then the Link Layer address of the
    > Join Proxy is identical to the Layer-2 8-byte address used to
    > originate this enhanced beacon.  In either case, the destination
    > layer-2 address of this beacon may use the layer-2 address which
    > was used to originate the beacon.

    > I have no idea what the last sentence of that paragraph is trying to
    > say.

I have clarified this by moving most of this text into the section on
the Join Proxy lower-64, leaving just the fact that the P-bit indicates
of the Join Proxy lower-64 is present.

The last sentence is wrong, thank you for catching this.
I have removed it. It intended to say that join traffic may use this
address as the destination, but I don't think it adds anything to say that
here.

here are the changes:
https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/9cd43a339c4d3f35ac024f6070ff37ba27053f05

    >> The IESG has asked us to set a two-week deadline for registration
    >> reviews. The due date for this request is 2020-02-04.  

    > The actual allocation would be ok, but before actual numbers are
    > allocated, it would be better to make sure there is no need to change
    > the format anymore, thus it would be good to make sure that the
    > document is stable enough and almost finished before this is done.

    > The current document seems to still have lots of other issues, so
    > delaying to get fixes to those might be approriate. 

I would like to know what other changes you think will be needed to the field
definitions.

-- 
]               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: Michael Richardson <[email-masked]>
Date: Fri, 14 Feb 2020 17:42:39 +0100

In addition to the comments from Tero, Pat Kinney provided a marked up
review, which I have placed at
  http://www.sandelman.ca/SSW/ietf/6tisch/kinney-enrollment-enhanced-beacon-edits-2020.html

It arrived in some Apple proprietary format, having red-lines and
replacements, which after some grumpiness, I determined to some binary junk
followed by HTML. 
The crux is that Pat prefers "transmit" to "send" and "receive" to "hears",
and I accept his wisdom about my use of vernacular language.

{I am now contemplating about writing an RFC in Belta Creole. 
   _Operational Considerations for Interstellar Wormholes_}

The changes from Pat are now at:
   https://bitbucket.org/6tisch/6tisch-join-enhanced-beacon/commits/8b18e8ae818c80f09b9b598bde8504f8d566a0d7