Loading ...
Sorry, an error occurred while loading the content.

424RE: [bacnet-ip-wg] RE: Unresolved Commenter

Expand Messages
  • Clifford H Copass
    May 20, 2014
    • 0 Attachment

      So would the extra language added be something like:

       

      "It is a local matter whether, or not, a device allows multiple client devices to write pending changes at the same time.  If a device disallows a write because it would violate this condition, the device shall return of a Result(-) with an ‘Error Class’ of DEVICE and an ‘Error Code’ of CONFIGURATION_IN_PROGRESS."

       

      I think it is an overkill to implement both restrictions, but since it is a local matter, it is up to the vendor as to what they think is reasonable.

       

      Cliff Copass

       

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
      Sent: Tuesday, May 20, 2014 10:49 AM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] RE: Unresolved Commenter

       




      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?

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
      Sent: Tuesday, May 20, 2014 9:04 AM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: [bacnet-ip-wg] RE: Unresolved Commenter

       

       

      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?

       

      Cliff Copass

       

       

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
      Sent: Monday, May 19, 2014 10:32 PM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: [bacnet-ip-wg] Unresolved Commenter
      Importance: High

       




      BACneteers,

       

      Two comments on 135-2012ai which we rejected 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 voting members to vote quickly.

       

      Both comment entries are included at the end of the email for you information.

       

      1)

       

      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

      Initiate

      Execute

      Write-Broadcast-Distribution-Table

      x

       

      Read-Broadcast-Distribution-Table

      x

       

      Read-Foreign-Device-Table

      x

       

      Delete-Foreign-Device-Table-Entry

      x

       

       

      Devices claiming conformance to this BIBB are required to initiate Write-Broadcast-Distribution-Table for interoperability with devices implementing Protocol_Revisions older than X.

       

       

      2)

       

      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(-) with an ‘Error Class’ of DEVICE and an ‘Error Code’ of CONFIGURATION_IN_PROGRESS.

       

      COMMENT ENTRIES:

       

      COMMENT

      Comment Key

      7918

      Cmnter Number

      0007

      Cmnt Number

      014

      Document

      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)

      Review Period

      45-Day Public Review Period from March 7, 2014, to April 21, 2014

      Committee

      SSPC135

      Comment Title

      J.4.5 BBMD Operation - Broadcast Distribution and J.2.2.1 Write-Broadcast-Distribution-Table

      Section Type

      Clause

      Section Number

      J

      Supportive

      No

      Comment Text

      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-Distribution-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

      No Attachments

      Substantiating Comments

      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

       

      Comment Status*

      New - Submitted

      Administrative Information

      Committee Tag*

       

      Assigned Responder/SC/WG*

       

      COMMITTEE RESPONSE

      Committee Notes

      Change Type

       

       

      X

      None

       

      Editorial

       

       

      Substantive

       

       

       

       

      Resolution Potential

       

       

      X

      No contact required

       

      Contact required

       

      Contacted, likely resolved

       

      Contacted, likely unresolved

       

       

      General Notes

       

      Committee Response

      Response Status

       

       

       

      Draft

       

      Ready for Approval

      X

      Response Approved

       

       

      Approval Date

      Enter date formatted as mm/dd/yyyy

      05/16/2014

      Approval Method

       

       

       

      PC Meeting

      X

      Letter Ballot

       

       

      Approval Location

       

      Committee Response

       

       

       

      Accepted as submitted

       

      Accepted with minor changes

       

      Accepted in principle

      X

      Rejected except as noted

       

      Rejected


      (Message over 64 KB, truncated)
    • Show all 9 messages in this topic