Re: [energyinterop] FW: Ack Ack

[Rik Drummond <rikd@drummondgroup.com>]

I would have to look at the spec in detail.  ACKs are protocol level specific.... Each level has their own to verify the packet was received without errors.  So using the OSI 7 layers, each layer would normally have it's own ACK structure.

One has to be careful using ACKs from lower levels in upper layers because ACKs may have different functional meanings.

That is not the answer, but it is all I have time for now.

ACKs may not, usually do not give nonrepudiation functionality... That requires digital signatures..

Rik





Sent from Rik's IPAD

Rik Drummond
CEO, Drummond Group Inc


On Mar 28, 2011, at 11:31 AM, "Gerald Gray" <gerald.gray@guiding-principle.com> wrote:

> Hi Rik, more importantly, would you concur that message acknowledgement is
> something that has been solved outside of the message payload and is part of
> implementation?
> 
> -----Original Message-----
> From: rik drummond [mailto:rikd@drummondgroup.com] 
> Sent: Monday, March 28, 2011 8:41 AM
> To: Gerald Gray
> Cc: <wtcox@coxsoftwarearchitects.com>; <energyinterop@lists.oasis-open.org>
> Subject: Re: [energyinterop] FW: Ack Ack
> 
> I expect you mean at the transfer level not the transport layer. Email and
> FTP are examples of transfer mechanisms. Tcp is a transfer layer of the OSI
> stack. 
> 
> Very best regards, Rik
> 
> Sent from Rik's iPhone
> 
> On Mar 27, 2011, at 10:47 AM, "Gerald Gray"
> <gerald.gray@guiding-principle.com> wrote:
> 
>> If we are concerned about reliable delivery this again is something that
> is
>> best handled at the transport layer.
>> 
>> If we are discussing security we can handle this at the transport layer
>> (TLS); cross certificates to handled non-repudiation, etc, and SAML if we
>> want to secure the payload.  These are outside the scope of the core
> message
>> payload.
>> 
>> I think the core question is "Do we need a set of standardized responses"?
>> My take is that the answer is "no".  Not when the sending and receiving is
>> handled by the transport layer and with message headers.
>> 
>> If I send a message the context and identification is in the service
> called
>> and the message headers provided.  If I receive a message I have this
>> identifying information, act according to my business process, and respond
>> based on the service called, identity and message headers provided.
>> 
>> -----Original Message-----
>> From: wtcox@coxsoftwarearchitects.com
>> [mailto:wtcox@coxsoftwarearchitects.com] 
>> Sent: Saturday, March 26, 2011 8:45 PM
>> To: energyinterop@lists.oasis-open.org
>> Subject: Re: [energyinterop] FW: Ack Ack
>> 
>> A bit less  elliptical...
>> 
>> Toby's #2 is sufficient if and only if no application information need be
>> exchanged (which may act as an application-level ACK as well. 
>> 
>> So #1 was described as application information beyond a simple ACK. So
>> perhaps the name should include "respnse" rather than the potentialy
>> misleading "ack". 
>> 
>> #3 is the mechanism for defining and evolving the set of standardized
>> responses. 
>> 
>> Bill 
>> 
>> 
>> Sent via BlackBerry by AT&T
>> 
>> -----Original Message-----
>> From: William Cox <wtcox@CoxSoftwareArchitects.com>
>> Date: Sat, 26 Mar 2011 17:23:37 
>> To: <energyinterop@lists.oasis-open.org>
>> Subject: Re: [energyinterop] FW: Ack Ack
>> 
>> There are several levels here.
>> 
>> First, there is a need for application level acknowledgment strings with 
>> specific meanings.  That was the reason for the strings.
>> 
>> Second, there is the "reliably delivered" aspect. One needs to compose 
>> the relevant and required security and reliability for each {VTN, VEN}
> set..
>> 
>> Third, the "reliable delivery" protocols are NOT a guarantee of ACTUAL 
>> Delivery. (offline discussion any time; they increase the likelihood 
>> that you can assume delivery once sent, but are not a panacea).
>> 
>> Toby's #2 addresses my first item.
>> 
>> bill
>> --
>> *William Cox*
>> Email: wtcox@CoxSoftwareArchitects.com 
>> <mailto:wtcox@CoxSoftwareArchitects.com>
>> Web: http://www.CoxSoftwareArchitects.com
>> +1 862 485 3696 mobile
>> +1 908 277 3460 fax
>> 
>> On 3/26/11 4:29 PM, Considine, Toby (Campus Services IT) wrote:
>>> 
>>> So the question I am wrestling with, in the specific context of the 
>>> recently published schemas for EI, is what to do with all the ACK 
>>> strings that are in messages.
>>> 
>>> (1)They should be in an overall transaction framework, and are outside 
>>> of scope
>>> 
>>> (2)They have specific meaning and purpose, and give hints to the 
>>> overall transaction framework on how to track messages
>>> 
>>> (3)They have specific enumerations for each interaction type, and 
>>> those enumerations need to be understood by the consuming programs
>>> 
>>> Etc.
>>> 
>>> tc
>>> 
>>> ------------------------------------------------------------------------
>>> 
>>> "It is the theory that decides what can be observed."   - Albert Einstein
>>> 
>>> ------------------------------------------------------------------------
>>> 
>>> Toby Considine
>>> 
>>> Chair, OASIS oBIX Technical Committee
>>> U.S. National Inst. of Standards and Tech. Smart Grid Architecture 
>>> Committee
>>> 
>>> Facilities Technology Office
>>> University of North Carolina
>>> Chapel Hill, NC
>>> 
>>> 
>>> 
>>> 
>>> 
>>> Email: Toby.Considine@ unc.edu <mailto:Toby.Considine@fac.unc.edu>
>>> Phone: (919)962-9073
>>> 
>>> http://www.oasis-open.org
>>> 
>>> blog: www.NewDaedalus.com
>>> 
>>> *From:*Girish Ghatikar [mailto:gghatikar@lbl.gov]
>>> *Sent:* Saturday, March 26, 2011 4:03 PM
>>> *To:* Considine, Toby (Campus Services IT)
>>> *Cc:* energyinterop@lists.oasis-open.org
>>> *Subject:* Re: [energyinterop] FW: Ack Ack
>>> 
>>> It was my understanding that the ACK is part of the message transport 
>>> requirements. This visits TCP or UDP requirements (reliable vs. not 
>>> reliable transport). If the ACK is used in this context, we're 
>>> suggesting specific implementations (of course, version of UDP, 
>>> reliable UDP, acts mostly like TCP).
>>> 
>>> In OpenADR, we had a message "confirmation" on top of the 
>>> implementation-specific ACK. The confirmation goes beyond sending the 
>>> ID to confirm the receipt of message -- it also includes returning 
>>> some specific information as part of the message.
>>> 
>>> Thanks,
>>> 
>>> -Rish
>>> 
>>> On Sat, Mar 26, 2011 at 12:51 PM, Considine, Toby (Campus Services IT) 
>>> <Toby.Considine@unc.edu <mailto:Toby.Considine@unc.edu>> wrote:
>>> 
>>> Bringing back to the list.
>>> 
>>> *From:*Gerald Gray [mailto:gerald.gray@guiding-principle.com 
>>> <mailto:gerald.gray@guiding-principle.com>]
>>> *Sent:* Friday, March 25, 2011 4:30 PM
>>> *To:* Considine, Toby (Campus Services IT)
>>> *Subject:* RE: Ack Ack
>>> 
>>> Hi Toby, let's see if I can explain further.  I didn't know how much 
>>> detail I should go into the jira; didn't want to write a book if it 
>>> was something we were going to discuss on the call.
>>> 
>>> As noted in the jira we have various and sundry Ack types (love the 
>>> image below BTW -- big Bill The Cat fan).   For my part I am not 
>>> certain of the use of the Ack in the different payloads, hence my lack 
>>> of clarity in suggesting a fix.
>>> 
>>> It looks like this is something we want to set once we return the call 
>>> in the service operation.  Is this your understanding?  For example, 
>>> are we trying to do the following:
>>> 
>>> somemessage.gif
>>> 
>>> That is, after we have sent a message to System B, are we trying to 
>>> let System A know that we have received it?
>>> 
>>> If that is the purpose I think we can simply remove the various Acks 
>>> from the message payloads.  This is because normally an "ack" of this 
>>> sort is an implementation thing.  For example, if someone was going to 
>>> implement a web service there would be a message header associated 
>>> with the service that is going to contain bits of information 
>>> important to both System A and System B.  There would probably be a 
>>> unique ID for the message itself for example.  The "ack" aka return 
>>> (the dashed line in the diagram) would reference this ID (or other 
>>> identifying information) that tells System A "yep we got it".  For 
>>> this reason we don't need to include an Ack in the message payload; as 
>>> I said, it's an "implementation thing".
>>> 
>>> If Ack is not used for this purpose, i.e. some sort of status used by 
>>> System B, then we can delve into how we can abstract this out.
>>> 
>>> Does that makes sense?
>>> 
>>> Cheers -
>>> 
>>> *Gerald R. Gray, PhD*
>>> 
>>> *Guiding Principle Consulting*
>>> 
>>> PO Box 381
>>> 
>>> Laingsburg, MI 48848
>>> 
>>> cell: 517.455.4824 <tel:517.455.4824>| fax: 517.913.6024 
>>> <tel:517.913.6024>
>>> 
>>> *From:*Considine, Toby (Campus Services IT) 
>>> [mailto:Toby.Considine@unc.edu <mailto:Toby.Considine@unc.edu>]
>>> *Sent:* Friday, March 25, 2011 2:26 PM
>>> *To:* Gerald Gray
>>> *Subject:* Ack Ack
>>> 
>>> Can you give me more specific detail or say if I am on the right track?
>>> 
>>> Thanks
>>> 
>>> tc
>>> 
>>> Description: Bill the Cat sez 'ACK!'
>>> 
>>> "It is the theory that decides what can be observed."   - Albert Einstein
>>> 
>>> Toby Considine
>>> 
>>> Chair, OASIS oBIX Technical Committee
>>> 
>>> U.S. National Inst. of Standards and Tech. Smart Grid Architecture 
>>> Committee
>>> 
>>> Facilities Technology Office
>>> 
>>> University of North Carolina
>>> 
>>> Chapel Hill, NC
>>> 
>>> Email: Toby.Considine@ unc.edu <http://unc.edu>
>>> 
>>> Phone: (919)962-9073 <tel:%28919%29962-9073>
>>> 
>>> http://www.oasis-open.org
>>> 
>>> blog: www.NewDaedalus.com <http://www.NewDaedalus.com>
>>> 
>>> -----Original Message-----
>>> From: OASIS Issues Tracker 
>>> [mailto:workgroup_mailer@lists.oasis-open.org 
>>> <mailto:workgroup_mailer@lists.oasis-open.org>]
>>> Sent: Thursday, March 24, 2011 2:57 PM
>>> To: energyinterop@lists.oasis-open.org 
>>> <mailto:energyinterop@lists.oasis-open.org>
>>> Subject: [energyinterop] [OASIS Issue Tracker] Commented: 
>>> (ENERGYINTEROP-348) Use of "Ack" as a string
>>> 
>>>   [ 
>>> 
>> 
> http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348?page=com.atlassi
>> 
> an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=24965
>> #action_24965 
>>> 
>> 
> <http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348?page=com.atlass
>> 
> ian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=2496
>> 5#action_24965> 
>>> ]
>>> 
>>> Toby Considine commented on ENERGYINTEROP-348:
>>> 
>>> ----------------------------------------------
>>> 
>>> My favorite issue that I hhad not yet entered.
>>> 
>>> Do we need a Bool and the 61698, or one, or....
>>> 
>>> dateTime
>>> 
>>> reason - not enumerated, do we need to?
>>> 
>>> remark free form
>>> 
>>> status, recommend app specific enum...
>>> 
>>> Note that for types of documents, the status is regarding the subject 
>>> matter (e.g., TroubleTicket, SwitchingSchedule, Work, WorkTask, 
>>> Specification, TypeAsset, AssetModel, etc.) of this particular type of 
>>> document. It is not the status of the document, which is found in 
>>> 'docStatus'.
>>> 
>>>> Use of "Ack" as a string
>>> 
>>>> ------------------------
>>> 
>>>> 
>>> 
>>>>               Key: ENERGYINTEROP-348
>>> 
>>>>               URL: 
>>> http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-348
>>> 
>>>>           Project: OASIS Energy Interoperation TC
>>> 
>>>>        Issue Type: Bug
>>> 
>>>>        Components: model, schema
>>> 
>>>>  Affects Versions: wd22
>>> 
>>>>          Reporter: Gerald Gray
>>> 
>>>>          Assignee: William Cox
>>> 
>>>> 
>>> 
>>>> Throughout the model there are various uses of "ack" type attributes 
>>> which have been set to the data type of string.  An ack type action is 
>>> probably best reflected as a Boolean.
>>> 
>>>> However, the repeated uses of "ack" attributes throughout the model 
>>> suggest this attribute may be abstracted out.  In addition if more 
>>> information about an acknowledgement is needed there may be an 
>>> opportunity to leverage the Status class from CIM.
>>> 
>>>> IEC61968.Common.Status (compounded class) This class contains
>>> 
>>>> dateTime, reason, remark, value that may be leveraged for this purpose.
>>> 
>>> --
>>> 
>>> This message is automatically generated by JIRA.
>>> 
>>> -
>>> 
>>> If you think it was sent incorrectly contact one of the 
>>> administrators: 
>>> http://tools.oasis-open.org/issues/secure/Administrators.jspa
>>> 
>>> -
>>> 
>>> For more information on JIRA, see: http://www.atlassian.com/software/jira
>>> 
>>> ---------------------------------------------------------------------
>>> 
>>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> 
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Rish Ghatikar
>>> Lawrence Berkeley National Laboratory
>>> 1 Cyclotron Road, MS: 90-3111, Berkeley, CA 94720
>>> GGhatikar@lbl.gov <mailto:GGhatikar@lbl.gov> | +1 510.486.6768 | +1 
>>> 510.486.4089 [fax]
>>> 
>>> This email is intended for the addressee only and may contain 
>>> confidential information and should not be copied without permission. 
>>> If you are not the intended recipient, please contact the sender as 
>>> soon as possible and delete the email from computer[s].
>>> 
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>