Re: [6tisch] updates to 6tisch-terminology document

Michael,

Pascal (thanks!) created http://tools.ietf.org/wg/6tisch/trac/ticket/32.

Let's discuss these terms at the call tomorrow, and Maria Rita or myself
can add them to the draft after we reach consensus both on the call and ML.

Personally, +1 on those definitions.

Thomas

On Thu, Dec 4, 2014 at 1:34 PM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> In order to support the security parts of the architecture document, I
> would
> like to propose the following text be added to the 6tisch-terminology
> document:
>
>    JCE                 the Join Coordination Entity.  This acronym is
>                        chosen to parallel the PCE.
>
>    joining node        The newly unboxed constrained node that needs to
>                        join a network.
>
>    join protocol       the protocol which secures initial communication
>                        between the joining node and the JCE
>
>    join assistant      A constrained node near the joining node that
>                        will act as it's first 6LR, and will relay
>                        traffic to/from the joining node.
>
>    unique join key     a key shared between a newly joining node, and
>                        the JCE.  This key supports smaller installations
>                        for which asymmetric methods are considered too
>                        large
>
>    production network  A 802.15.4e network whose encryption/
>                        authentication keys are determined by some
>                        algorithm/protocol.  There may have network-wide
>                        group keys, or per-link keys.
>
>    production network key  A L2-key known by all authorized nodes, used
>                        for multicast messages
>
>    per-peer L2 key     a key that results from an exchange (such as MLE)
>                        that creates a pair-wise L2 key which is known
>                        only to the two nodes involved,
>                        [I-D.piro-6tisch-security-issues] calls this a
>                        LinkKey
>
>    The following terms are used in this document and come from other
>    documents:
>
>    DevID               [IEEE.802.1AR] defines the secure DEVice
>                        IDentifier as a device identifier that is
>                        cryptographically bound to the device and is
>                        composed of the Secure Device Identifier Secret
>                        and the Secure Device Identifier Credential.
>
>    IDevID              The Initial secure DEVice IDentifier (IDevID) is
>                        the Device Identifier which was installed on the
>                        device by the manufacturer.
>
>    LDevID              A Locally significant secure DEVice IDentifiers
>                        (LDevIDs) is a Secure Device Identifier
>                        credential that is unique in the local
>                        administrative domain in which the device is
>                        used.  The LDevID is usually a new certificate
>                        provisioned by some local means, such as the 6top
>                        mechanism defined in this document.
>
>    CoAP                The CoAP protocol, defined in [RFC7252] is an
>                        HTTP-like resource access protocol.  CoAP runs
>                        over UDP.
>
>    DTLS                The datagram version of TLS, defined in
>                        [RFC6347], and which can be used to secure CoAP
>                        in the same way that TLS secures HTTP.
>
>    ARO                 [RFC6775]defines a number of new Neighbor
>                        Discovery options including the Address
>                        Registration Option
>
>    DAR/DAC             [RFC6775]defines the Duplicate Address Request
>                        and Duplicate Address Confirmation options to
>                        turn the multicasted Duplicate Address Detection
>                        protocol into a client/server process
>
>    EARO                [I-D.thubert-6lo-rfc6775-update-reqs]extends the
>                        ARO option to include some additional fields
>                        necessary to distinguish duplicate addresses from
>                        nodes that have moved networks when there are
>                        mulitple LLNs linked over a backbone.
>
>
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>