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

Unresolved Commenter

Expand Messages
  • Carl Neilson
    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
    Message 1 of 9 , May 19, 2014

      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

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

      Committee

      SSPC135

      Comment Title

      12.X.12 Command and ReinitializeDevice for multiple ports

      Section Type

      Clause

      Section Number

      12.X.12

      Supportive

      No

      Comment Text

      Clarify the behavior of ReinitializeDevice when multiple Port objects have pending changes.

       

       

      Associated Reference Materials

      No Attachments

      Substantiating Comments

      In previous versions, activation was done by writing ACTIVATE to the Command property.  This has been replaced by a new type of ReinitializeDevice request.

      However, consider the case where more than one Port object has been written to, and has Changes_Pending true.  Under the old scheme, you could ACTIVATE one, but leave the other unchanged.  Under the new scheme, a ReinitializeDevice request to either ACTIVATE or WARMSTART will activate ALL Ports th

      (Message over 64 KB, truncated)

    • Isler, Bernhard
      I am supporting Carl s proposed resolution. Bernhard Bernhard Isler Siemens Switzerland Ltd Building Technologies Division From: bacnet-ip-wg@yahoogroups.com
      Message 2 of 9 , May 20, 2014

        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

      • Coleman Brumley
        Agreed. Carl, do you want me to make the changes? Coleman From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] Sent: Tuesday, May 20, 2014
        Message 3 of 9 , May 20, 2014

          Agreed.

           

          Carl, do you want me to make the changes?

           

          Coleman

           

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

           

           

          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.

           

           



          (Message over 64 KB, truncated)

          COMMENT

          Comment Key

          7910

          Cmnter Number

          0007

          Cmnt Number

          006

        • Clifford H Copass
          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
          Message 4 of 9 , May 20, 2014

            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

             

            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

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

            Committee

            SSPC135

            Comment Title

            12.X.12 Command and ReinitializeDevice for multiple ports

            Section Type

            Clause

            Section Number

            12.X.12

            Supportive

            No

            Comment Text

            Clarify the behavior of ReinitializeDevice when multiple Port objects have pending changes.

             

             

            Associated Reference Materials


            (Message over 64 KB, truncated)
          • Coleman Brumley
            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
            Message 5 of 9 , May 20, 2014

              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

               

              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 committe

              (Message over 64 KB, truncated)

            • Clifford H Copass
              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
              Message 6 of 9 , May 20, 2014

                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)
              • Carl Neilson
                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
                Message 7 of 9 , May 20, 2014

                  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.

                  Carl

                   

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

                   

                  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

                   < /p>

                  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(-) wit h 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-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

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

                   

                  Editorial

                   

                   

                  Substantive

                   

                   

                   < td width="8" style="width:6.0pt;padding:0in 0in 0in 0in;height:1.8pt;">

                   

                  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


                  (Message over 64 KB, truncated)

                • Clifford H Copass
                  I had to read it three times, but I think this covers what we want to allow. I can go with it. Cliff From: bacnet-ip-wg@yahoogroups.com
                  Message 8 of 9 , 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.

                     

                    Cliff

                     

                     

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

                     




                    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.

                    Carl

                     

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

                     

                    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

                     < /p>

                    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(-) wit h 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-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

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

                     

                    Editorial

                     

                     

                    Substantive

                     

                     

                     < td width="8" style="width:6.0pt;padding:0in 0in 0in 0in;height:1.8pt;">

                     

                    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

                  • duffyocraven
                    I would encourage dropping the third part. The way that a write to a Network Port object could result in no pending changes in any Network Port object, and be
                    Message 9 of 9 , May 20, 2014
                      I would encourage dropping the third part. The way that a write to a Network Port object could result in no pending changes in any Network Port object, and be from a device other than that which wrote the existing pending changes, is if it is trying to write the same value as it already has. And I don't think it is worth requiring that the implementation check "if it is trying to write the same value" solely in order to figure out if it is not entitled to send the Result(-). If the write is to a Network Port object and from a device other than that which wrote the existing pending changes, then the implementation should be entitled to send the Result(-), irrespective of the value.
                             - Duffy O'Craven 
                      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.
                      Carl
                    Your message has been successfully submitted and would be delivered to recipients shortly.