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

RE: [bacnet-ip-wg] NPO question for consideration

Expand Messages
  • Carl Neilson
    That sounds like a good approach to me. Carl From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John Sent:
    Message 1 of 8 , Sep 19, 2012
    • 0 Attachment

      That sounds like a good approach to me.


      Carl

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John
      Sent: Wednesday, September 19, 2012 8:18 AM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] NPO question for consideration

       

       

      There are at least THREE options, each of which may be appropriate in different cases

       

      1)      6-octet BVLL address is exactly what we want for the MAC_Address property.  That is the address used generically and is an octet string for any datalink, and it is nobody’s business whether there IS a UDP port.  On BACnetIP, MAC_Address should be read-only.

      2)      BACnetHostNPort is great for cases like BDTs where each entry is an IP address or host name, and may use a different UDP port

      3)      UDP port as its own property may be clearest way to deal with the DHCP case, where the user can assign the UDP port but NOT the address.  It

      might also make sense if there were multiple IP addresses that all used (and HAD to use) the same UDP port:  if you used BACnetHostNPort for these addresses, you would have the annoying/odd behavior that writing to one property would change parts (ports) or other properties.

       

      I think that this works pretty well

      ·        MAC_Address is a read-only octet string

      ·        IP_Address is JUST an IP address (aka octet string of length 4), read-only if DHCP is enabled, or on something like a workstation without admin rights where you CAN’T change the IP address; else writable to set the IP address.

      ·        Subnet_mask, default_gateway etc. are also octet string of length 4

      ·        UDP port is an edited unsigned integer

      ·        BDT entries are BACnetHostNPort, since we want the hostname option and may need unique ports for each entry

       

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
      Sent: Wednesday, September 19, 2012 9:06 AM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] NPO question for consideration

       

       

      I reviewed older versions of the NPO (when it was still a young proposal) and I can't find a version that has a separate IP Address and UDP port property.

       

      I guess my fear about "simply" adding this properties is that it'll cause a storm of "Why aren't these properties combined and declared as BACnetHostNPort?" type discussions.

       

      In my mind, they should be as follows:

      BACnet_IP_Address       OCTET STRING

      BACnet_IP_UDP_Port   OCTET STRING

       

      Both of which are conveyed most significant byte first.

       

      The bigger issue is what happens to the value of the MAC_Address property in the case of an IP device? Does this value automagically take on the combined values of the IP_Address property and the UDP_Port property? I have note that says "MAC_Address becomes read only for BACNET_IP", but is this still the direction we want to go know that it's likely to generate more comments?

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
      Sent: Tuesday, September 18, 2012 8:40 PM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] NPO question for consideration

       

       

      Yep, the problem that I've run into is that now we need to re-introduce IP Address and UDP Port as separate properties which trumps the MAC_Address property. So, what value does MAC Address take on when we're working with an IP only device?

       

      The more I think about it, the more I *like* separate object types, and your point about the footnotes is perfectly valid. When maintenance of the footnotes is more of a hassle than the table, then we're in trouble.

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Dave Robin
      Sent: Tuesday, September 18, 2012 5:29 PM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: Re: [bacnet-ip-wg] NPO question for consideration

       

       

      I usually don't like a large number of mutually exclusive properties (if the footnotes are longer than the table, something's wrong).  

       

      I was thinking about asking if we've considered the approach taken by Event_Type/Event_Parameters, which seems like an obvious thing to do in this polymorphic situation.  But one problem with that is that we don't have extensible data structures. i.e. we cant add another data field to one of the choices,.  This leads to terrible things like the return to normal delay *property* that should have been a parameter with a new context tag.

       

      So, we're stuck with a bunch of mutually exclusive properties or separate object types,... or use a Port_Type/Port_Parameters pair and hold our breath hoping that we will never have to add something like return-to-normal-delay.  Separate object types wouldn't be a terrible thing, but it does feel odd, too.   I really just wish we had extensible data structures  :-(

       

      Dave

       

      On Sep 13, 2012, at 8:15 AM, Clifford.H.Copass@... wrote:




       


      I think I would prefer an approach with a single object type, but clearer collections of properties based on the Network_Type value.  Consider dividing up the property table and descriptions into sections that are common, and then appropriate to each network type.

      Cliff Copass
      Johnson Controls, Inc.



      From:

      "Coleman Brumley" <bacnet_cb@...>

      To:

      <bacnet-ip-wg@yahoogroups.com>

      Date:

      09/11/2012 08:46 PM

      Subject:

      [bacnet-ip-wg] NPO question for consideration

       






      IP-WG,

       

      This is something I started thinking about during the San Antonio meeting, and the more I review Add. AI (and the NPO mods required for Add. AJ) the more I think what I'm proposing below is a little easier of an approach.

       

      What does everyone think of splitting the one, huge NPO into several separate NPO based solely on network type? For example, in the new approach, there would be an MSTP NPO, a BACNET_IPV4 NPO, and so on.

       

      Do you think this would make modifications easier? Do you think it makes the object easier to consume and implement? I look forward to hearing opinions on this.

       

      Regards,

      Coleman

       

       





       

       



      The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.

    • Coleman Brumley
      Agreed. I ll make those changes after the meeting today, along any other outstanding issues. I still have notes about adding language to Annex J that mandates
      Message 2 of 8 , Sep 19, 2012
      • 0 Attachment

        Agreed. I'll make those changes after the meeting today, along any other outstanding issues.

         

        I still have notes about adding language to Annex J that mandates BACnet/IP devices shall be capable of supporting DNS resolution as well as updating the NAT language to reflect NPO properties.

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
        Sent: Wednesday, September 19, 2012 11:21 AM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] NPO question for consideration

         

         

        That sounds like a good approach to me.


        Carl

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John
        Sent: Wednesday, September 19, 2012 8:18 AM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] NPO question for consideration

         

         

        There are at least THREE options, each of which may be appropriate in different cases

         

        1)      6-octet BVLL address is exactly what we want for the MAC_Address property.  That is the address used generically and is an octet string for any datalink, and it is nobody’s business whether there IS a UDP port.  On BACnetIP, MAC_Address should be read-only.

        2)      BACnetHostNPort is great for cases like BDTs where each entry is an IP address or host name, and may use a different UDP port

        3)      UDP port as its own property may be clearest way to deal with the DHCP case, where the user can assign the UDP port but NOT the address.  It

        might also make sense if there were multiple IP addresses that all used (and HAD to use) the same UDP port:  if you used BACnetHostNPort for these addresses, you would have the annoying/odd behavior that writing to one property would change parts (ports) or other properties.

         

        I think that this works pretty well

        ·        MAC_Address is a read-only octet string

        ·        IP_Address is JUST an IP address (aka octet string of length 4), read-only if DHCP is enabled, or on something like a workstation without admin rights where you CAN’T change the IP address; else writable to set the IP address.

        ·        Subnet_mask, default_gateway etc. are also octet string of length 4

        ·        UDP port is an edited unsigned integer

        ·        BDT entries are BACnetHostNPort, since we want the hostname option and may need unique ports for each entry

         

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
        Sent: Wednesday, September 19, 2012 9:06 AM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] NPO question for consideration

         

         

        I reviewed older versions of the NPO (when it was still a young proposal) and I can't find a version that has a separate IP Address and UDP port property.

         

        I guess my fear about "simply" adding this properties is that it'll cause a storm of "Why aren't these properties combined and declared as BACnetHostNPort?" type discussions.

         

        In my mind, they should be as follows:

        BACnet_IP_Address       OCTET STRING

        BACnet_IP_UDP_Port   OCTET STRING

         

        Both of which are conveyed most significant byte first.

         

        The bigger issue is what happens to the value of the MAC_Address property in the case of an IP device? Does this value automagically take on the combined values of the IP_Address property and the UDP_Port property? I have note that says "MAC_Address becomes read only for BACNET_IP", but is this still the direction we want to go know that it's likely to generate more comments?

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
        Sent: Tuesday, September 18, 2012 8:40 PM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] NPO question for consideration

         

         

        Yep, the problem that I've run into is that now we need to re-introduce IP Address and UDP Port as separate properties which trumps the MAC_Address property. So, what value does MAC Address take on when we're working with an IP only device?

         

        The more I think about it, the more I *like* separate object types, and your point about the footnotes is perfectly valid. When maintenance of the footnotes is more of a hassle than the table, then we're in trouble.

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Dave Robin
        Sent: Tuesday, September 18, 2012 5:29 PM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: Re: [bacnet-ip-wg] NPO question for consideration

         

         

        I usually don't like a large number of mutually exclusive properties (if the footnotes are longer than the table, something's wrong).  

         

        I was thinking about asking if we've considered the approach taken by Event_Type/Event_Parameters, which seems like an obvious thing to do in this polymorphic situation.  But one problem with that is that we don't have extensible data structures. i.e. we cant add another data field to one of the choices,.  This leads to terrible things like the return to normal delay *property* that should have been a parameter with a new context tag.

         

        So, we're stuck with a bunch of mutually exclusive properties or separate object types,... or use a Port_Type/Port_Parameters pair and hold our breath hoping that we will never have to add something like return-to-normal-delay.  Separate object types wouldn't be a terrible thing, but it does feel odd, too.   I really just wish we had extensible data structures  :-(

         

        Dave

         

        On Sep 13, 2012, at 8:15 AM, Clifford.H.Copass@... wrote:





         


        I think I would prefer an approach with a single object type, but clearer collections of properties based on the Network_Type value.  Consider dividing up the property table and descriptions into sections that are common, and then appropriate to each network type.

        Cliff Copass
        Johnson Controls, Inc.




        From:

        "Coleman Brumley" <bacnet_cb@...>

        To:

        <bacnet-ip-wg@yahoogroups.com>

        Date:

        09/11/2012 08:46 PM

        Subject:

        [bacnet-ip-wg] NPO question for consideration

         







        IP-WG,

         

        This is something I started thinking about during the San Antonio meeting, and the more I review Add. AI (and the NPO mods required for Add. AJ) the more I think what I'm proposing below is a little easier of an approach.

         

        What does everyone think of splitting the one, huge NPO into several separate NPO based solely on network type? For example, in the new approach, there would be an MSTP NPO, a BACNET_IPV4 NPO, and so on.

         

        Do you think this would make modifications easier? Do you think it makes the object easier to consume and implement? I look forward to hearing opinions on this.

         

        Regards,

        Coleman

         

         






         

         



        The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.

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