Subject: [Int-dir] INT Dir Review : draft-ietf-6lo-6lobac

From: Brian Haberman <[email-masked]>
Date: Mon, 15 Aug 2016 10:14:18 -0400

I am an assigned INT directorate reviewer for this draft. These comments
were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherds should treat these comments just like
they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received.
For more details of the INT directorate, see
<http://www.ietf.org/iesg/directorate.html>.

Summary

This document is clearly written and informative. I just have a few
comments/questions that would be good to clear up prior to publication.

- Section 1.3 shows a padding option, but does not sufficiently describe
when/how to use it. Is there sufficient discussion in the BACnet spec on
the use of the padding option?

- In section 3, the document says that multicast is not supported at the
link layer so IPv6 multicast packets SHOULD be sent as broadcast. If
multicast is not supported, why is the requirement to broadcast only a
"SHOULD"? What other options could be used to disseminate the IPv6
multicast packets? This also applies to section 9.

- Section 6 uses the phrase "forwardable address". Do you really mean
"globally scoped address"? If so, why not just say that since "globally
scoped" is generally acceptable? If this is changed in section 6, it
also needs to be changed in section 12.

Regards,
Brian

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 15 Aug 2016 12:29:10 -0400

Hi Brian,

Thanks for the review.  The MS/TP (Master-Slave/Token Passing) specification
is embedded as clause 9 in the ISO/ANSI/ASHRAE 135-2012 spec.  It is open,
but not not free.  I can, however, provide a copy of the relevant sections
of the
BACnet spec for any IETF reviewer who would like them.  Answers inline...

On Mon, Aug 15, 2016 at 10:14 AM, Brian Haberman <[email-masked]>
wrote:

> The padding octet is discussed in BACnet sub-clause 9.2.3:

"Transmitter disable: A node shall not disable its EIA-485 driver until the
stop
bit of the final octet of a frame has been generated.  The node shall
disable its
EIA-485 driver within Tpostdrive  after the beginning of the stop bit of
the final
octet of a frame in order that it not interfere with any subsequent frame
transmitted by another node. This specification allows, but does not
encourage,
the use of a "padding" octet after the final octet of a frame in order to
facilitate
the use of common UART transmit interrupts for driver disable control. If a
"padding" octet is used, its value shall be X'FF'. The "padding" octet is
not
considered part of the frame, that is, it shall be included within T
postdrive .

> This was changed to a SHOULD during WG review of the document.  The
other option is to serially unicast packets with multicast destination
addresses
(though I have no idea why you'd want to do this over a wired medium).

> This is an attempt to align with the definitions of RFC 6890 (although I
failed to add this RFC to the references and will do so in the next
revision).
By using this term, I mean "non link-local", that is, global as well as
unique
local addresses.

HTH, Kerry

---

From: Brian Haberman <[email-masked]>
Date: Mon, 15 Aug 2016 13:02:15 -0400

Hi Kerry,

> considered part of the frame, that is, it shall be included within T

It may be useful to say in 1.3 that use of the padding is described in
the BACnet spec. Not crucial, so I will leave it up to you and Suresh to
decide.

> (though I have no idea why you'd want to do this over a wired medium).

I agree that I wouldn't want to use serial unicast, especially given the
token passing nature of the medium. If the link is heavily populated,
would a node get a chance to transmit all those copies in a single period?

If the SHOULD stays, and I don't think it should, I would suggest adding
a *brief* blurb on any interoperability issues that would arise by using
the alternative approach.

> By using this term, I mean "non link-local", that is, global as well as

Well... ULAs are globally scoped, per RFC 4193, so I think saying
"globally scoped" is more accurate. Again, this is up to you and Suresh
to decide.

Regards,
Brian