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

419RE: Unresolved Commenter

Expand Messages
  • Isler, Bernhard
    May 20, 2014
    • 0 Attachment

      I am supporting Carl’s proposed resolution.

       

      Bernhard

       

      Bernhard Isler

      Siemens Switzerland Ltd
      Building Technologies Division

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
      Sent: Tuesday, May 20, 2014 5:32 AM
      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

       

      More information is needed

       

      Deferred, Out of Scope

       

      Deferred, Late

       

       

      Response Text

      The standard does not make mention of past protocol revisions in the suggested manner, only what is supported in current revisions. For example, when ReadPropertyCondidtional was deprecated, it was removed with no mention of it ever being available in earlier revisions. A future addendum will further clarify the Write-BDT error cases.

      Response Sent*

      Do not edit.

                                                     

      Reply Deadline

      If left blank, the ‘Reply Deadline’ will be set to 30 days from when the response has been sent.

       

      Enter date formatted as mm/dd/yyyy.

       

       

      Associated Reference Materials

      No Attachments

      Attachments must be added via the online system following upload. Please note in the “Committee Notes” field, above, if an attachment will be included with the committee response.

       

       

      COMMENT

      Comment Key

      7910

      Cmnter Number

      0007

      Cmnt Number

      006

      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

    • Show all 9 messages in this topic