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

RE: [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

Expand Messages
  • Carl Neilson
    I like this solution. From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Clifford.H.Copass@jci.com Sent: Friday, December
    Message 1 of 5 , Dec 9, 2011

      I like this solution.

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
      Sent: Friday, December 09, 2011 6:06 AM
      To: bacnet-ip-wg@yahoogroups.com
      Cc: bernhard.isler@...
      Subject: RE: [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

       

       


      This would be fine with me also.  It would be useful for the case of devices having a Network Port object but only a single port (not a router) and thus little or no network layer.  (For that case we could also standardize the instance to be used by the NP object in a device.)

      Regarding knowing the port a request came in from at the application layer, we would probably need to state something formal about this at the interfaces.  I don't think it would be all that hard to implement since we already have to be able to direct the response back to the port where it came from.

      Cliff Copass
      Johnson Controls, Inc.


      From:

      "Isler, Bernhard" <bernhard.isler@...>

      To:

      "bacnet-ip-wg@yahoogroups.com" <bacnet-ip-wg@yahoogroups.com>

      Date:

      12/09/2011 04:32 AM

      Subject:

      RE: [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

       





      On Point 4:

       

      What about using the wildcard instance 4194303 for this? A ReadProperty on an NPO and wildcard instance would read the property from the NPO that represents the port through which the request came in.

       

      This would have the advantage that no new NL message communication is needed for something that is on AL. And the NL does not need to be aware of the NPO.

       

      On the flip side, this would imply that the NL interface and AL interface needs to convey the port through which the request came in.

       

      Best,

      Bernhard

       

      Bernhard Isler
      Siemens Switzerland Ltd
      Building Technologies Division

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of cliffcopass
      Sent:
      Thursday, December 08, 2011 6:21 PM
      To:
      bacnet-ip-wg@yahoogroups.com
      Subject:
      [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

       

       

      This is a follow-up message from the telephone conference held December 7, 2011 for public review comment resolution on addendum ai.
      Comments on Add-135-2010ai-PPR2-Draft2.doc
      1 – Page4, table 12-X. Properties of the Network Port Object Type
      Changing footnote 8 from indicating just optionality / requirement conditions to indicating writability conditions doesn't seem to convey the correct information. Some writability conditions are complex and some should not apply to every place where the original footnote 8 was used.
      2 – Page 6, 12.X.12, near the bottom.
      I would like to see some clarification about how failed validation affects operation or is allowed to affect operation when the object is being designed. For example, if Changes_Pending remains True after a failed validation, I would not expect operation to change either, and all pending changes to remain pending. For the case discussed during the call (a device reset where there is no storage of the original configuration), I don't think we can require a failed validation to not affect Changes_Pending, but we should say what is expected.
      3 – Page 7, 12.X.15, (I am not sure we got to this)
      Link speed is to persist – which I believe is correct, but it is not clear what you persist when the Link Speed is initially 0 on MS/TP ("…autonegotiation algorithm is still in process."). I would expect to persist the "0" rather than the link speed reported after autonegotiation is complete so that changes in link speed can be automatically handled. Perhaps it would be sufficient to indicate that the WRITTEN value persists through a reboot rather than values resulting from autonegotiation.
      4 – General issue of associating Network Port instances with physical ports.
      One suggestion I have made several times is to provide a way to easily determine the Network Port instance for the port some other device is communicating to. It occurred to me that a Network Layer Protocol Message could be used to retrieve the Network Port object ID much like the service used to retrieve the network number (see 135-2010 6.4.19). This may be enough to resolve the issue since an external device would then be able to use a directed message to determine the capabilities of the port it is sending messages to. This mechanism would resolve the issue of the application layer behaving differently depending on the port where a message is received from or to be sent to since the network layer handles the query. What does everyone else think of this?

      Cliff Copass
      Johnson Controls, Inc.



      [attachment "image001.jpg" deleted by Clifford H Copass/CORP/Johnson_Controls] [attachment "image002.jpg" deleted by Clifford H Copass/CORP/Johnson_Controls]

    • Coleman Brumley
      Ok, that s the solution I ll put in Draft 3. From: Carl Neilson [mailto:cneilson@deltacontrols.com] Sent: Friday, December 09, 2011 1:39 PM To:
      Message 2 of 5 , Dec 9, 2011

        Ok, that's the solution I'll put in Draft 3. 

         

         

        From: Carl Neilson [mailto:cneilson@...]
        Sent: Friday, December 09, 2011 1:39 PM
        To: bacnet-ip-wg@yahoogroups.com
        Cc: bernhard.isler@...
        Subject: RE: [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

         

        I like this solution.

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
        Sent: Friday, December 09, 2011 6:06 AM
        To: bacnet-ip-wg@yahoogroups.com
        Cc: bernhard.isler@...
        Subject: RE: [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

         

         


        This would be fine with me also.  It would be useful for the case of devices having a Network Port object but only a single port (not a router) and thus little or no network layer.  (For that case we could also standardize the instance to be used by the NP object in a device.)

        Regarding knowing the port a request came in from at the application layer, we would probably need to state something formal about this at the interfaces.  I don't think it would be all that hard to implement since we already have to be able to direct the response back to the port where it came from.

        Cliff Copass
        Johnson Controls, Inc.

        From:

        "Isler, Bernhard" <bernhard.isler@...>

        To:

        "bacnet-ip-wg@yahoogroups.com" <bacnet-ip-wg@yahoogroups.com>

        Date:

        12/09/2011 04:32 AM

        Subject:

        RE: [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

         




        On Point 4:

         

        What about using the wildcard instance 4194303 for this? A ReadProperty on an NPO and wildcard instance would read the property from the NPO that represents the port through which the request came in.

         

        This would have the advantage that no new NL message communication is needed for something that is on AL. And the NL does not need to be aware of the NPO.

         

        On the flip side, this would imply that the NL interface and AL interface needs to convey the port through which the request came in.

         

        Best,

        Bernhard

         

        Bernhard Isler
        Siemens Switzerland Ltd
        Building Technologies Division

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of cliffcopass
        Sent:
        Thursday, December 08, 2011 6:21 PM
        To:
        bacnet-ip-wg@yahoogroups.com
        Subject:
        [bacnet-ip-wg] comments on Add-135-2010ai-PPR2-Draft2.doc

         

         

        This is a follow-up message from the telephone conference held December 7, 2011 for public review comment resolution on addendum ai.
        Comments on Add-135-2010ai-PPR2-Draft2.doc
        1 – Page4, table 12-X. Properties of the Network Port Object Type
        Changing footnote 8 from indicating just optionality / requirement conditions to indicating writability conditions doesn't seem to convey the correct information. Some writability conditions are complex and some should not apply to every place where the original footnote 8 was used.
        2 – Page 6, 12.X.12, near the bottom.
        I would like to see some clarification about how failed validation affects operation or is allowed to affect operation when the object is being designed. For example, if Changes_Pending remains True after a failed validation, I would not expect operation to change either, and all pending changes to remain pending. For the case discussed during the call (a device reset where there is no storage of the original configuration), I don't think we can require a failed validation to not affect Changes_Pending, but we should say what is expected.
        3 – Page 7, 12.X.15, (I am not sure we got to this)
        Link speed is to persist – which I believe is correct, but it is not clear what you persist when the Link Speed is initially 0 on MS/TP ("…autonegotiation algorithm is still in process."). I would expect to persist the "0" rather than the link speed reported after autonegotiation is complete so that changes in link speed can be automatically handled. Perhaps it would be sufficient to indicate that the WRITTEN value persists through a reboot rather than values resulting from autonegotiation.
        4 – General issue of associating Network Port instances with physical ports.
        One suggestion I have made several times is to provide a way to easily determine the Network Port instance for the port some other device is communicating to. It occurred to me that a Network Layer Protocol Message could be used to retrieve the Network Port object ID much like the service used to retrieve the network number (see 135-2010 6.4.19). This may be enough to resolve the issue since an external device would then be able to use a directed message to determine the capabilities of the port it is sending messages to. This mechanism would resolve the issue of the application layer behaving differently depending on the port where a message is received from or to be sent to since the network layer handles the query. What does everyone else think of this?

        Cliff Copass
        Johnson Controls, Inc.



        [attachment "image001.jpg" deleted by Clifford H Copass/CORP/Johnson_Controls] [attachment "image002.jpg" deleted by Clifford H Copass/CORP/Johnson_Controls]

         

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