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

Add AI PPR3 Rev. 23 has been uploaded

Expand Messages
  • Coleman Brumley
    IP-WG, PPR3 draft 23 of the Add. AI has been uploaded to the Yahoo group. The shortcut is here
    Message 1 of 2 , Dec 4, 2012
    • 0 Attachment

      IP-WG,

       

      PPR3 draft 23 of the Add. AI has been uploaded to the Yahoo group. The shortcut is here.

       

      There have been several changes to this revision based on feedback from draft 22. Please review these and if you have feedback this evening or early tomorrow, I will try to get another draft prepared prior to the telecon.

       

      In general, unless the changes were minor, changes are marked with CLB comments that start with "Rev. 23".

       

      >        Minor editorial changes (two spaces after a ".", spaces before commas, extra blank lines, etc.). These changes are throughout and are likely not marked with comments.

      >        Footnote 2 modified to include the word "other".

      >        12.X.16, added the word "the" so it now reads "...is an array of the link speeds..."

      >        12.X.26, now reads "indicates whether or not this network port is configured via DHCP."

      >        Changed the footnote for BBMD_Accept_FD_Registrations to footnote 11 since it must be present and writable.

      >        12.X.37, now reads "...the valid range for the value of this property shall be 0 to 127."

      >        12.X.37 and 12.X.38, modified the language to make these clauses consistent with one another regarding "master node" language.

      >        12.11.33, slave nodes cannot have a max_info_frames property. Added the word "master".

      >        Footnote 14 has been changed to indicate that the property must be writable if WriteProperty is supported.

      >        Old footnotes 14-20 have been renumbered to 15-21.

      >        Table 12-X, Max_Master is now footnote 14. Max_Info_Frames is now footnote 15.

      >        Table 12-X, Event_State is footnote 20.

      >        Table 12-X, Manual_Slave_Address_Binding footnote changed to footnote 16, which requires writability if the device can be a slave proxy.

      >        Clause J.4.5, added language about host names in a table entry to be consistent with the property description in the NPO.

      >        Clause 12.X.8, changed "...property may have any of..." to "...property shall have one of..."

      >        Clause 12.X.19, change "...property may have any of..." to "...property shall have one of..."

       

      The following items are more substantive items and require discussion as to whether they will go into this PPR. My personal feeling is that these are all valid points, with the exception maybe of #3. Items #1 and #2 are potentially easy changes. Items #4 and #5 -- not so much.

       

      1.       Proposed changes to Table 12-13 Footnote X, 12.11.32 and 12.11.13 says “If the device supports multiple MS/TP networks, then this property shall reflect the value of the Max_Master property of the enabled Network Port object with the lowest object instance whose Network_Type is MSTP”.  But the relationship should be true even if the device only has ONE MS/TP network.  Thus, the sentences should be “If the device is a master on an MS/TP network, then this property shall reflect the value of the Max_Master property of the enabled Network Port object with the lowest object instance whose Network_Type is MSTP”.  This applies to all the MS/TP properties in both the Port and the Device object.

       

      2.       Footnote 3 and 12.X.13 say that MAC_Address is read-only if the port is BACnet/IP.  Common sense indicates that vendors will make this property read-only for clause 8 Ethernet, since Ethernet addresses are usually not changeable.  But I think we should require read-only for ZigBee and other network types that use a VMAC derived from the Device Instance.  Allowing a writeable VMAC would either result in breaking the VMAC == DeviceInstance, or change the Device Instance.

       

      3.       12.X.42 says that the list consists of manually configured devices, plus those automatically discovered.  It also says that devices that later fail to respond shall be removed.  But removing a manually configured device means that the first requirement is no longer true.  If manually-configured devices ARE removed, how and when are they added back in?  Is there an implicit requirement that the device occasionally poll the removed manually-configured devices in order to add them back into the binding list?

       

      [Note from CLB: I believe this issue (#3) is out of scope for the NPO changes, as if it's a problem then it's a problem in the existing slave proxy language. For what it's worth, I don't think this is an issue because 12.11.41 talks about polling and how the sets are combined in the Slave_Proxy_Enable property of the Device object. It's possible that the two clauses could be made clearer in this regard, but that's not here and should be addressed by either a interpretation/clarification request or another change proposal.]

       

      4.       12.11.32 describes the Max_Master property in the Device object.  It allows the property to be written, but does not specify that writing it changes the associated Network Port object.  The ability to write this property in the Device object would be nice, as it enhances backward compatibility with Workstations and service tools that can write to the Device object but do not know about the Network Port object.  However writing to this property via the Device object causes a problem: writing to Max_Master in the Network Port object sets Changes_Pending, and must be ACTIVATED to take effect.  Possible solutions would seem to be

      ·         Writing to the Device object property would AUTOMATICALLY cause activation in order to preserve backward compatibility of service tools

      ·         Writing Max_Master in either the Device or Network Port object could take place WITHOUT activation in order to preserve backward compatibility of service tools.

      ·         The Device object version of the property could be made read only, bidding fond adieu to backward compatibility

      ·         Remove the properties from the Device object altogether.

      ·         I can’t say that I like any of these, but the third or fourth options seem simplest and safest.  Personally, I like read-only.

       

      Note that this same argument applies to Max_Info_Frames.

       

      5.       The Device object has Slave_Proxy_Enable, Manual_Slave_Address_Binding, Auto_Slave_Discovery, and Slave_Address_Binding.  It would seem that these properties need the same treatment as Max_Master and Max_Info_Frames.

      ·         Text describing the relationship between the Device object properties and Network Port object (lowest instance…)

      ·         Deal with writability as above

      ·         Or remove the properties from the device object.  These optional properties are less prevalent than the Max_xxx properties, which are currently REQUIRED for an MS/TP device, so removing them would cause fewer compatibility issues..

      ·         Personally, I would go with read-only, or remove them.

       

      Regards,

      Coleman

       

       

    • Carl Neilson
      I will be late to todays telco. A couple of comments on the draft: 1) Footnote 2 is inaccurate. It should be restricted only based on those properties that use
      Message 2 of 2 , Dec 5, 2012
      • 0 Attachment

         

        I will be late to todays telco.

         

        A couple of comments on the draft:

         

        1) Footnote 2 is inaccurate. It should be restricted only based on those properties that use the Activate feature: 

        2 This property shall be writable if any property which uses the activate feature of this object is writable.

         

        2) I would prefer that the intro language for the Command property language be changed to not use the word ‘command’ as a verb as it means something else in BACnet:

         

        This property, of type BACnetNetworkPortCommand, is used to request that the Network Port object perform various actions.

         

        3) The addition of the sentence that Status_Flags is the pStatusFlags parameter of the event algorithm is probably incorrect since the Event Algorithm is NONE

         

        4) The word ‘must’ needs to be replaced with ‘shall’.

         

        5) Network_Interface_Name description does not adequately describe what the property does.

         

        This property, of type CharacterString, indicates which network interface hardware port to which this network port is bound. The value of this property is a local matter.

        Carl

         

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
        Sent: Tuesday, December 04, 2012 2:37 PM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: [bacnet-ip-wg] Add AI PPR3 Rev. 23 has been uploaded

         

         

        IP-WG,

         

        PPR3 draft 23 of the Add. AI has been uploaded to the Yahoo group. The shortcut is here.

         

        There have been several changes to this revision based on feedback from draft 22. Please review these and if you have feedback this evening or early tomorrow, I will try to get another draft prepared prior to the telecon.

         

        In general, unless the changes were minor, changes are marked with CLB comments that start with "Rev. 23".

         

        >        Minor editorial changes (two spaces after a ".", spaces before commas, extra blank lines, etc.). These changes are throughout and are likely not marked with comments.

        >        Footnote 2 modified to include the word "other".

        >        12.X.16, added the word "the" so it now reads "...is an array of

        the link speeds..."

        >    &nbs p;   12.X.26, now reads "indicates whether or not

        this network port is configured via DHCP."

        >        Changed the footnote for BBMD_Accept_FD_Registrations to footnote 11 since it must be present

        and writable.

        >        12.X.37, now reads "...the valid range for the value of this property

        shall be 0 to 127."

        >        12.X.37 and 12.X.38, modified the language to make the se clauses consistent with one another regarding "master node" language.

        >        12.11.33, slave nodes cannot have a max_info_frames property. Added the word "master".

        >        Footnote 14 has been changed to indicate that the property must be writable if WriteProperty is supported.

        >        Old footnotes 14-20 have been renumbered to 15-21.

        >        Table 12-X, Max_Master is now footnote 14. Max_Info_Frames is now footnote 15.

        >        Table 12-X, Event_State is footnote 20.

        >        Table 12-X, Manual_Slave_Address_Binding footnote changed to footnote 16, which requires writability if the device can be a slave proxy.

        >        Clause J.4.5, added language about host names in a tabl e entry to be consistent with the property description in the NPO.

        >        Clause 12.X.8, changed "...property may have any of..." to "...property shall have one of..."

        >        Clause 12.X.19, change "...property may have any of..." to "...property shall have one of..."

         

        The following items are more substantive items and require discussion as to whether they will go into this PPR. My personal feeling is that these are all valid points, with the exception maybe of #3. Items #1 and #2 are potentially easy changes. Items #4 and #5 -- not so much.

         

        1.       Proposed changes to Table 12-13 Footnote X, 12.11.32 and 12.11.13 says “If the device supports multiple MS/TP networks, then this property shall reflect the value of the Max_Master property of the enabled Network Port object with the lowest object instance whose Network_Type is MSTP”.  But the relationship should be true even if the device only has ONE MS/TP network.  Thus, the sentences should be “If the device is a master on an MS/TP network, then this property shall reflect the value of the Max_Master property of the enabled Network Port object with the lowest object instance whose Network_Type is MSTP”.  This applies to all the MS/TP properties in both the Port and the Device object.

         

        2.       Footnote 3 and 12.X.13 say that MAC_Address is read-only if the port is BACnet/IP.  Common sense indicates that vendors will make this property read-only for clause 8 Ethernet, since Ethernet addresses are usually not changeable.  But I think we should require read-only for ZigBee and other network types that use a VMAC derived from the Device Instance.  Allowing a writeable VMAC would either result in breaking the VMAC == DeviceInstance, or change the Device Instance.

         

        3.       12.X.42 says that the list consists of manually configured devices, plus those automatically discovered.  It also says that devices that later fail to respond shall be removed.  But removing a manually configured device means that the first requirement is no longer true.  If manually-configured devices ARE removed, how and when are they added back in?  Is there an implicit requirement that the device occasionally poll the removed manually-configured devices in order to add them back into the binding list?

         

        [Note from CLB: I believe this issue (#3) is out of scope for the NPO changes, as if it's a problem then it's a problem in the existing slave proxy language. For what it's worth, I don't think this is an issue because 12.11.41 talks about polling and how the sets are c ombined in the Slave_Proxy_Enable property of the Device object. It's possible that the two clauses could be made clearer in this regard, but that's not here and should be addressed by either a interpretation/clarification request or another change proposal.]

         

        4.       12.11.32 describes the Max_Master property in the Device object.  It allows the property to be written, but does not specify that writing it changes the associated Network Port object.  The ability to write this property in the Device object would be nice, as it enhances backward compatibility with Workstations and service tools that can write to the Device object but do not know about the Network Port object.  However writing t o this property via the Device object causes a problem: writing to Max_Master in the Network Port object sets Changes_Pending, and must be ACTIVATED to take effect.  Possible solutions would seem to be

        ·         Writing to the Device object property would AUTOMATICALLY cause activation in order to preserve backward compatibility of service tools

        ·         Writing Max_Master in either the Device or Network Port object co uld take place WITHOUT activation in order to preserve backward compatibility of service tools.

        ·         The Device object version of the property could be made read only, bidding fond adieu to backward compatibility

        ·         Remove the properties from the Device object altogether.

        ·         I can’t say that I like any of these, but the third or fourth options seem simplest and safest.  Personally, I like read-only.

         

        Note that this same argument applies to Max_Info_Frames.

         

        5.       The Device object has Slave_Proxy_Enable, Manual_Slave_Address_Binding, Auto_Slave_Discovery, and Slave_Address_Binding.  It would seem that these properties need the same treatment as Max_Master and Max_ Info_Frames.

        ·         Text describing the relationship between the Device object properties and Network Port object (lowest instance…)

        ·         Deal with writability as above

        ·         Or remove the properties from the device object.  These optional properties are less prevalent than the Max_xxx properties, which are currently REQUIRED for an MS/TP device, so removing them would cause fewer compatibility issues..

        ·         Personally, I would go with read-only, or remove them.

         

        Regards,

        Coleman

         

         


      Your message has been successfully submitted and would be delivered to recipients shortly.