Subject: [mile] Proposed GRC Exchange Message Type changes

From: "Brugger, Terry [USA]" <[email-masked]>
Date: Tue, 24 Jul 2012 20:55:13 +0000

All,

I've been chatting with Dave Waltermire about the GRC Exchange Message Types
(Section 3.5 of the current draft-ietf-mile-grc-exchange-00). The original
motivation was just to add the concept of a command type. In the process the
issues of redundancy and overlap between Request and Query as well as Result
and Report came up. To that end, we'd like to propose some refactoring of
the GRC Exchange Message Types. At a high-level:
1. Rename Request type to ReportRequest type
2. Rename Query type to QueryRequest type
3. Remove Result type
4. Add StatusRequest type
5. Add ActionRequest type
6. Add ActionResult type
7. Keep Acknowledgement and Report types

This would mean a total of seven (7) message types.

Getting into the details of each:
1. ReportRequest: Includes a GRCPolicy, Request ID, and the Report ID for
the
   report being requested. Results in a Report (or Acknowledgement).
2. QueryRequest: Includes a GRCPolicy, Request ID, and an arbitrary (xs:any)
   query definition. Results in a Report (or Acknowledgement).
3. Report: Includes a GRCPolicy, and a Report ID. Returned in response to a
   ReportRequest, QueryRequest, or sent directly as in the Report
   Communication workflow shown in Section 7.1.
4. ActionRequest: Includes a GRCPolicy, Request ID, and an action command
   element, which will include the means to pass arbitrary action
parameters.
   Results in an ActionResult (or Acknowledgement).
5. ActionResult: Includes a GRCPolicy, the request ID of the original
   ActionRequest, and an arbitrary (xs:any) block describing the result,
which
   will vary depending on the action command requested; may be used to
   communicate technical failures, as opposed to failures due to policy that
   shall be communicated via an Acknowledgement message.
6. StatusRequest: Includes a GRCPolicy, Request ID, and the Request ID for
the
   original request for which the status is being requested. Results in an
   Acknowledgement.
7. Acknowledgement: Includes a GRCPolicy, the Request ID this
acknowledgement
   pertains to, a RequestStatus, and an arbitrary (xs:any) block of status
   information. The RequestStatus class should have elements added to it to
   capture execution status, for instance, "Queued", "Running", and
   "Complete". Returned in response to a StatusRequest, or in lieu of a
Report
   or ActionResult when appropriate.

We would appreciate feedback on the concept and details at this sort of high
level before proposing specific changes to the GRC-Exchange draft.

Cheers,
Terry

---
S Terry Brugger, Ph.D.
Lead Associate
Booz  | Allen | Hamilton 
-----------------------
Suite 3300
101 California Street
San Francisco CA 94111-5855 USA
209-640-0068 (mobile)
[email-masked]

---

From: Michael Hammer <[email-masked]>
Date: Wed, 25 Jul 2012 17:27:40 +0000

Terry,

I think something along the lines of the following would be cleaner:

1. GRC_Request: 
   Request ID,
   Request Type:  Report, Query, Action, Status
   GRCPolicy, 
   Filter parameters (xs:any)
     - Report ID parameters
     - Query parameters
     - Action parameters 
     - Status parameters (e.g. Request ID for the original request)

2. GRC_Result:
   Request ID,
   Request Type:  Report, Query, Action, Status
   GRCPolicy, 
   Result Payload:
     - Report results (status and parameters)
     - Query results (status and parameters)
     - Action results (status and parameters)
     - Status results (status and parameters)

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Brugger, Terry [USA]
Sent: Tuesday, July 24, 2012 4:55 PM
To: [email-masked]
Subject: [mile] Proposed GRC Exchange Message Type changes

All,

I've been chatting with Dave Waltermire about the GRC Exchange Message Types
(Section 3.5 of the current draft-ietf-mile-grc-exchange-00). The original
motivation was just to add the concept of a command type. In the process the
issues of redundancy and overlap between Request and Query as well as Result
and Report came up. To that end, we'd like to propose some refactoring of
the GRC Exchange Message Types. At a high-level:
1. Rename Request type to ReportRequest type 2. Rename Query type to
QueryRequest type 3. Remove Result type 4. Add StatusRequest type 5. Add
ActionRequest type 6. Add ActionResult type 7. Keep Acknowledgement and
Report types

Cheers,
Terry

---
S Terry Brugger, Ph.D.
Lead Associate
Booz  | Allen | Hamilton
-----------------------
Suite 3300
101 California Street

---

From: "Brugger, Terry [USA]" <[email-masked]>
Date: Mon, 30 Jul 2012 16:51:37 +0000

Mike,

Great feedback -- we thought about something along these lines. I rather
like the elegance of it. There were a couple issues, however:
1. A Report can either be in response to a Report Request, or can just be
sent, not in response to anything.
2. Is the Status Result the Result of the Request, or about the Request
itself?

The first point seems like merely an interpretation of the semantics of
"result" (or "Result"). The second seems like a serious point of confusion.
Hopefully this is something folks can discuss at the meeting this week.
Unfortunately I won't be there, but Dave will be.

Cheers,
Terry

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Wednesday, July 25, 2012 10:28 AM
> To: Brugger, Terry [USA]; [email-masked]
> Subject: [External] RE: Proposed GRC Exchange Message Type changes
> 
> Terry,
>

---

From: Michael Hammer <[email-masked]>
Date: Mon, 30 Jul 2012 17:13:05 +0000

Terry,

Without an initial request or "subscription" would an unsolicited report be
a form of spam?
Also, will it get through firewalls?

It might be possible to change the name to GRC_Info, 
And add a type on response side to be Autonomous Report.

For 2, I was thinking of the responses as reaction to the request payloads,
But there may be two aspects to answer the issue you raised:
1) Is there an underlying transport that would provider error indications?
2) If at this level, then an additional Response payload of Error result(s)
could be added.

Food for thought.

Mike

-----Original Message-----
From: Brugger, Terry [USA] [mailto:[email-masked]] 
Sent: Monday, July 30, 2012 12:52 PM
To: Michael Hammer; [email-masked]
Subject: RE: [External] RE: Proposed GRC Exchange Message Type changes

Mike,

Cheers,
Terry

---

From: "Brugger, Terry [USA]" <[email-masked]>
Date: Mon, 30 Jul 2012 23:03:36 +0000

Mike,

> Without an initial request or "subscription" would an unsolicited report
be

Heh -- hadn't thought of it that way, but I suppose so. I think the
difference is that for GRC Exchange you can stipulate that all the instances
you receive reports from sign them and automatically discard any reports
that are not signed, or not signed by an entity you are expecting reports
from.

> Also, will it get through firewalls?

Section 3.2 establishes that GRC-RE peers connect directly to one another,
so anyone setting up a GRC-RE instance would need to ensure that both
incoming and outgoing communication could take place with its peers on the
appropriate port(s).

> And add a type on response side to be Autonomous Report.

That could certainly work.

> 1) Is there an underlying transport that would provider error indications?

This actually brings up an excellent question: What should the underlying
transport be for GRC Exchange? This question came up at the Mitre Dev Days a
couple weeks ago. Should 6546 be modified to cover GRC-Exchange and not just
RID? Should a new RFC be drafted essentially copying 6546 but perhaps using
a different port and be focused purely on GRC-Exchange? Should we still
focus on SOAP-based services or incorporate RESTful services? As a
requirement or option? I might put out another message to the list with just
this question for anyone who didn't read through this discussion.

> 2) If at this level, then an additional Response payload of Error
result(s)

I think that may have some merit.

Great input Mike!

Cheers,
Terry