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

Attachment: signature.asc
Description: PGP signature

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

Reply via email to