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

Revised Addenda 2012an. Third time is the charm?

Expand Messages
  • Kerry Lynn
    Greetings, I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files area and have attached it here. It contains all the edits we
    Message 1 of 10 , Dec 10, 2013
    Greetings,

    I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
    area and have attached it here.

    It contains all the edits we discussed on last weeks call as well as resolutions to
    several good comments from John Hartman.

    This version contains a sample COBS-encoded frame (see X.4) but I did not have
    time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
    example code (X.3) so hopefully that will be sufficient.

    I also reversed spur-of-the-moment decision that we made on last weeks call,
    namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
    there are several good reasons for setting the range back to 32 - 127:

    a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.
    b) That range was reduced to 32 - 127 just in case we ever want to define
         more "legacy" frames
    c) The rationale for reducing the COBS-encoded range still further was "in
        case a new technology comes forward".  I doubt that will ever occur.
    d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"
       would seriously complicate the document at this point.
    e) The only current use of this range in the proposal is for the purposes of
        validating header fields
    f) If we really think some new format may come out later, then we can deal with
       that possibility by allocating Frame Types from 34 on.  This will permit later
       definition of a new range after COBS-encoded.

    If this decision or lack of a flowchart is a show-stopper, then we should discuss it
    at the next SSPC.

    Regards, -K-
  • Clifford H Copass
    I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me. I am checking to see if I am missing something
    Message 2 of 10 , Dec 13, 2013
    • 0 Attachment

      I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

       

      The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

       

      On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

       

      On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

       

      On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

       

      Cliff Copass

       

       

      From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
      Sent: Tuesday, December 10, 2013 11:31 AM
      To: bacnet-mstpwg
      Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

       

      [Attachment(s) from Kerry Lynn included below]


      Greetings,

      I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
      area and have attached it here.

      It contains all the edits we discussed on last weeks call as well as resolutions to
      several good comments from John Hartman.

      This version contains a sample COBS-encoded frame (see X.4) but I did not have
      time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
      example code (X.3) so hopefully that will be sufficient.

      I also reversed spur-of-the-moment decision that we made on last weeks call,

      namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
      there are several good reasons for setting the range back to 32 - 127:

      a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

      b) That range was reduced to 32 - 127 just in case we ever want to define

           more "legacy" frames

      c) The rationale for reducing the COBS-encoded range still further was "in

          case a new technology comes forward".  I doubt that will ever occur.

      d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

         would seriously complicate the document at this point.

      e) The only current use of this range in the proposal is for the purposes of

          validating header fields

      f) If we really think some new format may come out later, then we can deal with

         that possibility by allocating Frame Types from 34 on.  This will permit later

         definition of a new range after COBS-encoded.

      If this decision or lack of a flowchart is a show-stopper, then we should discuss it

      at the next SSPC.

      Regards, -K-




    • Kerry Lynn
      Hi Clif, Thanks for your comments. Se my responses inline... On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass
      Message 3 of 10 , Dec 15, 2013
      • 0 Attachment
        Hi Clif,

        Thanks for your comments.  Se my responses inline...


        On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:
         

        I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

         

        The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

         

        The fundamental definition is given on page 20:
        "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

        So a COBS-encoded field consists one or more code blocks, each or which begins with
        a code octet. Without more detail, I'm not sure which sections of the text are causing
        confusion.

        On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

         

        The sentence
        "In operation, the CRC-32K register C31-C0 is initialized to all ones."
        is similar to the descriptions of the header and data CRC examples in Annex G.
        Would you just like to see "C31-C0" removed?

        On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

         

        What text would you propose?
         

        On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

         

        Would you propose to delete the first sentence?  It was perhaps more timely three years
        ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
        forbid the use of large frames with low baud rates, vendors will hopefully realize this is a
        bad combination.

        There are many variations on the name "CRC-16-CCITT" but they all refer to the same
        polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
        article on CRC polynomials.

        Please respond with your thoughts on the points above.

        Regards, -K-

         

        Cliff Copass

         

         

        From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
        Sent: Tuesday, December 10, 2013 11:31 AM
        To: bacnet-mstpwg
        Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

         

        [Attachment(s) from Kerry Lynn included below]


        Greetings,

        I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
        area and have attached it here.

        It contains all the edits we discussed on last weeks call as well as resolutions to
        several good comments from John Hartman.

        This version contains a sample COBS-encoded frame (see X.4) but I did not have
        time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
        example code (X.3) so hopefully that will be sufficient.

        I also reversed spur-of-the-moment decision that we made on last weeks call,

        namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
        there are several good reasons for setting the range back to 32 - 127:

        a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

        b) That range was reduced to 32 - 127 just in case we ever want to define

             more "legacy" frames

        c) The rationale for reducing the COBS-encoded range still further was "in

            case a new technology comes forward".  I doubt that will ever occur.

        d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

           would seriously complicate the document at this point.

        e) The only current use of this range in the proposal is for the purposes of

            validating header fields

        f) If we really think some new format may come out later, then we can deal with

           that possibility by allocating Frame Types from 34 on.  This will permit later

           definition of a new range after COBS-encoded.

        If this decision or lack of a flowchart is a show-stopper, then we should discuss it

        at the next SSPC.

        Regards, -K-




      • Clifford H Copass
        Some ideas and suggestions: Regarding the use of CodeOctet : I think this can be resolved in the 9.5.2 Variables section. Code block is repeatedly used
        Message 4 of 10 , Dec 16, 2013
        • 0 Attachment

          Some ideas and suggestions:

           

          Regarding the use of "CodeOctet":

          I think this can be resolved in the "9.5.2 Variables" section.  "Code block" is repeatedly used with no reference as to what that means at this point in the text.  Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block.  Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.

          Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):

          "Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."

          What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.

           

           

          Regarding "CRC-32K register C31-C0":

          There needs to be a reference that exactly matches a register in the example.  Would this be "crcValue"?  If so, something like the following would be more enlightening:

          "In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."

          What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means.  The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones.  This would then read as:

          "In operation, the CRC32K register "crcValue" bits are initialized to all ones."

           

           

          Consider changing:

          "See clause 19.X for the preferred approach for determining…"

          to something like

          "See clause 19.X for an approach for determining…"

           

          Rationale:

          Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities."  I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).

          I would also like to see consistency in terminology for the uninitiated.  Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere.  Someone reading this for the first time may not realize these are the same thing.

           

          Cliff Copass

           

           

          From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
          Sent: Sunday, December 15, 2013 8:19 PM
          To: bacnet-mstpwg
          Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

           




          Hi Clif,

          Thanks for your comments.  Se my responses inline...

           

          On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

           

          I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

           

          The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

           

          The fundamental definition is given on page 20:
          "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

          So a COBS-encoded field consists one or more code blocks, each or which begins with
          a code octet. Without more detail, I'm not sure which sections of the text are causing

          confusion.

          On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

           

          The sentence

          is similar to the descriptions of the header and data CRC examples in Annex G.

          Would you just like to see "C31-C0" removed?

           

          On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

           

          What text would you propose?
           

          On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

           

          Would you propose to delete the first sentence?  It was perhaps more timely three years

          ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
          forbid the use of large frames with low baud rates, vendors will hopefully realize this is a

          bad combination.

          There are many variations on the name "CRC-16-CCITT" but they all refer to the same
          polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
          article on CRC polynomials.

          Please respond with your thoughts on the points above.

          Regards, -K-

           

          Cliff Copass

           

           

          From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
          Sent: Tuesday, December 10, 2013 11:31 AM
          To: bacnet-mstpwg
          Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

           

          [Attachment(s) from Kerry Lynn included below]

          Greetings,

          I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
          area and have attached it here.

          It contains all the edits we discussed on last weeks call as well as resolutions to
          several good comments from John Hartman.

          This version contains a sample COBS-encoded frame (see X.4) but I did not have
          time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
          example code (X.3) so hopefully that will be sufficient.

          I also reversed spur-of-the-moment decision that we made on last weeks call,

          namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
          there are several good reasons for setting the range back to 32 - 127:

          a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

          b) That range was reduced to 32 - 127 just in case we ever want to define

               more "legacy" frames

          c) The rationale for reducing the COBS-encoded range still further was "in

              case a new technology comes forward".  I doubt that will ever occur.

          d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

             would seriously complicate the document at this point.

          e) The only current use of this range in the proposal is for the purposes of

              validating header fields

          f) If we really think some new format may come out later, then we can deal with

             that possibility by allocating Frame Types from 34 on.  This will permit later

             definition of a new range after COBS-encoded.

          If this decision or lack of a flowchart is a show-stopper, then we should discuss it

          at the next SSPC.

          Regards, -K-






        • Clifford H Copass
          I don t really want to keep this back and forth running longer because we can continue based on public review comments, but I can t resist a little more...
          Message 5 of 10 , Dec 17, 2013

          I don't really want to keep this back and forth running longer because we can continue based on public review comments, but I can't resist a little more…

           

          Regarding the term "CodeOctet" and its definition - When I see "Code block", I immediately think of part of a computer program subroutine and have no concept of a COBS encoded data block.  I believe this may be true for a large part of the audience for this document since it will be computer programming people trying to implement it.

           

          When I look at the "C" code example on page 25, the only thing I see labeled "CRC-32K" is the comment about "…CRC-32K polynomial…" which is 0xEB31D82E in the code.

          If I am trying to follow this example, I should not need to guess about what variables in the example correspond to what values in the text.  This should be extremely clear.

           

          Regarding making the picture labels in the Rationale match the text, is this because of copyright restrictions or because of picture editing capabilities?  If it is due to picture editing capabilities, I am attaching a modified picture (gif and jpg formats) made in just a few minutes with only the clunky picture editing tools that come with Windows 7.  A better modification could be done with decent tools, but this looked satisfactory.

           

          In most of this debate, my concern is that the people trying to implement this may NOT be COBS encoding experts or even communications experts.  They should not be required to study the background material before being able to implement the BACnet standard.  They should not need to guess about what the examples mean.  When I read this from the prospective of someone seeing it for the first time, it is much harder to follow than it should or could be.

           

          Cliff Copass

          Johnson Controls, Inc.

           

          From: Kerry Lynn [mailto:kerlyn2001@...]
          Sent: Monday, December 16, 2013 1:06 PM
          To: Clifford H Copass
          Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

           

          Clif,

          Thanks for your comments.  See my responses inline...

           

          On Mon, Dec 16, 2013 at 9:33 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

          Some ideas and suggestions:

           

          Regarding the use of "CodeOctet":

          I think this can be resolved in the "9.5.2 Variables" section.  "Code block" is repeatedly used with no reference as to what that means at this point in the text.  Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block.  Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.

          Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):

          "Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."

          What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.

           

          DecodeCount, DecodeIndex, CodeOctet, LastCode, and DataOctet are local variables used
          by the procedure in 9.10.3.  John Hartman suggested moving them out of 9.5.2 (since they

          are not used at all by the state machines) but I failed to heed his advice.  I think moving the

          variables would be a better solution than to have multiple terms for the same concept.  "Code

          block" is used consistently in the literature describing COBS, and it is used liberally throughout

          the proposal.  A less disruptive change would be to have a forward pointer to 9.10.3 at the
          first mention of "code block".

           

          Regarding "CRC-32K register C31-C0":

          There needs to be a reference that exactly matches a register in the example.  Would this be "crcValue"?

           

          You need to first place G.3 in context.  G.1 (Header CRC) and G.2 (Data CRC) are
          essentially hardware-based descriptions that are then implemented as software
          examples.  I don't make any attempt to describe the CRC-32K examples from a

          hardware perspective, so maybe the first thing to do is drop the word "register".

          The language used in G.3 nearly identical to the earlier examples.  I have also used

          the same C API as shown in earlier examples.  It doesn't seem that folks have had

          difficulty associating the prose "CRC" with the formal parameter "crcValue" that is

          used in the C example.  The ASM example is just pulling the CRC bytes off the
          stack (i.e. there is no "name" for the parameter).

          Regarding "C31-C0", I thought that was a useful cue that the residue value shown

          just below that paragraph is in big-endian order.  I can remove "C31-C0" if that's the

          group consensus.

          Finally, there are at least four different concepts that I'm trying to keep straight

          through consistent use of different terms:  there's the "CRC32K" variable in 9.5.2
          which is the actual running accumulator, there's "CRC-32K" which is the name of
          the polynomial (and the calculation); there is "Modified CRC-32K" which is the

          one's complement of CRC-32K, ordered LSB first; and then there is the "Encoded

          CRC-32K" which is the Modified CRC-32K, COBS-encoded.

           

          If so, something like the following would be more enlightening:

          "In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."

          What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means.  The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones.  This would then read as:

          "In operation, the CRC32K register "crcValue" bits are initialized to all ones."

           

          How about "In operation, the CRC32K value is initialized to all ones."

           

          Consider changing:

          "See clause 19.X for the preferred approach for determining…"

          to something like

          "See clause 19.X for an approach for determining…"

           

          Done.
           

          Rationale:

          Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities."  I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).

           

          Sorry, I was looking at the first sentence.  You're right that the second sentence

          was incoherent.
           

          I would also like to see consistency in terminology for the uninitiated.  Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere.  Someone reading this for the first time may not realize these are the same thing.

           

          As I said in my previous post, "CRC-16-CCITT" seems to be the most popular
          search term for this polynomial so that's what I think should be used in the text.

          I can't change the picture, so if it's the group consensus that it's confusing then

          I will delete it.

          Regards, -K-

          Cliff Copass

           

           

          From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
          Sent: Sunday, December 15, 2013 8:19 PM
          To: bacnet-mstpwg
          Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

           



          Hi Clif,

          Thanks for your comments.  Se my responses inline...

           

          On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

           

          I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

           

          The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

           

          The fundamental definition is given on page 20:
          "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

          So a COBS-encoded field consists one or more code blocks, each or which begins with
          a code octet. Without more detail, I'm not sure which sections of the text are causing

          confusion.

          On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

           

          The sentence

          is similar to the descriptions of the header and data CRC examples in Annex G.

          Would you just like to see "C31-C0" removed?

           

          On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

           

          What text would you propose?
           

          On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

           

          Would you propose to delete the first sentence?  It was perhaps more timely three years

          ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
          forbid the use of large frames with low baud rates, vendors will hopefully realize this is a

          bad combination.

          There are many variations on the name "CRC-16-CCITT" but they all refer to the same
          polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
          article on CRC polynomials.

          Please respond with your thoughts on the points above.

          Regards, -K-

           

          Cliff Copass

           

           

          From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
          Sent: Tuesday, December 10, 2013 11:31 AM
          To: bacnet-mstpwg
          Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

           

          [Attachment(s) from Kerry Lynn included below]

          Greetings,

          I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
          area and have attached it here.

          It contains all the edits we discussed on last weeks call as well as resolutions to
          several good comments from John Hartman.

          This version contains a sample COBS-encoded frame (see X.4) but I did not have
          time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
          example code (X.3) so hopefully that will be sufficient.

          I also reversed spur-of-the-moment decision that we made on last weeks call,

          namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
          there are several good reasons for setting the range back to 32 - 127:

          a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

          b) That range was reduced to 32 - 127 just in case we ever want to define

               more "legacy" frames

          c) The rationale for reducing the COBS-encoded range still further was "in

              case a new technology comes forward".  I doubt that will ever occur.

          d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

             would seriously complicate the document at this point.

          e) The only current use of this range in the proposal is for the purposes of

              validating header fields

          f) If we really think some new format may come out later, then we can deal with

             that possibility by allocating Frame Types from 34 on.  This will permit later

             definition of a new range after COBS-encoded.

          If this decision or lack of a flowchart is a show-stopper, then we should discuss it

          at the next SSPC.

          Regards, -K-

           



        • Kerry Lynn
          On Tue, Dec 17, 2013 at 9:23 AM, Clifford H Copass
          Message 6 of 10 , Dec 17, 2013
          • 0 Attachment
            On Tue, Dec 17, 2013 at 9:23 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:
             
            [Attachment(s) from Clifford H Copass included below]

            I don't really want to keep this back and forth running longer because we can continue based on public review comments, but I can't resist a little more…

             

            Regarding the term "CodeOctet" and its definition - When I see "Code block", I immediately think of part of a computer program subroutine and have no concept of a COBS encoded data block.  I believe this may be true for a large part of the audience for this document since it will be computer programming people trying to implement it.

             

            John Hartman's proposal was to place all references to "code block" after the definition.  Is
            this acceptable?

            You're not suggesting that "code block" be replaced everywhere it appears in the document?
            That would make our descriptions inconsistent with all the existing literature on COBS, including
            Stuart Cheshire's PhD thesis (Stanford University) where it occurs nearly 70 times.

            I agree that this optional feature will be difficult to implement for anyone who is unable (or unwilling)
            to read the description and relate it to the examples and sample code.  When I'm in that situation,
            I search for and read papers on the topic.

            When I look at the "C" code example on page 25, the only thing I see labeled "CRC-32K" is the comment about "…CRC-32K polynomial…" which is 0xEB31D82E in the code.


            The function is named CalcCRC32K().

            If I am trying to follow this example, I should not need to guess about what variables in the example correspond to what values in the text.  This should be extremely clear.

             

            What are your proposed changes?   Should I change the name of the formal parameter "crcValue"
            to "crc32k" or "crc32kValue"?

            Won't this hypothetical reader be similarly confused by the example in G.2.1?

            Regarding making the picture labels in the Rationale match the text, is this because of copyright restrictions or because of picture editing capabilities?


            I am concerned about modifying it, then citing it as someone else's work.  If you feel that agreement
            with the figure is paramount, then the better course is to change the text to agree with the drawing.
            Two years from now, the rationale will be gone but the text in the standard will persist.  Searching
            on "CCITT-16 CRC" will still get you to the Wikipedia "Cyclic redundancy check" article, where it is
            consistently referred to as "CRC-16-CCITT".
             

              If it is due to picture editing capabilities, I am attaching a modified picture (gif and jpg formats) made in just a few minutes with only the clunky picture editing tools that come with Windows 7.  A better modification could be done with decent tools, but this looked satisfactory.

             

            In most of this debate, my concern is that the people trying to implement this may NOT be COBS encoding experts or even communications experts.  They should not be required to study the background material before being able to implement the BACnet standard.  They should not need to guess about what the examples mean.  When I read this from the prospective of someone seeing it for the first time, it is much harder to follow than it should or could be.

             

            I'm not seeking a debate, but convergence.  I'm only pushing back in areas that make the proposal
            inconsistent with the existing literature or language used elsewhere in Clause 9. 

            I do not believe this proposal can be made perfect, no matter how long we work on it.  However, it
            should be standalone (when placed in context with the existing Clause 9) and understandable by
            a good majority of those "skilled in the art".  If the proposal does not yet meet that standard then I
            welcome any proposed text that will improve it.

            Lastly, I want to reiterate that this is an *optional* feature for all but BACnet router vendors who
            claim conformance to the latest standard, so clearly the goal must be to capture 100% of that
            audience (I assume they are communication experts, or at least should be).  I have a complete
            set of patches for Steve Karg's open BACnet stack (for his BDK board) as well as a Wireshark
            dissector.  I can copy these up to the mstpwg files area during the holiday break if that would be
            helpful.

            Regards, -K-

            Cliff Copass

            Johnson Controls, Inc.

             

            From: Kerry Lynn [mailto:kerlyn2001@...]
            Sent: Monday, December 16, 2013 1:06 PM
            To: Clifford H Copass
            Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

             

            Clif,

            Thanks for your comments.  See my responses inline...

             

            On Mon, Dec 16, 2013 at 9:33 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

            Some ideas and suggestions:

             

            Regarding the use of "CodeOctet":

            I think this can be resolved in the "9.5.2 Variables" section.  "Code block" is repeatedly used with no reference as to what that means at this point in the text.  Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block.  Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.

            Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):

            "Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."

            What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.

             

            DecodeCount, DecodeIndex, CodeOctet, LastCode, and DataOctet are local variables used
            by the procedure in 9.10.3.  John Hartman suggested moving them out of 9.5.2 (since they

            are not used at all by the state machines) but I failed to heed his advice.  I think moving the

            variables would be a better solution than to have multiple terms for the same concept.  "Code

            block" is used consistently in the literature describing COBS, and it is used liberally throughout

            the proposal.  A less disruptive change would be to have a forward pointer to 9.10.3 at the
            first mention of "code block".

             

            Regarding "CRC-32K register C31-C0":

            There needs to be a reference that exactly matches a register in the example.  Would this be "crcValue"?

             

            You need to first place G.3 in context.  G.1 (Header CRC) and G.2 (Data CRC) are
            essentially hardware-based descriptions that are then implemented as software
            examples.  I don't make any attempt to describe the CRC-32K examples from a

            hardware perspective, so maybe the first thing to do is drop the word "register".

            The language used in G.3 nearly identical to the earlier examples.  I have also used

            the same C API as shown in earlier examples.  It doesn't seem that folks have had

            difficulty associating the prose "CRC" with the formal parameter "crcValue" that is

            used in the C example.  The ASM example is just pulling the CRC bytes off the
            stack (i.e. there is no "name" for the parameter).

            Regarding "C31-C0", I thought that was a useful cue that the residue value shown

            just below that paragraph is in big-endian order.  I can remove "C31-C0" if that's the

            group consensus.

            Finally, there are at least four different concepts that I'm trying to keep straight

            through consistent use of different terms:  there's the "CRC32K" variable in 9.5.2
            which is the actual running accumulator, there's "CRC-32K" which is the name of
            the polynomial (and the calculation); there is "Modified CRC-32K" which is the

            one's complement of CRC-32K, ordered LSB first; and then there is the "Encoded

            CRC-32K" which is the Modified CRC-32K, COBS-encoded.

             

            If so, something like the following would be more enlightening:

            "In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."

            What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means.  The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones.  This would then read as:

            "In operation, the CRC32K register "crcValue" bits are initialized to all ones."

             

            How about "In operation, the CRC32K value is initialized to all ones."

             

            Consider changing:

            "See clause 19.X for the preferred approach for determining…"

            to something like

            "See clause 19.X for an approach for determining…"

             

            Done.
             

            Rationale:

            Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities."  I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).

             

            Sorry, I was looking at the first sentence.  You're right that the second sentence

            was incoherent.
             

            I would also like to see consistency in terminology for the uninitiated.  Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere.  Someone reading this for the first time may not realize these are the same thing.

             

            As I said in my previous post, "CRC-16-CCITT" seems to be the most popular
            search term for this polynomial so that's what I think should be used in the text.

            I can't change the picture, so if it's the group consensus that it's confusing then

            I will delete it.

            Regards, -K-

            Cliff Copass

             

             

            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
            Sent: Sunday, December 15, 2013 8:19 PM
            To: bacnet-mstpwg
            Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

             



            Hi Clif,

            Thanks for your comments.  Se my responses inline...

             

            On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

             

            I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

             

            The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

             

            The fundamental definition is given on page 20:
            "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

            So a COBS-encoded field consists one or more code blocks, each or which begins with
            a code octet. Without more detail, I'm not sure which sections of the text are causing

            confusion.

            On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

             

            The sentence

            is similar to the descriptions of the header and data CRC examples in Annex G.

            Would you just like to see "C31-C0" removed?

             

            On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

             

            What text would you propose?
             

            On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

             

            Would you propose to delete the first sentence?  It was perhaps more timely three years

            ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
            forbid the use of large frames with low baud rates, vendors will hopefully realize this is a

            bad combination.

            There are many variations on the name "CRC-16-CCITT" but they all refer to the same
            polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
            article on CRC polynomials.

            Please respond with your thoughts on the points above.

            Regards, -K-

             

            Cliff Copass

             

             

            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
            Sent: Tuesday, December 10, 2013 11:31 AM
            To: bacnet-mstpwg
            Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

             

            [Attachment(s) from Kerry Lynn included below]

            Greetings,

            I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
            area and have attached it here.

            It contains all the edits we discussed on last weeks call as well as resolutions to
            several good comments from John Hartman.

            This version contains a sample COBS-encoded frame (see X.4) but I did not have
            time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
            example code (X.3) so hopefully that will be sufficient.

            I also reversed spur-of-the-moment decision that we made on last weeks call,

            namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
            there are several good reasons for setting the range back to 32 - 127:

            a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

            b) That range was reduced to 32 - 127 just in case we ever want to define

                 more "legacy" frames

            c) The rationale for reducing the COBS-encoded range still further was "in

                case a new technology comes forward".  I doubt that will ever occur.

            d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

               would seriously complicate the document at this point.

            e) The only current use of this range in the proposal is for the purposes of

                validating header fields

            f) If we really think some new format may come out later, then we can deal with

               that possibility by allocating Frame Types from 34 on.  This will permit later

               definition of a new range after COBS-encoded.

            If this decision or lack of a flowchart is a show-stopper, then we should discuss it

            at the next SSPC.

            Regards, -K-

             




          • Clifford H Copass
            Perhaps if code block was defined in the context where it is used, that would be sufficient. CRC-32K seems to be a value while functions are not. Changing
            Message 7 of 10 , Dec 17, 2013
            • 0 Attachment

              Perhaps if "code block" was defined in the context where it is used, that would be sufficient.

               

              "CRC-32K" seems to be a value while functions are not.  Changing the name of "crcValue" may solve the issue - or even better, reference it somewhere (i.e. in a code comment within the example) that "crcValue" is the value of "CRC-32K" in this example.  I think the example in question supplies an updated "CRC-32K" through the return value "crc" which also needs to be specifically commented.  All examples should do this for all variables that relate to any term used in the text.

               

              If you want to keep the Rationale picture unchanged so it matches the original, then consider something like a parenthetical expression to explain the names are equivalent.

              for example

              "…Since the CRC-16-CCITT is widely used, (also known as CCITT-16 CRC)…"

               

              Cliff

               

               

              From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
              Sent: Tuesday, December 17, 2013 11:15 AM
              To: bacnet-mstpwg
              Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

               




              On Tue, Dec 17, 2013 at 9:23 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

               

              [Attachment(s) from Clifford H Copass included below]

              I don't really want to keep this back and forth running longer because we can continue based on public review comments, but I can't resist a little more…

               

              Regarding the term "CodeOctet" and its definition - When I see "Code block", I immediately think of part of a computer program subroutine and have no concept of a COBS encoded data block.  I believe this may be true for a large part of the audience for this document since it will be computer programming people trying to implement it.

               

              John Hartman's proposal was to place all references to "code block" after the definition.  Is
              this acceptable?

               

              You're not suggesting that "code block" be replaced everywhere it appears in the document?

              That would make our descriptions inconsistent with all the existing literature on COBS, including
              Stuart Cheshire's PhD thesis (Stanford University) where it occurs nearly 70 times.

              I agree that this optional feature will be difficult to implement for anyone who is unable (or unwilling)
              to read the description and relate it to the examples and sample code.  When I'm in that situation,
              I search for and read papers on the topic.

               

              When I look at the "C" code example on page 25, the only thing I see labeled "CRC-32K" is the comment about "…CRC-32K polynomial…" which is 0xEB31D82E in the code.

               

              The function is named CalcCRC32K().

              If I am trying to follow this example, I should not need to guess about what variables in the example correspond to what values in the text.  This should be extremely clear.

               

              What are your proposed changes?   Should I change the name of the formal parameter "crcValue"
              to "crc32k" or "crc32kValue"?

              Won't this hypothetical reader be similarly confused by the example in G.2.1?

              Regarding making the picture labels in the Rationale match the text, is this because of copyright restrictions or because of picture editing capabilities?

               

              I am concerned about modifying it, then citing it as someone else's work.  If you feel that agreement

              with the figure is paramount, then the better course is to change the text to agree with the drawing.
              Two years from now, the rationale will be gone but the text in the standard will persist.  Searching

              on "CCITT-16 CRC" will still get you to the Wikipedia "Cyclic redundancy check" article, where it is
              consistently referred to as "CRC-16-CCITT".

               

                If it is due to picture editing capabilities, I am attaching a modified picture (gif and jpg formats) made in just a few minutes with only the clunky picture editing tools that come with Windows 7.  A better modification could be done with decent tools, but this looked satisfactory.

               

              In most of this debate, my concern is that the people trying to implement this may NOT be COBS encoding experts or even communications experts.  They should not be required to study the background material before being able to implement the BACnet standard.  They should not need to guess about what the examples mean.  When I read this from the prospective of someone seeing it for the first time, it is much harder to follow than it should or could be.

               

              I'm not seeking a debate, but convergence.  I'm only pushing back in areas that make the proposal

              inconsistent with the existing literature or language used elsewhere in Clause 9. 


              I do not believe this proposal can be made perfect, no matter how long we work on it.  However, it
              should be standalone (when placed in context with the existing Clause 9) and understandable by
              a good majority of those "skilled in the art".  If the proposal does not yet meet that standard then I

              welcome any proposed text that will improve it.

              Lastly, I want to reiterate that this is an *optional* feature for all but BACnet router vendors who

              claim conformance to the latest standard, so clearly the goal must be to capture 100% of that
              audience (I assume they are communication experts, or at least should be).  I have a complete
              set of patches for Steve Karg's open BACnet stack (for his BDK board) as well as a Wireshark
              dissector.  I can copy these up to the mstpwg files area during the holiday break if that would be

              helpful.

              Regards, -K-

               

              Cliff Copass

              Johnson Controls, Inc.

               

              From: Kerry Lynn [mailto:kerlyn2001@...]
              Sent: Monday, December 16, 2013 1:06 PM
              To: Clifford H Copass
              Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

               

              Clif,

              Thanks for your comments.  See my responses inline...

               

              On Mon, Dec 16, 2013 at 9:33 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

              Some ideas and suggestions:

               

              Regarding the use of "CodeOctet":

              I think this can be resolved in the "9.5.2 Variables" section.  "Code block" is repeatedly used with no reference as to what that means at this point in the text.  Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block.  Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.

              Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):

              "Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."

              What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.

               

              DecodeCount, DecodeIndex, CodeOctet, LastCode, and DataOctet are local variables used
              by the procedure in 9.10.3.  John Hartman suggested moving them out of 9.5.2 (since they

              are not used at all by the state machines) but I failed to heed his advice.  I think moving the

              variables would be a better solution than to have multiple terms for the same concept.  "Code

              block" is used consistently in the literature describing COBS, and it is used liberally throughout

              the proposal.  A less disruptive change would be to have a forward pointer to 9.10.3 at the
              first mention of "code block".

               

              Regarding "CRC-32K register C31-C0":

              There needs to be a reference that exactly matches a register in the example.  Would this be "crcValue"?

               

              You need to first place G.3 in context.  G.1 (Header CRC) and G.2 (Data CRC) are
              essentially hardware-based descriptions that are then implemented as software
              examples.  I don't make any attempt to describe the CRC-32K examples from a

              hardware perspective, so maybe the first thing to do is drop the word "register".

              The language used in G.3 nearly identical to the earlier examples.  I have also used

              the same C API as shown in earlier examples.  It doesn't seem that folks have had

              difficulty associating the prose "CRC" with the formal parameter "crcValue" that is

              used in the C example.  The ASM example is just pulling the CRC bytes off the
              stack (i.e. there is no "name" for the parameter).

              Regarding "C31-C0", I thought that was a useful cue that the residue value shown

              just below that paragraph is in big-endian order.  I can remove "C31-C0" if that's the

              group consensus.

              Finally, there are at least four different concepts that I'm trying to keep straight

              through consistent use of different terms:  there's the "CRC32K" variable in 9.5.2
              which is the actual running accumulator, there's "CRC-32K" which is the name of
              the polynomial (and the calculation); there is "Modified CRC-32K" which is the

              one's complement of CRC-32K, ordered LSB first; and then there is the "Encoded

              CRC-32K" which is the Modified CRC-32K, COBS-encoded.

               

              If so, something like the following would be more enlightening:

              "In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."

              What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means.  The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones.  This would then read as:

              "In operation, the CRC32K register "crcValue" bits are initialized to all ones."

               

              How about "In operation, the CRC32K value is initialized to all ones."

               

              Consider changing:

              "See clause 19.X for the preferred approach for determining…"

              to something like

              "See clause 19.X for an approach for determining…"

               

              Done.
               

              Rationale:

              Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities."  I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).

               

              Sorry, I was looking at the first sentence.  You're right that the second sentence

              was incoherent.
               

              I would also like to see consistency in terminology for the uninitiated.  Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere.  Someone reading this for the first time may not realize these are the same thing.

               

              As I said in my previous post, "CRC-16-CCITT" seems to be the most popular
              search term for this polynomial so that's what I think should be used in the text.

              I can't change the picture, so if it's the group consensus that it's confusing then

              I will delete it.

              Regards, -K-

              Cliff Copass

               

               

              From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
              Sent: Sunday, December 15, 2013 8:19 PM
              To: bacnet-mstpwg
              Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

               

               

              Hi Clif,

              Thanks for your comments.  Se my responses inline...

               

              On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

               

              I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

               

              The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

               

              The fundamental definition is given on page 20:
              "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

              So a COBS-encoded field consists one or more code blocks, each or which begins with
              a code octet. Without more detail, I'm not sure which sections of the text are causing

              confusion.

              On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

               

              The sentence

              is similar to the descriptions of the header and data CRC examples in Annex G.

              Would you just like to see "C31-C0" removed?

               

              On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

               

              What text would you propose?
               

              On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

               

              Would you propose to delete the first sentence?  It was perhaps more timely three years

              ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
              forbid the use of large frames with low baud rates, vendors will hopefully realize this is a

              bad combination.

              There are many variations on the name "CRC-16-CCITT" but they all refer to the same
              polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
              article on CRC polynomials.

              Please respond with your thoughts on the points above.

              Regards, -K-

               

              Cliff Copass

               

               

              From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
              Sent: Tuesday, December 10, 2013 11:31 AM
              To: bacnet-mstpwg
              Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

               

              [Attachment(s) from Kerry Lynn included below]

              Greetings,

              I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
              area and have attached it here.

              It contains all the edits we discussed on last weeks call as well as resolutions to
              several good comments from John Hartman.

              This version contains a sample COBS-encoded frame (see X.4) but I did not have
              time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
              example code (X.3) so hopefully that will be sufficient.

              I also reversed spur-of-the-moment decision that we made on last weeks call,

              namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
              there are several good reasons for setting the range back to 32 - 127:

              a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

              b) That range was reduced to 32 - 127 just in case we ever want to define

                   more "legacy" frames

              c) The rationale for reducing the COBS-encoded range still further was "in

                  case a new technology comes forward".  I doubt that will ever occur.

              d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

                 would seriously complicate the document at this point.

              e) The only current use of this range in the proposal is for the purposes of

                  validating header fields

              f) If we really think some new format may come out later, then we can deal with

                 that possibility by allocating Frame Types from 34 on.  This will permit later

                 definition of a new range after COBS-encoded.

              If this decision or lack of a flowchart is a show-stopper, then we should discuss it

              at the next SSPC.

              Regards, -K-

               

               

               




            • Kerry Lynn
              Clif et al. Please review -rc5 (just uploaded) to see if it addresses all of your comments. Thanks, -K- On Tue, Dec 17, 2013 at 12:56 PM, Clifford H Copass
              Message 8 of 10 , Dec 19, 2013
              • 0 Attachment
                Clif et al.

                Please review -rc5 (just uploaded) to see if it addresses all of your comments.

                Thanks, -K-



                On Tue, Dec 17, 2013 at 12:56 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                Perhaps if "code block" was defined in the context where it is used, that would be sufficient.

                 

                "CRC-32K" seems to be a value while functions are not.  Changing the name of "crcValue" may solve the issue - or even better, reference it somewhere (i.e. in a code comment within the example) that "crcValue" is the value of "CRC-32K" in this example.  I think the example in question supplies an updated "CRC-32K" through the return value "crc" which also needs to be specifically commented.  All examples should do this for all variables that relate to any term used in the text.

                 

                If you want to keep the Rationale picture unchanged so it matches the original, then consider something like a parenthetical expression to explain the names are equivalent.

                for example

                "…Since the CRC-16-CCITT is widely used, (also known as CCITT-16 CRC)…"

                 

                Cliff

                 

                 

                From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                Sent: Tuesday, December 17, 2013 11:15 AM


                To: bacnet-mstpwg
                Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                 




                On Tue, Dec 17, 2013 at 9:23 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                 

                [Attachment(s) from Clifford H Copass included below]

                I don't really want to keep this back and forth running longer because we can continue based on public review comments, but I can't resist a little more…

                 

                Regarding the term "CodeOctet" and its definition - When I see "Code block", I immediately think of part of a computer program subroutine and have no concept of a COBS encoded data block.  I believe this may be true for a large part of the audience for this document since it will be computer programming people trying to implement it.

                 

                John Hartman's proposal was to place all references to "code block" after the definition.  Is
                this acceptable?

                 

                You're not suggesting that "code block" be replaced everywhere it appears in the document?

                That would make our descriptions inconsistent with all the existing literature on COBS, including
                Stuart Cheshire's PhD thesis (Stanford University) where it occurs nearly 70 times.

                I agree that this optional feature will be difficult to implement for anyone who is unable (or unwilling)
                to read the description and relate it to the examples and sample code.  When I'm in that situation,
                I search for and read papers on the topic.

                 

                When I look at the "C" code example on page 25, the only thing I see labeled "CRC-32K" is the comment about "…CRC-32K polynomial…" which is 0xEB31D82E in the code.

                 

                The function is named CalcCRC32K().

                If I am trying to follow this example, I should not need to guess about what variables in the example correspond to what values in the text.  This should be extremely clear.

                 

                What are your proposed changes?   Should I change the name of the formal parameter "crcValue"
                to "crc32k" or "crc32kValue"?

                Won't this hypothetical reader be similarly confused by the example in G.2.1?

                Regarding making the picture labels in the Rationale match the text, is this because of copyright restrictions or because of picture editing capabilities?

                 

                I am concerned about modifying it, then citing it as someone else's work.  If you feel that agreement

                with the figure is paramount, then the better course is to change the text to agree with the drawing.
                Two years from now, the rationale will be gone but the text in the standard will persist.  Searching

                on "CCITT-16 CRC" will still get you to the Wikipedia "Cyclic redundancy check" article, where it is
                consistently referred to as "CRC-16-CCITT".

                 

                  If it is due to picture editing capabilities, I am attaching a modified picture (gif and jpg formats) made in just a few minutes with only the clunky picture editing tools that come with Windows 7.  A better modification could be done with decent tools, but this looked satisfactory.

                 

                In most of this debate, my concern is that the people trying to implement this may NOT be COBS encoding experts or even communications experts.  They should not be required to study the background material before being able to implement the BACnet standard.  They should not need to guess about what the examples mean.  When I read this from the prospective of someone seeing it for the first time, it is much harder to follow than it should or could be.

                 

                I'm not seeking a debate, but convergence.  I'm only pushing back in areas that make the proposal

                inconsistent with the existing literature or language used elsewhere in Clause 9. 


                I do not believe this proposal can be made perfect, no matter how long we work on it.  However, it
                should be standalone (when placed in context with the existing Clause 9) and understandable by
                a good majority of those "skilled in the art".  If the proposal does not yet meet that standard then I

                welcome any proposed text that will improve it.

                Lastly, I want to reiterate that this is an *optional* feature for all but BACnet router vendors who

                claim conformance to the latest standard, so clearly the goal must be to capture 100% of that
                audience (I assume they are communication experts, or at least should be).  I have a complete
                set of patches for Steve Karg's open BACnet stack (for his BDK board) as well as a Wireshark
                dissector.  I can copy these up to the mstpwg files area during the holiday break if that would be

                helpful.

                Regards, -K-

                 

                Cliff Copass

                Johnson Controls, Inc.

                 

                From: Kerry Lynn [mailto:kerlyn2001@...]
                Sent: Monday, December 16, 2013 1:06 PM
                To: Clifford H Copass
                Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                 

                Clif,

                Thanks for your comments.  See my responses inline...

                 

                On Mon, Dec 16, 2013 at 9:33 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                Some ideas and suggestions:

                 

                Regarding the use of "CodeOctet":

                I think this can be resolved in the "9.5.2 Variables" section.  "Code block" is repeatedly used with no reference as to what that means at this point in the text.  Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block.  Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.

                Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):

                "Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."

                What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.

                 

                DecodeCount, DecodeIndex, CodeOctet, LastCode, and DataOctet are local variables used
                by the procedure in 9.10.3.  John Hartman suggested moving them out of 9.5.2 (since they

                are not used at all by the state machines) but I failed to heed his advice.  I think moving the

                variables would be a better solution than to have multiple terms for the same concept.  "Code

                block" is used consistently in the literature describing COBS, and it is used liberally throughout

                the proposal.  A less disruptive change would be to have a forward pointer to 9.10.3 at the
                first mention of "code block".

                 

                Regarding "CRC-32K register C31-C0":

                There needs to be a reference that exactly matches a register in the example.  Would this be "crcValue"?

                 

                You need to first place G.3 in context.  G.1 (Header CRC) and G.2 (Data CRC) are
                essentially hardware-based descriptions that are then implemented as software
                examples.  I don't make any attempt to describe the CRC-32K examples from a

                hardware perspective, so maybe the first thing to do is drop the word "register".

                The language used in G.3 nearly identical to the earlier examples.  I have also used

                the same C API as shown in earlier examples.  It doesn't seem that folks have had

                difficulty associating the prose "CRC" with the formal parameter "crcValue" that is

                used in the C example.  The ASM example is just pulling the CRC bytes off the
                stack (i.e. there is no "name" for the parameter).

                Regarding "C31-C0", I thought that was a useful cue that the residue value shown

                just below that paragraph is in big-endian order.  I can remove "C31-C0" if that's the

                group consensus.

                Finally, there are at least four different concepts that I'm trying to keep straight

                through consistent use of different terms:  there's the "CRC32K" variable in 9.5.2
                which is the actual running accumulator, there's "CRC-32K" which is the name of
                the polynomial (and the calculation); there is "Modified CRC-32K" which is the

                one's complement of CRC-32K, ordered LSB first; and then there is the "Encoded

                CRC-32K" which is the Modified CRC-32K, COBS-encoded.

                 

                If so, something like the following would be more enlightening:

                "In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."

                What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means.  The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones.  This would then read as:

                "In operation, the CRC32K register "crcValue" bits are initialized to all ones."

                 

                How about "In operation, the CRC32K value is initialized to all ones."

                 

                Consider changing:

                "See clause 19.X for the preferred approach for determining…"

                to something like

                "See clause 19.X for an approach for determining…"

                 

                Done.
                 

                Rationale:

                Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities."  I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).

                 

                Sorry, I was looking at the first sentence.  You're right that the second sentence

                was incoherent.
                 

                I would also like to see consistency in terminology for the uninitiated.  Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere.  Someone reading this for the first time may not realize these are the same thing.

                 

                As I said in my previous post, "CRC-16-CCITT" seems to be the most popular
                search term for this polynomial so that's what I think should be used in the text.

                I can't change the picture, so if it's the group consensus that it's confusing then

                I will delete it.

                Regards, -K-

                Cliff Copass

                 

                 

                From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                Sent: Sunday, December 15, 2013 8:19 PM
                To: bacnet-mstpwg
                Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                 

                 

                Hi Clif,

                Thanks for your comments.  Se my responses inline...

                 

                On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                 

                I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

                 

                The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

                 

                The fundamental definition is given on page 20:
                "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

                So a COBS-encoded field consists one or more code blocks, each or which begins with
                a code octet. Without more detail, I'm not sure which sections of the text are causing

                confusion.

                On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

                 

                The sentence

                is similar to the descriptions of the header and data CRC examples in Annex G.

                Would you just like to see "C31-C0" removed?

                 

                On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

                 

                What text would you propose?
                 

                On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

                 

                Would you propose to delete the first sentence?  It was perhaps more timely three years

                ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
                forbid the use of large frames with low baud rates, vendors will hopefully realize this is a

                bad combination.

                There are many variations on the name "CRC-16-CCITT" but they all refer to the same
                polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
                article on CRC polynomials.

                Please respond with your thoughts on the points above.

                Regards, -K-

                 

                Cliff Copass

                 

                 

                From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                Sent: Tuesday, December 10, 2013 11:31 AM
                To: bacnet-mstpwg
                Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

                 

                [Attachment(s) from Kerry Lynn included below]

                Greetings,

                I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
                area and have attached it here.

                It contains all the edits we discussed on last weeks call as well as resolutions to
                several good comments from John Hartman.

                This version contains a sample COBS-encoded frame (see X.4) but I did not have
                time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
                example code (X.3) so hopefully that will be sufficient.

                I also reversed spur-of-the-moment decision that we made on last weeks call,

                namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
                there are several good reasons for setting the range back to 32 - 127:

                a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

                b) That range was reduced to 32 - 127 just in case we ever want to define

                     more "legacy" frames

                c) The rationale for reducing the COBS-encoded range still further was "in

                    case a new technology comes forward".  I doubt that will ever occur.

                d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

                   would seriously complicate the document at this point.

                e) The only current use of this range in the proposal is for the purposes of

                    validating header fields

                f) If we really think some new format may come out later, then we can deal with

                   that possibility by allocating Frame Types from 34 on.  This will permit later

                   definition of a new range after COBS-encoded.

                If this decision or lack of a flowchart is a show-stopper, then we should discuss it

                at the next SSPC.

                Regards, -K-

                 

                 

                 





              • Clifford H Copass
                Sorry for being late getting back on this - I was out of the office for some time. Looks like we should be good to go for public review. (I voted Yes). My
                Message 9 of 10 , Jan 2, 2014
                • 0 Attachment

                  Sorry for being late getting back on this - I was out of the office for some time.

                  Looks like we should be good to go for public review.  (I voted Yes).

                  My intent was to clean up as much confusion as possible within the bounds of editorial updates.  This is harder outside of the face to face meetings (but does allow more time to read in detail).

                   

                  Cliff Copass

                   

                   

                  From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                  Sent: Thursday, December 19, 2013 11:18 AM
                  To: Clifford H Copass; bacnet-mstpwg
                  Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                   




                  Clif et al.

                  Please review -rc5 (just uploaded) to see if it addresses all of your comments.

                  Thanks, -K-

                   

                  On Tue, Dec 17, 2013 at 12:56 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                  Perhaps if "code block" was defined in the context where it is used, that would be sufficient.

                   

                  "CRC-32K" seems to be a value while functions are not.  Changing the name of "crcValue" may solve the issue - or even better, reference it somewhere (i.e. in a code comment within the example) that "crcValue" is the value of "CRC-32K" in this example.  I think the example in question supplies an updated "CRC-32K" through the return value "crc" which also needs to be specifically commented.  All examples should do this for all variables that relate to any term used in the text.

                   

                  If you want to keep the Rationale picture unchanged so it matches the original, then consider something like a parenthetical expression to explain the names are equivalent.

                  for example

                  "…Since the CRC-16-CCITT is widely used, (also known as CCITT-16 CRC)…"

                   

                  Cliff

                   

                   

                  From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                  Sent: Tuesday, December 17, 2013 11:15 AM


                  To: bacnet-mstpwg
                  Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                   



                  On Tue, Dec 17, 2013 at 9:23 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                   

                  [Attachment(s) from Clifford H Copass included below]

                  I don't really want to keep this back and forth running longer because we can continue based on public review comments, but I can't resist a little more…

                   

                  Regarding the term "CodeOctet" and its definition - When I see "Code block", I immediately think of part of a computer program subroutine and have no concept of a COBS encoded data block.  I believe this may be true for a large part of the audience for this document since it will be computer programming people trying to implement it.

                   

                  John Hartman's proposal was to place all references to "code block" after the definition.  Is
                  this acceptable?

                   

                  You're not suggesting that "code block" be replaced everywhere it appears in the document?

                  That would make our descriptions inconsistent with all the existing literature on COBS, including
                  Stuart Cheshire's PhD thesis (Stanford University) where it occurs nearly 70 times.

                  I agree that this optional feature will be difficult to implement for anyone who is unable (or unwilling)
                  to read the description and relate it to the examples and sample code.  When I'm in that situation,
                  I search for and read papers on the topic.

                   

                  When I look at the "C" code example on page 25, the only thing I see labeled "CRC-32K" is the comment about "…CRC-32K polynomial…" which is 0xEB31D82E in the code.

                   

                  The function is named CalcCRC32K().

                  If I am trying to follow this example, I should not need to guess about what variables in the example correspond to what values in the text.  This should be extremely clear.

                   

                  What are your proposed changes?   Should I change the name of the formal parameter "crcValue"
                  to "crc32k" or "crc32kValue"?

                  Won't this hypothetical reader be similarly confused by the example in G.2.1?

                  Regarding making the picture labels in the Rationale match the text, is this because of copyright restrictions or because of picture editing capabilities?

                   

                  I am concerned about modifying it, then citing it as someone else's work.  If you feel that agreement

                  with the figure is paramount, then the better course is to change the text to agree with the drawing.
                  Two years from now, the rationale will be gone but the text in the standard will persist.  Searching

                  on "CCITT-16 CRC" will still get you to the Wikipedia "Cyclic redundancy check" article, where it is
                  consistently referred to as "CRC-16-CCITT".

                   

                    If it is due to picture editing capabilities, I am attaching a modified picture (gif and jpg formats) made in just a few minutes with only the clunky picture editing tools that come with Windows 7.  A better modification could be done with decent tools, but this looked satisfactory.

                   

                  In most of this debate, my concern is that the people trying to implement this may NOT be COBS encoding experts or even communications experts.  They should not be required to study the background material before being able to implement the BACnet standard.  They should not need to guess about what the examples mean.  When I read this from the prospective of someone seeing it for the first time, it is much harder to follow than it should or could be.

                   

                  I'm not seeking a debate, but convergence.  I'm only pushing back in areas that make the proposal

                  inconsistent with the existing literature or language used elsewhere in Clause 9. 


                  I do not believe this proposal can be made perfect, no matter how long we work on it.  However, it
                  should be standalone (when placed in context with the existing Clause 9) and understandable by
                  a good majority of those "skilled in the art".  If the proposal does not yet meet that standard then I

                  welcome any proposed text that will improve it.

                  Lastly, I want to reiterate that this is an *optional* feature for all but BACnet router vendors who

                  claim conformance to the latest standard, so clearly the goal must be to capture 100% of that
                  audience (I assume they are communication experts, or at least should be).  I have a complete
                  set of patches for Steve Karg's open BACnet stack (for his BDK board) as well as a Wireshark
                  dissector.  I can copy these up to the mstpwg files area during the holiday break if that would be

                  helpful.

                  Regards, -K-

                   

                  Cliff Copass

                  Johnson Controls, Inc.

                   

                  From: Kerry Lynn [mailto:kerlyn2001@...]
                  Sent: Monday, December 16, 2013 1:06 PM
                  To: Clifford H Copass
                  Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                   

                  Clif,

                  Thanks for your comments.  See my responses inline...

                   

                  On Mon, Dec 16, 2013 at 9:33 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                  Some ideas and suggestions:

                   

                  Regarding the use of "CodeOctet":

                  I think this can be resolved in the "9.5.2 Variables" section.  "Code block" is repeatedly used with no reference as to what that means at this point in the text.  Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block.  Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.

                  Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):

                  "Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."

                  What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.

                   

                  DecodeCount, DecodeIndex, CodeOctet, LastCode, and DataOctet are local variables used
                  by the procedure in 9.10.3.  John Hartman suggested moving them out of 9.5.2 (since they

                  are not used at all by the state machines) but I failed to heed his advice.  I think moving the

                  variables would be a better solution than to have multiple terms for the same concept.  "Code

                  block" is used consistently in the literature describing COBS, and it is used liberally throughout

                  the proposal.  A less disruptive change would be to have a forward pointer to 9.10.3 at the
                  first mention of "code block".

                   

                  Regarding "CRC-32K register C31-C0":

                  There needs to be a reference that exactly matches a register in the example.  Would this be "crcValue"?

                   

                  You need to first place G.3 in context.  G.1 (Header CRC) and G.2 (Data CRC) are
                  essentially hardware-based descriptions that are then implemented as software
                  examples.  I don't make any attempt to describe the CRC-32K examples from a

                  hardware perspective, so maybe the first thing to do is drop the word "register".

                  The language used in G.3 nearly identical to the earlier examples.  I have also used

                  the same C API as shown in earlier examples.  It doesn't seem that folks have had

                  difficulty associating the prose "CRC" with the formal parameter "crcValue" that is

                  used in the C example.  The ASM example is just pulling the CRC bytes off the
                  stack (i.e. there is no "name" for the parameter).

                  Regarding "C31-C0", I thought that was a useful cue that the residue value shown

                  just below that paragraph is in big-endian order.  I can remove "C31-C0" if that's the

                  group consensus.

                  Finally, there are at least four different concepts that I'm trying to keep straight

                  through consistent use of different terms:  there's the "CRC32K" variable in 9.5.2
                  which is the actual running accumulator, there's "CRC-32K" which is the name of
                  the polynomial (and the calculation); there is "Modified CRC-32K" which is the

                  one's complement of CRC-32K, ordered LSB first; and then there is the "Encoded

                  CRC-32K" which is the Modified CRC-32K, COBS-encoded.

                   

                  If so, something like the following would be more enlightening:

                  "In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."

                  What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means.  The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones.  This would then read as:

                  "In operation, the CRC32K register "crcValue" bits are initialized to all ones."

                   

                  How about "In operation, the CRC32K value is initialized to all ones."

                   

                  Consider changing:

                  "See clause 19.X for the preferred approach for determining…"

                  to something like

                  "See clause 19.X for an approach for determining…"

                   

                  Done.
                   

                  Rationale:

                  Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities."  I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).

                   

                  Sorry, I was looking at the first sentence.  You're right that the second sentence

                  was incoherent.
                   

                  I would also like to see consistency in terminology for the uninitiated.  Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere.  Someone reading this for the first time may not realize these are the same thing.

                   

                  As I said in my previous post, "CRC-16-CCITT" seems to be the most popular
                  search term for this polynomial so that's what I think should be used in the text.

                  I can't change the picture, so if it's the group consensus that it's confusing then

                  I will delete it.

                  Regards, -K-

                  Cliff Copass

                   

                   

                  From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                  Sent: Sunday, December 15, 2013 8:19 PM
                  To: bacnet-mstpwg
                  Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                   

                   

                  Hi Clif,

                  Thanks for your comments.  Se my responses inline...

                   

                  On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                   

                  I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

                   

                  The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

                   

                  The fundamental definition is given on page 20:
                  "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

                  So a COBS-encoded field consists one or more code blocks, each or which begins with
                  a code octet. Without more detail, I'm not sure which sections of the text are causing

                  confusion.

                  On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

                   

                  The sentence

                  is similar to the descriptions of the header and data CRC examples in Annex G.

                  Would you just like to see "C31-C0" removed?

                   

                  On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

                   

                  What text would you propose?
                   

                  On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

                   

                  Would you propose to delete the first sentence?  It was perhaps more timely three years

                  ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
                  forbid the use of large frames with low baud rates, vendors will hopefully realize this is a

                  bad combination.

                  There are many variations on the name "CRC-16-CCITT" but they all refer to the same
                  polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
                  article on CRC polynomials.

                  Please respond with your thoughts on the points above.

                  Regards, -K-

                   

                  Cliff Copass

                   

                   

                  From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                  Sent: Tuesday, December 10, 2013 11:31 AM
                  To: bacnet-mstpwg
                  Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

                   

                  [Attachment(s) from Kerry Lynn included below]

                  Greetings,

                  I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
                  area and have attached it here.

                  It contains all the edits we discussed on last weeks call as well as resolutions to
                  several good comments from John Hartman.

                  This version contains a sample COBS-encoded frame (see X.4) but I did not have
                  time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
                  example code (X.3) so hopefully that will be sufficient.

                  I also reversed spur-of-the-moment decision that we made on last weeks call,

                  namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
                  there are several good reasons for setting the range back to 32 - 127:

                  a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

                  b) That range was reduced to 32 - 127 just in case we ever want to define

                       more "legacy" frames

                  c) The rationale for reducing the COBS-encoded range still further was "in

                      case a new technology comes forward".  I doubt that will ever occur.

                  d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

                     would seriously complicate the document at this point.

                  e) The only current use of this range in the proposal is for the purposes of

                      validating header fields

                  f) If we really think some new format may come out later, then we can deal with

                     that possibility by allocating Frame Types from 34 on.  This will permit later

                     definition of a new range after COBS-encoded.

                  If this decision or lack of a flowchart is a show-stopper, then we should discuss it

                  at the next SSPC.

                  Regards, -K-

                   

                   

                   



                   




                • Kerry Lynn
                  Hi Everyone, In addition to a fifth version of the 135-2012an PPR2 draft that covered Cliff s comments, I also uploaded a draft process for obtaining an MS/TP
                  Message 10 of 10 , Jan 2, 2014
                  • 0 Attachment
                    Hi Everyone,

                    In addition to a fifth version of the 135-2012an PPR2 draft that covered Cliff's
                    comments, I also uploaded a draft process for obtaining an MS/TP Frame Type
                    from ASHRAE.  I based this on the form that is used to apply for a Vendor ID.

                    Can you take a look at it and send any comments to this list?

                    Thanks, -K-




                    On Thu, Jan 2, 2014 at 3:30 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                    Sorry for being late getting back on this - I was out of the office for some time.

                    Looks like we should be good to go for public review.  (I voted Yes).

                    My intent was to clean up as much confusion as possible within the bounds of editorial updates.  This is harder outside of the face to face meetings (but does allow more time to read in detail).

                     

                    Cliff Copass

                     

                     

                    From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                    Sent: Thursday, December 19, 2013 11:18 AM
                    To: Clifford H Copass; bacnet-mstpwg


                    Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                     




                    Clif et al.

                    Please review -rc5 (just uploaded) to see if it addresses all of your comments.

                    Thanks, -K-

                     

                    On Tue, Dec 17, 2013 at 12:56 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                    Perhaps if "code block" was defined in the context where it is used, that would be sufficient.

                     

                    "CRC-32K" seems to be a value while functions are not.  Changing the name of "crcValue" may solve the issue - or even better, reference it somewhere (i.e. in a code comment within the example) that "crcValue" is the value of "CRC-32K" in this example.  I think the example in question supplies an updated "CRC-32K" through the return value "crc" which also needs to be specifically commented.  All examples should do this for all variables that relate to any term used in the text.

                     

                    If you want to keep the Rationale picture unchanged so it matches the original, then consider something like a parenthetical expression to explain the names are equivalent.

                    for example

                    "…Since the CRC-16-CCITT is widely used, (also known as CCITT-16 CRC)…"

                     

                    Cliff

                     

                     

                    From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                    Sent: Tuesday, December 17, 2013 11:15 AM


                    To: bacnet-mstpwg
                    Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                     



                    On Tue, Dec 17, 2013 at 9:23 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                     

                    [Attachment(s) from Clifford H Copass included below]

                    I don't really want to keep this back and forth running longer because we can continue based on public review comments, but I can't resist a little more…

                     

                    Regarding the term "CodeOctet" and its definition - When I see "Code block", I immediately think of part of a computer program subroutine and have no concept of a COBS encoded data block.  I believe this may be true for a large part of the audience for this document since it will be computer programming people trying to implement it.

                     

                    John Hartman's proposal was to place all references to "code block" after the definition.  Is
                    this acceptable?

                     

                    You're not suggesting that "code block" be replaced everywhere it appears in the document?

                    That would make our descriptions inconsistent with all the existing literature on COBS, including
                    Stuart Cheshire's PhD thesis (Stanford University) where it occurs nearly 70 times.

                    I agree that this optional feature will be difficult to implement for anyone who is unable (or unwilling)
                    to read the description and relate it to the examples and sample code.  When I'm in that situation,
                    I search for and read papers on the topic.

                     

                    When I look at the "C" code example on page 25, the only thing I see labeled "CRC-32K" is the comment about "…CRC-32K polynomial…" which is 0xEB31D82E in the code.

                     

                    The function is named CalcCRC32K().

                    If I am trying to follow this example, I should not need to guess about what variables in the example correspond to what values in the text.  This should be extremely clear.

                     

                    What are your proposed changes?   Should I change the name of the formal parameter "crcValue"
                    to "crc32k" or "crc32kValue"?

                    Won't this hypothetical reader be similarly confused by the example in G.2.1?

                    Regarding making the picture labels in the Rationale match the text, is this because of copyright restrictions or because of picture editing capabilities?

                     

                    I am concerned about modifying it, then citing it as someone else's work.  If you feel that agreement

                    with the figure is paramount, then the better course is to change the text to agree with the drawing.
                    Two years from now, the rationale will be gone but the text in the standard will persist.  Searching

                    on "CCITT-16 CRC" will still get you to the Wikipedia "Cyclic redundancy check" article, where it is
                    consistently referred to as "CRC-16-CCITT".

                     

                      If it is due to picture editing capabilities, I am attaching a modified picture (gif and jpg formats) made in just a few minutes with only the clunky picture editing tools that come with Windows 7.  A better modification could be done with decent tools, but this looked satisfactory.

                     

                    In most of this debate, my concern is that the people trying to implement this may NOT be COBS encoding experts or even communications experts.  They should not be required to study the background material before being able to implement the BACnet standard.  They should not need to guess about what the examples mean.  When I read this from the prospective of someone seeing it for the first time, it is much harder to follow than it should or could be.

                     

                    I'm not seeking a debate, but convergence.  I'm only pushing back in areas that make the proposal

                    inconsistent with the existing literature or language used elsewhere in Clause 9. 


                    I do not believe this proposal can be made perfect, no matter how long we work on it.  However, it
                    should be standalone (when placed in context with the existing Clause 9) and understandable by
                    a good majority of those "skilled in the art".  If the proposal does not yet meet that standard then I

                    welcome any proposed text that will improve it.

                    Lastly, I want to reiterate that this is an *optional* feature for all but BACnet router vendors who

                    claim conformance to the latest standard, so clearly the goal must be to capture 100% of that
                    audience (I assume they are communication experts, or at least should be).  I have a complete
                    set of patches for Steve Karg's open BACnet stack (for his BDK board) as well as a Wireshark
                    dissector.  I can copy these up to the mstpwg files area during the holiday break if that would be

                    helpful.

                    Regards, -K-

                     

                    Cliff Copass

                    Johnson Controls, Inc.

                     

                    From: Kerry Lynn [mailto:kerlyn2001@...]
                    Sent: Monday, December 16, 2013 1:06 PM
                    To: Clifford H Copass
                    Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                     

                    Clif,

                    Thanks for your comments.  See my responses inline...

                     

                    On Mon, Dec 16, 2013 at 9:33 AM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                    Some ideas and suggestions:

                     

                    Regarding the use of "CodeOctet":

                    I think this can be resolved in the "9.5.2 Variables" section.  "Code block" is repeatedly used with no reference as to what that means at this point in the text.  Also, it seems like a single "code block" is not so much decoded octet by octet as it is processed, since most of the decoding seems to happen at the block boundaries rather than within the block.  Finally, exclusively referring to "decoded" (multiple places in the variables section) leaves one wondering if there is any "encoding" required at all.

                    Consider something like the following for "CodeOctet" (and possibly similar changes elsewhere in the section):

                    "Used by devices that support COBS-encoded frames to count down the number of octets remaining to be processed in the current block of data within the frame."

                    What I am trying to get across here is that we are dealing with part of the frame (a subset) and to tie this into 9.10.3 where it refers to "Process a code octet" in several places.

                     

                    DecodeCount, DecodeIndex, CodeOctet, LastCode, and DataOctet are local variables used
                    by the procedure in 9.10.3.  John Hartman suggested moving them out of 9.5.2 (since they

                    are not used at all by the state machines) but I failed to heed his advice.  I think moving the

                    variables would be a better solution than to have multiple terms for the same concept.  "Code

                    block" is used consistently in the literature describing COBS, and it is used liberally throughout

                    the proposal.  A less disruptive change would be to have a forward pointer to 9.10.3 at the
                    first mention of "code block".

                     

                    Regarding "CRC-32K register C31-C0":

                    There needs to be a reference that exactly matches a register in the example.  Would this be "crcValue"?

                     

                    You need to first place G.3 in context.  G.1 (Header CRC) and G.2 (Data CRC) are
                    essentially hardware-based descriptions that are then implemented as software
                    examples.  I don't make any attempt to describe the CRC-32K examples from a

                    hardware perspective, so maybe the first thing to do is drop the word "register".

                    The language used in G.3 nearly identical to the earlier examples.  I have also used

                    the same C API as shown in earlier examples.  It doesn't seem that folks have had

                    difficulty associating the prose "CRC" with the formal parameter "crcValue" that is

                    used in the C example.  The ASM example is just pulling the CRC bytes off the
                    stack (i.e. there is no "name" for the parameter).

                    Regarding "C31-C0", I thought that was a useful cue that the residue value shown

                    just below that paragraph is in big-endian order.  I can remove "C31-C0" if that's the

                    group consensus.

                    Finally, there are at least four different concepts that I'm trying to keep straight

                    through consistent use of different terms:  there's the "CRC32K" variable in 9.5.2
                    which is the actual running accumulator, there's "CRC-32K" which is the name of
                    the polynomial (and the calculation); there is "Modified CRC-32K" which is the

                    one's complement of CRC-32K, ordered LSB first; and then there is the "Encoded

                    CRC-32K" which is the Modified CRC-32K, COBS-encoded.

                     

                    If so, something like the following would be more enlightening:

                    "In operation, the CRC32K register "crcValue" bits C31-C0 are initialized to all ones."

                    What I am trying to do here is to tie the text name (CRC32K) to a variable name used in the example and provide some hint as to what C32 (etc.) means.  The "C31-C0" part could be deleted since I don't think it adds much clarity since a register can have bits that can be initialized to all ones.  This would then read as:

                    "In operation, the CRC32K register "crcValue" bits are initialized to all ones."

                     

                    How about "In operation, the CRC32K value is initialized to all ones."

                     

                    Consider changing:

                    "See clause 19.X for the preferred approach for determining…"

                    to something like

                    "See clause 19.X for an approach for determining…"

                     

                    Done.
                     

                    Rationale:

                    Consider deleting the last two words of the first sentence so it ends "…as well as opening up future possibilities."  I don't think deleting the whole sentence is a good idea since it is the heart of the rationale (i.e. why do we want to make this change).

                     

                    Sorry, I was looking at the first sentence.  You're right that the second sentence

                    was incoherent.
                     

                    I would also like to see consistency in terminology for the uninitiated.  Use "CCITT-16 CRC" or "CRC-16-CCITT" or whatever is chosen everywhere.  Someone reading this for the first time may not realize these are the same thing.

                     

                    As I said in my previous post, "CRC-16-CCITT" seems to be the most popular
                    search term for this polynomial so that's what I think should be used in the text.

                    I can't change the picture, so if it's the group consensus that it's confusing then

                    I will delete it.

                    Regards, -K-

                    Cliff Copass

                     

                     

                    From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                    Sent: Sunday, December 15, 2013 8:19 PM
                    To: bacnet-mstpwg
                    Subject: Re: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm?

                     

                     

                    Hi Clif,

                    Thanks for your comments.  Se my responses inline...

                     

                    On Fri, Dec 13, 2013 at 5:21 PM, Clifford H Copass <Clifford.H.Copass@...> wrote:

                     

                    I have been reading through Add-135-2012an-PPR2-draft-rc4.docx and found some places that confuse me.  I am checking to see if I am missing something significant or if there are some editorial corrections that can be made before public review.

                     

                    The term "CodeOctet" is giving me some problems.  In some places it sounds like a data octet and in some places it sounds like an index.  Is this where the omitted "zeros" are added back in by counting down the block size?  If so, that could be clearer.

                     

                    The fundamental definition is given on page 20:
                    "A COBS code block consists of a single code octet, followed by zero or more data octets. The number of data octets is represented by the code octet."

                    So a COBS-encoded field consists one or more code blocks, each or which begins with
                    a code octet. Without more detail, I'm not sure which sections of the text are causing

                    confusion.

                    On page 25, I don't see what "CRC-32K register C31-C0" in the text has to do with the example code.

                     

                    The sentence

                    is similar to the descriptions of the header and data CRC examples in Annex G.

                    Would you just like to see "C31-C0" removed?

                     

                    On page 5, "See clause 19.X for the preferred approach…" seems too strong a statement.

                     

                    What text would you propose?
                     

                    On page 3, in the Rationale, the first sentence seems incomplete.  Also in the drawing, "CCITT-16 CRC" doesn't match the text which uses "CRC-16-CCITT".

                     

                    Would you propose to delete the first sentence?  It was perhaps more timely three years

                    ago when 115,200 baud had just been approved.  Although the proposal doesn't explicitly
                    forbid the use of large frames with low baud rates, vendors will hopefully realize this is a

                    bad combination.

                    There are many variations on the name "CRC-16-CCITT" but they all refer to the same
                    polynomial.  "CRC-16-CCITT" and "CRC-32K" are the names used in the Wikipedia
                    article on CRC polynomials.

                    Please respond with your thoughts on the points above.

                    Regards, -K-

                     

                    Cliff Copass

                     

                     

                    From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
                    Sent: Tuesday, December 10, 2013 11:31 AM
                    To: bacnet-mstpwg
                    Subject: [bacnet-mstpwg] Revised Addenda 2012an. Third time is the charm? [1 Attachment]

                     

                    [Attachment(s) from Kerry Lynn included below]

                    Greetings,

                    I have uploaded the third revision of the Add-135-2012an PPR2 draft up to the files
                    area and have attached it here.

                    It contains all the edits we discussed on last weeks call as well as resolutions to
                    several good comments from John Hartman.

                    This version contains a sample COBS-encoded frame (see X.4) but I did not have
                    time to do a flowchart for COBS-decoding.  We have pseudo-code (9.10.3) and
                    example code (X.3) so hopefully that will be sufficient.

                    I also reversed spur-of-the-moment decision that we made on last weeks call,

                    namely to define the range of Frame Types 32 - 63 as COBS-encoded.  I feel
                    there are several good reasons for setting the range back to 32 - 127:

                    a) We started PPR1 with the thoroughly MSTP-WG discussed range 8 - 127.

                    b) That range was reduced to 32 - 127 just in case we ever want to define

                         more "legacy" frames

                    c) The rationale for reducing the COBS-encoded range still further was "in

                        case a new technology comes forward".  I doubt that will ever occur.

                    d) Adding a third range, e.g. "Undefined", to "COBS-encoded" and "Non-encoded"

                       would seriously complicate the document at this point.

                    e) The only current use of this range in the proposal is for the purposes of

                        validating header fields

                    f) If we really think some new format may come out later, then we can deal with

                       that possibility by allocating Frame Types from 34 on.  This will permit later

                       definition of a new range after COBS-encoded.

                    If this decision or lack of a flowchart is a show-stopper, then we should discuss it

                    at the next SSPC.

                    Regards, -K-

                     

                     

                     



                     





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