426RE: [bacnet-ip-wg] RE: Unresolved Commenter
- May 20, 2014
I had to read it three times, but I think this covers what we want to allow.
I can go with it.
For 7910 the new proposed language is:
It is a local matter whether, or not, a device refuses requests to write to a Network Port object if:
any Network Port object has pending changes,
the write request is from a device other than that which wrote the existing pending changes, and
the write would result in pending changes in any Network Port object.
When refusing such a request, the device shall return of a Result(-) with an ‘Error Class’ of DEVICE and an ‘Error Code’ of CONFIGURATION_IN_PROGRESS.
For comment 7910, I suggest we take an approach like backup and restore where the device can send a Result(-) indicating CONFIGURATION_IN_PROGRESS if 1) any NPO is already being configured and 2) the subsequent write request came from an address other than the client from #1.
I suggest we do this along with Carl’s proposed change.
Complicated? Yes, but as the commenter points out, so is this object.
How’s that sound?
Carl's suggestions seem reasonable to me, but I think a few comments are appropriate.
Regarding comment 7918 regarding Write-BDT
1 - Does changing 135-2012al and sending it out in the PPR resolve the issue of it being "on hold" too long?
2 - Is there any reason to also include Read-Broadcast-Distribution-Table in the new requirement? I see it as a very weak need at best, but wondered if anyone had similar thoughts.
Regarding comment 7910 regarding allowing a device to control write capability to Network Port objects.
I think the proposed solution is significantly different than the commenter's proposed solution, and I was wondering if that is intentional.
The commenter wants to allow ONE CLIENT to change as many Network Port objects in a device as they desire.
The proposed solution is to allow many clients to change only ONE Network Port object in a device.
Personally I think the commenter's solution is more useful in the real world, but may have more implementation difficulties in some cases. There are also questions about allowing other clients to cancel pending changes, etc.
Does anyone else have an opinion on this?
Two comments on 135-2012ai which we re jected have left a commenter unresolved. Before we move forward we need to ensure that the committee is OK with especially given the commenter’s additional comments on the topics.
If we can come to an agreed position on these very quickly we can move forward with the public review; otherwise we will need to deal with these issues in Seattle.
To move this along, I have proposed changed responses that should ameliorate the commenter and which I do not believe would be objectionable.
Please review and comment on the proposals. If they are acceptable I will move them forward to the committee and attempt to get all vot ing members to vote quickly.
Both comment entries are included at the end of the email for you information.
Comment 7918 was rejected, but noted that a change would be made in a future addendum. The commenter correctly notes that our contention that we do not make mention of changed functionality in the standard is incorrect; he has provided an example of such (the schedule object). His request for a BIBB change is reasonable, especially since a BIBB on that topic is present in Addendum 135-2012al.
The commenter’s response:
ReadPropertyConditional was quietly removed because no one had ever implemented it.
In contrast, many BACnet workstations HAVE implemented Write-BDT. Both existing AND NEW workstations will need to CONTINUE to support Write-BDT if they wish to work on jobs with existing BBMDs.
Clause 12.24 DOES describe a version-dependent change in behavior of the Schedule object for exactly this reason: so that a significant change in behavior is documented without requiring an implementer to read all previous versions of the standard. Given that you can't GET previous versions of the standard from ASHRAE (a least without purchasing them separately), this is an important issue.
To move this forward, I suggest that we change our comment response to ‘Accepted’, draft language which changes 135-2012al and include it in the PPR.
[Change K.5.X2 in 135-2012al, p. 8]
K.5.X2 BIBB - Network Management - BBMD Configuration - A (NM-BBMDC-A)
The A device is able to query and change the configuration of BBMDs.
BACnet Virtual Link Layer Message
Devices claiming conformance to this BIBB are required to initiate Write-Broadcast-Distribution-Table for interoperability with devices implementing Protocol_Revisions older than X.
Comment 7910 was rejected.
The commenter’s response:
You say "The committee prefers that this be achieved by controlling the process allowing changes in the product, i.e. don't configure multiple ports at the same time, rather than requiring products to enforce that rule. "
Am I ALLOWED to have my BACnet server device "control the process" by not allowing multiple clients to make changes simultaneously (e.g., after client A writes to a Port object, reject writes from client B to any Port object until A either sends Re-init, sends "Discard Changes", or after some timeout)?
Regarding "complicates the solution": requiring the Network Port object in all BACnet devices, and requiring it to be writable in almost all BACnet devices has already gotten to a gawdawful complicated mess. The only thing worse than requiring everyone to add complicated, potentially dangerous (you can use BACnet to permanently take me off line by changing my address, baud rate etc) functionality to their device is to require that, but then leave aspects of the operation ambiguous, as in this case
The commenter’s second paragraph above is a reasonable question and allowing for implementations to take this approach seems reasonable.
To move this forward, I suggest that we change our comment response to ‘Accepted’, and add the following to clause 12.X.11 Changes_Pending:
It is a local matter whether, or not, a device allows multiple Network Port objects to have pending changes. If a device disallows a write because
it would violate this condition, the device shall return of a Result(-) wit h an ‘Error Class’ of DEVICE and an ‘Error Code’ of CONFIGURATION_IN_PROGRESS.
BSR/ASHRAE Addendum ai to ANSI/ASHRAE Standard 135-2012, BACnet - A Data Communication Protocol for Building Automation and Control Networks (Fourth Public Review Draft)
45-Day Public Review Period from March 7, 2014, to April 21, 2014
J.4.5 BBMD Operation - Broadcast Distribution and J.2.2.1 Write-Broadcast-Distribution-Table
Add language to J.2.2.1 and J.4.5 explaining that Write-Broadcast-Distribution-Table is deprecated.
I understand the deprecation of Write-Broadcast-Distribution-Table in favor of the Network Port object. However, the standard needs to explicitly deprecate it: otherwise J.2.2.1 defines a message, and J.4.5 forbids its use, leading to confusion. Something like:
Prior to protocol revision X, this message was used to create or replace the BDT in a device. Beginning in protocol revision X, the BDT must be updated via writes to the BBMD_Broadcast_Distribution_Table property of the Network Port object associated with the BBMD’s network port.
When BBMD which supports protocol revision X or later receives a Write-Broadcast-Di stribution-Table message , it shall return a BVLC-Result message to the originating device with a result code of X'0010' indicating that the Write-Broadcast-Distribution BVLL message is not supported.
When a BBMD which supports a protocol revision of X-1 or earlier receives a BVLL Write-Broadcast-Distribution-Table message, the BBMD shall attempt to create or replace its BDT, depending on whether or not a BDT has previously existed. If the creation or replacement of the BDT is successful, the BBMD shall return a BVLC-Result message to the originating device with a result code of X'0000'. Otherwise, the BBMD shall return a BVLC-Result message to the originating device with a result code of X'0010' indicating that the write attempt has failed.
Because both types of BBMDs may be encountered in the field, client devices that need to manipulate BDTs should (shall?) be prepared to deal with both types.
Interoperability is best served by making that last sentence normative. But one might argue for “should” here, and putting the requirement only in the BIBB.
Associated Reference Materials
This comment was submitted as “supportive” in a previous review. I thought it was a simple request that needed no response. However, the committee apparently disagreed. I feel the issue is important enough raise again, this time requesting a committee response
New - Submitted
< td width="8" style="width:6.0pt;padding:0in 0in 0in 0in;height:1.8pt;">
No contact required
Contacted, likely resolved
Contacted, likely unresolved
Ready for Approval
Enter date formatted as mm/dd/yyyy
- << Previous post in topic Next post in topic >>