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

NPO question for consideration

Expand Messages
  • Coleman Brumley
    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
    Message 1 of 8 , Sep 11 6:45 PM
    • 0 Attachment

      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

       

       

    • Clifford.H.Copass@jci.com
      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
      Message 2 of 8 , Sep 13 5:15 AM
      • 0 Attachment

        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

         

         





      • Dave Robin
        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
        Message 3 of 8 , Sep 18 2:29 PM
        • 0 Attachment
          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

           
           






        • Coleman Brumley
          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.
          Message 4 of 8 , Sep 18 5:40 PM
          • 0 Attachment

            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

             

             




             

          • Coleman Brumley
            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
            Message 5 of 8 , Sep 19 7:05 AM
            • 0 Attachment

              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

               

               





               

            • Hartman, John
              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
              Message 6 of 8 , Sep 19 8:17 AM
              • 0 Attachment

                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.
              • 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 7 of 8 , Sep 19 8:20 AM
                • 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 8 of 8 , Sep 19 8:27 AM
                  • 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.