OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

energyinterop message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (ENERGYINTEROP-423) Opt Out forindividual event; not in opt out message; is it in feedback?



    [ http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=26242#action_26242 ] 

William Cox commented on ENERGYINTEROP-423:
-------------------------------------------

I think that we need validation of this use case.  The posting of this item is the first that we've heard of this (so far as I can recall). The behavior in a contractual arrangement is "failure to perform" with all the implications and potential penalties.  Why is this any different, other than delivering a hint to the VTN to not expect any additional generation/response?

It seems an odd case, as all the behaviors except that notification can take place already.

So we need several steps:

FIRST step is justification of need -  to understand real business requirements and/or regulatory requirements for this behavior. Is this discussed in the Phase 2 NAESB requirements?

SECOND step if there is justification is for the TC to decide whether to support this behavior

THIRD step is to determine the solution. See below for my thoughts.

FOURTH step is to determine the release.  Given the timing of steps 1..3, I think this is post PR02. And if it's not picked up by the TC it's on the list of possible items post 1.0

FIFTH step is to do the work.



Here are my thoughts on how to accomplish the stated objective; I haven't seen the detailed use cases and business case for this behavior, so I'm presuming that steps one and two are completed and we're working on step three.

I'd see using either

(a) EiCancelEvent sent by the VEN, rather than the VTN. This has the defect that the event is not canceled, only that particular VTN's paricipation.

(b) EiCreatedEvent could be called up to twice; if first called by the VEN with accept, then it could be called once more with Failure.  This seems odd, and pushes the behavior into a re-used operation that confuses the flow.

(c) Create a new function, VEN is service consumer, VTN is service provider, say EiStopEvent, that would indicate the VEN's decision to no longer abide by its commitment in accepting the event in the first place.


> Opt Out for individual event; not in opt out message; is it in feedback?
> ------------------------------------------------------------------------
>
>                 Key: ENERGYINTEROP-423
>                 URL: http://tools.oasis-open.org/issues/browse/ENERGYINTEROP-423
>             Project: OASIS Energy Interoperation TC
>          Issue Type: Bug
>         Environment: Bruce Bartell
>            Reporter: Bruce Bartell
>            Assignee: Bruce Bartell
>
> Need the ability to opt out for an individual event. The event does not seem to be in the opt out message. Are we handling this through feedback message?

-- 
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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]