Dale,
Thanks for your thorough review of draft-ietf-6lo-6lobac. Sorry that it has taken
so long to get back to you. Can you take a look at the new version and see if
it addresses your concerns? Comments inline...
On Sun, Nov 13, 2016 at 2:26 PM, Dale R. Worley <worley@xxxxxxxxxxx> wrote:
Comments on draft-ietf-6lo-6lobac-06
(This is probably the best-written Internet-Draft that I have ever
read.)
Technical issues:
6. Stateless Address Autoconfiguration
This section defines how to obtain an IPv6 Interface Identifier. The
general procedure for creating a MAC-address-derived IID is described
in [RFC4291] Appendix A, "Creating Modified EUI-64 Format Interface
Identifiers", as updated by [RFC7136].
The IID SHOULD NOT embed an [EUI-64] or any other globally unique
hardware identifier assigned to a device (see Section 12).
<kel>
Section 6 has been reworked to more clearly distinguish between two types
of IIDs: "MAC-address-derived" and "semantically opaque". The first is
recommended for link-local addresses because it enables maximum IPv6
header compression efficiency. Since MS/TP is used primarily as a field
bus, I expect most installations will only ever involve link-local traffic between
an MS/TP device and a local controller.
For applications where the MS/TP device is a client or server with routable
addresses, the spec strongly recommends generating a semantically opaque
IID, with 64 bits of entropy, for each global address.
</kel>
I have a hard time correlating these two paragraphs. At first read,
the first paragraph describes how an IID is to be constructed from a
MAC address, and the second one specifies that the IID should not
contain a MAC address. Reading more carefully, it seems that the
intention is to refer to one of the methods of constructing IIDs that
are listed in section 2 of RFC 7136 which construct IIDs *from* MAC
addresses but the IIDs do not directly contain them:
<kel>
The recommended method of generating IIDs from the 8-bit node address
is described, so the reference to EUI-64 has been removed as it was
confusing (and MS/TP devices don't typically have static 48- or 64-bit
hardware addresses.)
</kel>
In addition to IIDs formed from IEEE EUI-64 addresses, various new
forms of IIDs have been defined, including temporary addresses
[RFC4941], Cryptographically Generated Addresses (CGAs) [RFC3972]
[RFC4982], Hash-Based Addresses (HBAs) [RFC5535], and ISATAP
addresses [RFC5214].
Though, strctily speaking, those formats aren't introduced due to RFC
7136 updating RFC 4291, but rather by RFC 4941 etc. doing so.
But if my understanding is correct, it would help greatly if this text
was revised to point more directly to the text that is relevant, as my
reflexive behavior is to read Appendix A of RFC 4291, which only
discusses embedding MAC addresses in IIDs.
It would also help to explain what the important difference is between
"MAC-address-derived" and "embed an [EUI-64] or other globally unique
hardware identifier" -- I think the critical distinction is that with
the former, knowing the MAC address is not sufficient for an attacker
to guess the IID, but I'm left to guess that.
Editorial issues:
1. Introduction
a) MS/TP devices typically have a continuous source of power
I think this isn't quite how you want to phrase it, since a battery is
a "continuous source of power". Perhaps "typically have mains power".
1.4. Goals and Constraints
The primary goal of this specification is to enable IPv6 directly on
wired end devices in building automation and control networks by
leveraging existing standards to the greatest extent possible. A
secondary goal is to co-exist with legacy MS/TP implementations.
This doesn't seem to be as clear as it could be in a number of ways.
One issue is the distinction between "primary goal" and "secondary
goal". Naively it seems to me that both are necessary for success,
but as written it sounds like coexistence has in some way been
sacrificed or compromised in order to achieve the primary goal. But
it seems that draft-ietf-6lo-6lobac provides for complete coexistence.
Only the minimum changes necessary to support IPv6 over MS/TP were
specified in BACnet [Addendum_an] (see Section 1.3).
This sentence seems to mean that Addendum_an contains just enough
changes to MS/TP to allow draft-ietf-6lo-6lobac to be written. But
it's hard to tell what the significance of that is -- if Addendum_an
is *only* to support draft-ietf-6lo-6lobac, then the partitioning of
changes between Addendum_an and draft-ietf-6lo-6lobac is arbitrary,
and Addendum_an could have been made smaller by shifting some of its
content into draft-ietf-6lo-6lobac. And that contradicts the claim
that Addendum_is "minimum".
It seems that what is really meant is that Addendum_an support is
necessary for draft-ietf-6lo-6lobac support, or perhaps that the only
use of Addendum_an is to support draft-ietf-6lo-6lobac.
In order to co-exist with legacy devices, no changes are permitted to
the MS/TP addressing modes, frame header format, control frames, or
Master Node state machine as specified in BACnet [Clause9].
Another issue is that there are three "levels", as it were, that a
device can be designed to:
1. Clause9 alone
2. Clause9 with Addendum_an
3. Clause9, Addendum_an, and draft-ietf-6lo-6lobac
I assume that the three levels are upward compatible, in that you can
mix devices designed to all three levels on one network, and then any
two devices will interoperate at the highest level that they share.
But it seems that this could be stated much more clearly by just
saying that draft-ietf-6lo-6lobac is upward-compatible with devices
designed to Clause9 and with devices designed to Clause9 with
Addendum_an.
<kel>
ANSI/ASHRAE Standard 135-2016 was published late last year. This
version integrates the changes that were standardized in 135-2012
Addendum an, so there's no longer any jumping back and forth between
references.
Also, I didn't make it clear (outside of 6lo wg) that I can provide a copy
of [BACnet] Clause 9 to anyone who wants to reference it in the course
of reviewing the ID.
</kel>
It's not really clear what the phrase "no changes are permitted to"
applies to -- is it a description of draft-ietf-6lo-6lobac, or a
warning that there are certain constraints on devices that aren't
stated in this document?
<kel>
This is a statement on how to achieve co-existence. Hopefully the
context is clearer in the current version of the ID.
</kel>
2. MS/TP Mode for IPv6
Must all nodes that support IPv6 be master nodes?
<kel>
Yes, slave nodes cannot initiate async transmission. MS/TP nodes
are designed to ignore frames they don't understand (e.g. 6LoBAC).
</kel>
... implement the Receive Frame state machine specified in
[Clause9] as extended by BACnet [Addendum_an].
There seems to be an alternative use of "BACnet [Clause9]"
vs. "[Clause9]", and also "BACnet [Addendum_an]" vs. "[Addendum_an]".
The usage should be made consistent, and also aligned with the
definition:
BACnet: An ISO/ANSI/ASHRAE Standard Data Communication Protocol
for Building Automation and Control Networks
Does "BACnet" mean just Clause9 or Clause9 plus Addendum_an, or is it
a generic that applies to both sets of specifications?
<kel>
Due to the update to the base spec, these references have all been converted
to [BACnet] Clause 9. There is a single reference to [Addendum_an] for any
historians in the audience. [BACnet] refers to the latest version, ANSI/ASHRAE
Standard 135-2016.
</kel>
5. LoBAC Adaptation Layer
Implementations MAY also support Generic Header Compression (GHC)
[RFC7400] for transport layer headers. A node implementing [RFC7400]
MUST probe its peers for GHC support before applying GHC.
This would probably read better if the second "[RFC7400]" was written "GHC".
6. Stateless Address Autoconfiguration
concatenating a node's' 8-bit MS/TP MAC address to the seven octets
s/node's'/node's/
9. Multicast Address Mapping
When represented as
a 16-bit address in a compressed header (see Section 10), it MUST be
formed by padding on the left with a zero:
This would read more smoothly if "it" was "the broadcast link address"
and "a zero" was "a zero octet".
10. Header Compression
When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short
address") it MUST be formed by padding the MS/TP address to the left
with a zero:
Similarly, this would read more smoothly if "a zero" was "a zero
octet".
Appendix B. Consistent Overhead Byte Stuffing [COBS]
The minimum overhead of COBS is one octet per encoded field. The
worst-case overhead in long fields is bounded to one octet per 254,
or less than 0.4%, as described in [COBS].
This could be more informative as:
The minimum overhead of COBS is one octet per encoded field, and
the maximum overhead is ceiling(length/254) octets. In the limit
for very long fields, the overhead is less than 0.4%. For 1280
octet fields, the overhead is 0.47% and for 1500 octet fields, the
overhead is 0.39%.
<kel>
I punted on calculating percentages, assuming the reader could do the math.
I guessing it varies discretely between 50% for a 1-byte field and 0.39% for
a 254 byte field. The salient fact is the overhead is bounded to six bytes of
overhead for a 1500-byte MTU, but maybe I need to say that explicitly.
</kel>
Appendix C. Encoded CRC-32K [CRC32K]
BACnet [Addendum_an] specifies the CRC-32K (Koopman) polynomial.
"CRC-32K" is not bound at this point. Perhaps
BACnet [Addendum_an] specifies one of these, the CRC-32K (Koopman)
polynomial.
<kel>
I'm pretty sure I incorporated all of your editorial changes.
I'm pretty sure I incorporated all of your editorial changes.
</kel>
Thanks again, Kerry
Dale