Early Review of draft-ietf-6lo-6lobac-05
review-ietf-6lo-6lobac-05-intdir-early-haberman-2016-08-15-00

Request Review of draft-ietf-6lo-6lobac
Requested rev. no specific revision (document currently at 08)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2016-08-15
Requested 2016-08-08
Authors Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson
Draft last updated 2016-08-15
Completed reviews Genart Last Call review of -06 by Orit Levin (diff)
Intdir Early review of -05 by Tim Chown (diff)
Intdir Early review of -05 by Brian Haberman (diff)
Opsdir Last Call review of -06 by Mahesh Jethanandani (diff)
Assignment Reviewer Brian Haberman
State Completed
Review review-ietf-6lo-6lobac-05-intdir-early-haberman-2016-08-15
Reviewed rev. 05 (document currently at 08)
Review result Ready
Review completed: 2016-08-15

Review
review-ietf-6lo-6lobac-05-intdir-early-haberman-2016-08-15

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



Attachment:


signature.asc




Description:

 OpenPGP digital signature