Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt

From: Adam Montville <[email-masked]>
Date: Thu, 5 Dec 2013 01:37:52 +0000

Something I've found helpful in the past is to abstract a bit further from "user", "operator", "application" and simply reference all of them at once with the term "actor".

I also believe that listing *potential* acquisition methods is useful in at least the following way: Including a multitude of acquisition methods clearly signals our intent of finding information where it already exists, while not necessarily precluding our ability to *get* information when information does not exist.

Finally, I, too, like the notion of a work-flow scenario.  I don't want to be the one drawing a process diagram in an RFC, though. ;-)

awm
________________________________________
From: sacm [[email-masked]] on behalf of Henk Birkholz [[email-masked]]
Sent: Friday, November 22, 2013 3:27 AM
To: [email-masked]
Subject: Re: [sacm] FW: New Version Notification for    draft-ietf-sacm-use-cases-05.txt

Regarding the first two question in section 2:

1.) Security automation today often supports the user/operator, I think.
There are cases a security-process can be fully automated, of course,
and in order to manage the sheer amount of security related system
events automation is essential, but it seems to me that the complexity
and heterogeneity of root-causes (that might trigger the work-flow) make
the inclusion of a user/operator necessary.

2.) To include acquisition methods can provide an intuitive insight
about the scope and intend of the endpoint posture assessment domain, I
think. On one hand, that might bloat the use-case document a bit (and
maybe renders the title "sacm use cases" too specific?). On the other
hand, I like the inclusion of a work-flow scenario and I think it is a
good place to highlight acquisition methods.

- Henk

On 11/21/2013 12:27 AM, Waltermire, David A. wrote:
> I just posted an updated use case draft based on the editorial sessions during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to all that provided input.
>
> I used the word version that we edited as a starting point. Here is what I did:
>
> - I worked through the use cases we planned to remove and made sure to merge in any concepts that would be lost. If you submitted a previous use case that was removed, please double check that I didn't miss anything.
> - I broke up "Endpoint Identification and Assessment" into 3 distinct and somewhat separable use cases: "Endpoint Identification and Assessment Planning", "Endpoint Posture Attribute Value Collection", "Posture Evaluation". Please let me know what you think about this change.
> - Addressed some aspects of the discussion thread based on the working session changes. Please provide any suggested edits for aspects that I might have missed or got wrong.
>
> The rest of the changes can be found in the draft's change log.
>
> If possible, I'd like to get to a fairly stable place with this draft in the next revision or two to allow for progress to be made on the requirements. In addition to the embedded questions in the document, I'd like to focus on the following questions:
>
> Is the draft approachable for a newcomer to the effort? Do you see the updated use case structure as an improvement?
> Does this draft paint a complete enough picture? Are we missing any important concepts?
> Is there anything you can't live with?
>
> I hope to release at least one or two more updates to this draft within the next few weeks before the holidays catch up on us.  I know everyone is busy; timely comments are appreciated to allow for a quick turnaround on the next revision.
>
> Thanks,
> Dave
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, November 20, 2013 5:58 PM
> To: Waltermire, David A.; David Harrington
> Subject: New Version Notification for draft-ietf-sacm-use-cases-05.txt
>
>
> A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been successfully submitted by David Waltermire and posted to the IETF repository.
>
> Filename:      draft-ietf-sacm-use-cases
> Revision:      05
> Title:                 Endpoint Security Posture Assessment - Enterprise Use Cases
> Creation date:         2013-11-20
> Group:                 sacm
> Number of pages: 24
> URL:             http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-cases-05.txt
> Status:          http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> Htmlized:        http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05
>
> Abstract:
>     This memo documents a sampling of use cases for securely aggregating
>     configuration and operational data and evaluating that data to
>     determine an organization's security posture.  From these operational
>     use cases, we can derive common functional capabilities and
>     requirements to guide development of vendor-neutral, interoperable
>     standards for aggregating and evaluating data relevant to security
>     posture.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

...

. . .

---

From: "Waltermire, David A." <[email-masked]>
Date: Thu, 5 Dec 2013 01:53:37 +0000

Comments inline.

> From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
> Sent: Wednesday, December 04, 2013 8:38 PM
> To: Henk Birkholz; [email-masked]
> Something I've found helpful in the past is to abstract a bit further from
> "user", "operator", "application" and simply reference all of them at once
> with the term "actor".

Are we ok with the change to using actor? The current usage of "user", "operator", "application" (specifically the last two) was suggested a while back to align with IETF terminology. Does use of "actor" to reference all three concepts raise any concerns?

> I also believe that listing *potential* acquisition methods is useful in at least
> the following way: Including a multitude of acquisition methods clearly signals
> our intent of finding information where it already exists, while not
> necessarily precluding our ability to *get* information when information
> does not exist.

Adam, would you or Henk provide some example acquisition methods for discussion?

> Finally, I, too, like the notion of a work-flow scenario.  I don't want to be the
> one drawing a process diagram in an RFC, though. ;-)

How would this differ from the workflow scenario text in section 2?

Are you suggesting representing this text in a visual form? If so, would anyone like to make a contribution of some ascii art?

> There are cases a security-process can be fully automated, of course, and in
> order to manage the sheer amount of security related system events
> automation is essential, but it seems to me that the complexity and
> heterogeneity of root-causes (that might trigger the work-flow) make the
> inclusion of a user/operator necessary.
> 
> 2.) To include acquisition methods can provide an intuitive insight about the
> scope and intend of the endpoint posture assessment domain, I think. On
> one hand, that might bloat the use-case document a bit (and maybe renders
> the title "sacm use cases" too specific?). On the other hand, I like the
> inclusion of a work-flow scenario and I think it is a good place to highlight
> acquisition methods.
> 
> - Henk
> 
> > I just posted an updated use case draft based on the editorial sessions
> during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to all that
> provided input.
> >
> > - I worked through the use cases we planned to remove and made sure to
> merge in any concepts that would be lost. If you submitted a previous use
> case that was removed, please double check that I didn't miss anything.
> > - I broke up "Endpoint Identification and Assessment" into 3 distinct and
> somewhat separable use cases: "Endpoint Identification and Assessment
> Planning", "Endpoint Posture Attribute Value Collection", "Posture
> Evaluation". Please let me know what you think about this change.
> > - Addressed some aspects of the discussion thread based on the working
> session changes. Please provide any suggested edits for aspects that I might
> have missed or got wrong.
> >
> > If possible, I'd like to get to a fairly stable place with this draft in the next
> revision or two to allow for progress to be made on the requirements. In
> addition to the embedded questions in the document, I'd like to focus on the
> following questions:
> >
> > Is the draft approachable for a newcomer to the effort? Do you see the
> updated use case structure as an improvement?
> > I hope to release at least one or two more updates to this draft within the
> next few weeks before the holidays catch up on us.  I know everyone is
> busy; timely comments are appreciated to allow for a quick turnaround on
> the next revision.
> >
> > Thanks,
> > Dave
> >
> > A new version of I-D, draft-ietf-sacm-use-cases-05.txt has been
> successfully submitted by David Waltermire and posted to the IETF
> repository.
> >
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 5 Dec 2013 02:32:49 +0000

Dave Waltermire wrote:
> Adam Montville wrote:
> > Something I've found helpful in the past is to abstract a bit further
> > from "user", "operator", "application" and simply reference all of
> > them at once with the term "actor".
> 
> Are we ok with the change to using actor? The current usage of "user",
> "operator", "application" (specifically the last two) was suggested a
> while back to align with IETF terminology. Does use of "actor" to
> reference all three concepts raise any concerns?

I'm not OK with this change. Not all users and applications are the same.
To be specific, the word "administrator" is only used in section 2.2.4,
which describes a security administrator querying posture databases to
look for installed software that's correlated with a particular data
exfiltration pattern. Changing "administrator" to "actor" in this section
would take the heart out of the scenario.

I realize that we say "operator or application" in several places. This
may seem like duplicative text. However, I believe that it's useful to
point out explicitly that these actions can be performed by either humans
or processes.

Thanks,

Steve

---

From: "Adam W. Montville" <[email-masked]>
Date: Wed, 4 Dec 2013 23:00:27 -0600

> point out explicitly that these actions can be performed by either humans

A fair point.  I'm fine either way, but do give preference to the term actor at higher levels of abstraction to get the overall point across without muddying the details too much with the (ultimately important) differences at the level of technical detail.

---

From: "David Harrington" <[email-masked]>
Date: Thu, 5 Dec 2013 00:11:00 -0500

Hi,

Using actor concerns me.
I find it important to understand whether some content needs to be parsed by
a human (with our wonderful ability to parse), or a computer application
(which is bound by a set of rules, and has great difficulty when the content
is not consistent with the rules).

Around 2003, the operators made it clear that CLIs were difficult to work
with, because queries would return information in variable formats.
While humans might be able to parse the output that might change from vendor
to vendor, model to model, and release to release, tools had significant
difficulty due to the lack of standardization. Operators could try to deal
with the lack of standardization by writing expect scripts, but they would
need to be updated constantly because what worked for one release of a
product might not be the same in the next release. 
Humans can parse variable syntax, such as the natural language content of
syslog, but applications can have a hard time.

I think is very important to know whether we are designing something for
human consumption or for computer consumption.
"Actor" doesn't provide enough differentiation to know how to design our
solutions.

David Harrington
[email-masked]
+1-603-828-1401

> From: sacm [mailto:[email-masked]] On Behalf Of Waltermire, David
> A.
> Sent: Wednesday, December 04, 2013 8:54 PM
> To: Adam Montville; Henk Birkholz; [email-masked]
> > Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-
> > cases-05.txt
from
> "operator", "application" (specifically the last two) was suggested a
while
> back to align with IETF terminology. Does use of "actor" to reference all
three
> concepts raise any concerns?
> 
> > Finally, I, too, like the notion of a work-flow scenario.  I don't want
to be
> the
> Are you suggesting representing this text in a visual form? If so, would
> anyone like to make a contribution of some ascii art?
> 
> > awm
> > Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-
> > cases-05.txt
and in
> > 2.) To include acquisition methods can provide an intuitive insight
about the
> > > I used the word version that we edited as a starting point. Here is
what I
> > did:
> > > Title:                 Endpoint Security Posture Assessment -
Enterprise Use
> Cases
> > > URL:
http://www.ietf.org/internet-drafts/draft-ietf-sacm-use-
> cases-
> > 05.txt
> > > Status:
http://datatracker.ietf.org/doc/draft-ietf-sacm-use-cases
> > > Htmlized:
http://tools.ietf.org/html/draft-ietf-sacm-use-cases-05
> > > Diff:
http://www.ietf.org/rfcdiff?url2=draft-ietf-sacm-use-cases-05

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 5 Dec 2013 09:52:29 +0000

I share DBH's concern. There may be significant differences in workflows and interface requirements between systems (networks, devices) and humans vs. systems (networks, devices) and applications. There may be significant differences if the humans are operators or end-users. Using one term (say 'actor') for all may create ambiguities. I am not sure that I understand the advantages of the proposed abstraction.

Dan 
(speaking as contributor)

> From: sacm [mailto:[email-masked]] On Behalf Of David Harrington
> Sent: Thursday, December 05, 2013 7:11 AM
> To: 'Waltermire, David A.'; 'Adam Montville'; 'Henk Birkholz';
> [email-masked]
> I find it important to understand whether some content needs to be
> parsed by a human (with our wonderful ability to parse), or a computer
> application (which is bound by a set of rules, and has great difficulty
> when the content is not consistent with the rules).
> 
> Around 2003, the operators made it clear that CLIs were difficult to
> work with, because queries would return information in variable formats.
> While humans might be able to parse the output that might change from
> vendor to vendor, model to model, and release to release, tools had
> significant difficulty due to the lack of standardization. Operators
> could try to deal with the lack of standardization by writing expect
> scripts, but they would need to be updated constantly because what
> worked for one release of a product might not be the same in the next
> release.
> Humans can parse variable syntax, such as the natural language content
> of syslog, but applications can have a hard time.
> 
> > From: sacm [mailto:[email-masked]] On Behalf Of Waltermire,
> > David A.
> > draft-ietf-sacm-use- cases-05.txt
> >
> > Comments inline.
> >
> > > "user", "operator", "application" and simply reference all of them
> > > at
> once
> > > with the term "actor".
> >
> > > I also believe that listing *potential* acquisition methods is
> > > useful in
> at least
> > > the following way: Including a multitude of acquisition methods
> > > clearly
> > signals
> > > necessarily precluding our ability to *get* information when
> > > information does not exist.
> >
> > Are you suggesting representing this text in a visual form? If so,
> > would anyone like to make a contribution of some ascii art?
> >
> > > awm
> > > heterogeneity of root-causes (that might trigger the work-flow) make
> > > scope and intend of the endpoint posture assessment domain, I think.
> > > On one hand, that might bloat the use-case document a bit (and maybe
> > renders
> > > the title "sacm use cases" too specific?). On the other hand, I like
> > > the inclusion of a work-flow scenario and I think it is a good place
> > > to
> highlight
> > > acquisition methods.
> > >
> > > - Henk
> > >
> > > during the IETF 88 meeting in Vancouver, BC, Canada. My thanks to
> > > all
> that
> > > provided input.
> > > >
> > > > - I worked through the use cases we planned to remove and made
> > > > sure
> > to
> > > merge in any concepts that would be lost. If you submitted a
> > > previous
> use
> > > > - I broke up "Endpoint Identification and Assessment" into 3
> > > > distinct
> and
> > > somewhat separable use cases: "Endpoint Identification and
> > > Assessment Planning", "Endpoint Posture Attribute Value Collection",
> > > "Posture Evaluation". Please let me know what you think about this
> change.
> > > session changes. Please provide any suggested edits for aspects that
> > > I
> > might
> > > > If possible, I'd like to get to a fairly stable place with this
> > > > draft
> in the next
> > > revision or two to allow for progress to be made on the
> > > requirements. In addition to the embedded questions in the document,
> > > I'd like to focus on
> > the
> > > following questions:
> > > >
> > > > Does this draft paint a complete enough picture? Are we missing
> > > > any
> > > important concepts?
> > > next few weeks before the holidays catch up on us.  I know everyone
> > > is busy; timely comments are appreciated to allow for a quick
> > > turnaround on the next revision.
> > > >
> > > > Thanks,
> > > > Dave
> > > >

---

From: Michael Hammer <[email-masked]>
Date: Thu, 5 Dec 2013 14:12:33 +0000

Actor connotes human to me.

What would be wrong with using client or server if asymmetric, or user agent
if peering?
With adjectives to differentiate types.

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; [email-masked]
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

I share DBH's concern. There may be significant differences in workflows and
interface requirements between systems (networks, devices) and humans vs.
systems (networks, devices) and applications. There may be significant
differences if the humans are operators or end-users. Using one term (say
'actor') for all may create ambiguities. I am not sure that I understand the
advantages of the proposed abstraction.

Dan

---

From: Ira McDonald <[email-masked]>
Date: Thu, 5 Dec 2013 09:49:33 -0500

Hi,

My two cents - End User, Operator, and Administrator are quite distinct
roles of actors in standards from many SDOs - they have inherently
distinct default privileges - using these common role terms consistently
would make SACM use cases more accessible to non-participants in
the SACM WG.

BTW - there are a few other roles of actors that should probably be
used in SACM use cases, e.g., Application - although tthat's a slippery
slope, because normal applications (browsers, email readers, etc.)
have very different privileges and responsibilities from security-specific
applications (MDM agents, anti-virus scanners, etc.).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer <[email-masked]
> wrote:

---

From: Adam Montville <[email-masked]>
Date: Fri, 6 Dec 2013 01:08:53 +0000

I am in agreement with all of the comments made to the suggestion of using "actor" thus far.  The only advantage to using that term is the abstraction it provides, which usually lends itself to communicating the generalities of the system for comprehension before getting into the important semantic differences between various actor subtypes.

If we see no reason for the abstraction, we don't need to use it.  And, it seems that many don't like the idea :-)

Adam

________________________________________
From: Romascanu, Dan (Dan) [[email-masked]]
Sent: Thursday, December 05, 2013 3:50 AM
To: David Harrington; 'Waltermire, David A.'; Adam Montville; 'Henk Birkholz'; [email-masked]
Subject: RE: [sacm] FW: New     Version Notification    for     draft-ietf-sacm-use-cases-05.txt

Dan

...

. . .

---

From: Adam Montville <[email-masked]>
Date: Fri, 6 Dec 2013 01:11:33 +0000

I like this set of terminology.  End User, Operator, Administrator, and Application.  Then, Application can potentially have further specification as we move forward.  For example, Analysis Application, Acquisition Application, and so on.

Whatever we choose, I would prefer to choose terms that we can easily use consistently.

Adam

(I'm assuming, but perhaps shouldn't, that when I comment like this it's as a contributor)

________________________________
From: Ira McDonald [[email-masked]]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked]; Adam Montville; [email-masked]; [email-masked]
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt

Hi,

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer <[email-masked]<mailto:[email-masked]>> wrote:
Actor connotes human to me.

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; [email-masked]<mailto:[email-masked]>
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

Dan

> From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of David Harrington
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> +1-603-828-1401<tel:%2B1-603-828-1401>
>
> > From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Waltermire,
> > David A.
> > To: Adam Montville; Henk Birkholz; [email-masked]<mailto:[email-masked]>
> > > From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Adam
> > > Montville
> > > To: Henk Birkholz; [email-masked]<mailto:[email-masked]>
> > > From: sacm [[email-masked]<mailto:[email-masked]>] on behalf of Henk Birkholz
> > > [[email-masked]<mailto:[email-masked]>]
> > > To: [email-masked]<mailto:[email-masked]>
> > > > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
> > > submission until the htmlized version and diff are available at
> tools.ietf.org<http://tools.ietf.org>.
> > > >
> > > > The IETF Secretariat
> > > >
> > > > [email-masked]<mailto:[email-masked]>
> > > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sacm

...

. . .

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 6 Dec 2013 06:09:49 +0000

I will also echo these concerns; to Dan's points the workflow, interface
as well as timing requirements will be influenced by the differentiation
of human vs. systems vs. applications (as well as the distinctive roles
they play).

Thanks Nancy.

On 12/5/13 1:52 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

>I share DBH's concern. There may be significant differences in workflows
>and interface requirements between systems (networks, devices) and humans
>vs. systems (networks, devices) and applications. There may be
>significant differences if the humans are operators or end-users. Using
>one term (say 'actor') for all may create ambiguities. I am not sure that
>I understand the advantages of the proposed abstraction.
>
>Dan 
>> tools.ietf.org.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 8 Dec 2013 13:43:38 +0000

+1

Dan

Speaking as contributor - better to say it clearly if there are reasons to wonder

From: Adam Montville [mailto:[email-masked]]
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt

Adam

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Adam Montville; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk

Dan

...
This message and attachments may contain confidential information. If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited. Please notify the sender immediately and permanently delete the message and any attachments.
. . .

---

From: <[email-masked]>
Date: Sun, 8 Dec 2013 17:19:38 +0000

+1

I like the terminology Ira and Adam have suggested.

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096
Mobile: +1.817.637.8026
Web: www.mcafee.com<http://www.mcafee.com/>

From: <Romascanu>, "Dan (Dan)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, December 8, 2013 7:43 AM
To: Adam Montville <[email-masked]<mailto:[email-masked]>>, Ira McDonald <[email-masked]<mailto:[email-masked]>>, Michael Hammer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, David Waltermire <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt

+1

Dan

Speaking as contributor – better to say it clearly if there are reasons to wonder

Cc: Romascanu, Dan (Dan); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Adam

From: Ira McDonald [[email-masked]<mailto:[email-masked]>]

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk

Dan

...

---

From: "Waltermire, David A." <[email-masked]>
Date: Mon, 9 Dec 2013 20:12:58 +0000

+1. I too like this approach. This has been a good discussion.

To direct this dialog towards actionable changes to the use cases draft, is there specific draft text that should be updated to make the roles and their relevance to a use case or usage scenario more clear?

Thanks,
Dave

From: sacm [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, December 08, 2013 12:20 PM
To: [email-masked]
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt

+1

Kent Landfield

+1

Dan

Adam

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk

Dan

...

---

From: Ira McDonald <[email-masked]>
Date: Mon, 9 Dec 2013 15:34:37 -0500

Hi Dave,

I'm not sure if there's consensus about this, but I suggest that the current
lowercase "operator", "administrator", etc. (e.g., in 2.1.1) should be
titlecase (first letter capitalized).

Also that a new section 1.1 Actors be added that defines these actor
terms (one to three sentences each about what are typical actions or
responsibilities for each actor).

>From the original Design Goals for IPP (RFC 2567) here are some
admittedly printing-specific definitions, but they give the right flavor:

"3.1. END-USER

   An end-user of a printer accepting jobs through the Internet is one
   of the roles in which humans act.  The end-user is the person that
   will submit a job to be printed on the printer.

   The wants and needs of the end-user are broken down into six
   categories: finding/locating a printer, creating a local instance of
   a printer, viewing printer status, viewing printer capabilities,
   submitting a print job, viewing print job status, altering the
   attributes of a print job.

3.2. OPERATOR

   An operator of a printer accepting jobs through the Internet is one
   of the roles in which humans act.  The operator has the
   responsibility of monitoring the status of the printer as well as
   managing and controlling the jobs at the device.  These
   responsibilities include but are not limited to the replenishing of
   supplies (ink, toner, paper, etc.), the clearing of minor errors
   (paper jams, etc.) and the re-prioritization of end-user jobs.
   Operator wants and needs will not be addressed by V1.0 of the
   protocol.

   The wants and needs of the operator include all those of the end-user
   but may include additional privileges.  For example, an operator may
   be able to view all print jobs on a printer while the end-user might
   only be able to see his own jobs.

3.3. ADMINISTRATOR

   An administrator of a printer accepting jobs through the Internet is
   one of the roles in which humans act.  The administrator has the
   responsibility of creating the printer instances and controlling the
   authorization of other end-users and operators.  Administrator wants
   and needs will not be addressed by V1.0 of the protocol.

   The wants and needs of the administrator include all those of the
   end-user and, in some environments, some or all of those of the
   operator.  Minimally, the administrator must also have the tools,
   programs, utilities and supporting protocols available to be able to:

   - create an instance of a printer
   - create, edit and maintain the list of authorized end-users
   - create, edit and maintain the list of authorized operators
   - create, edit and maintain the list of authorized
     administrators
   - create, customize, change or otherwise alter the manner in
     which the status capabilities and other information about printers
     and jobs are presented
   - create, customize, or change other printer or job features
   - administrate billing or other charge-back mechanisms
   - create sets of defaults
   - create sets of capabilities

   The administrator must have the capability to perform all the above
   tasks locally or remotely to the printer."

>From later IPP Get-Notifications (RFC 3997), here are much shorter
definitions:

"2.1.  Job-Submitting End User

   A human end user who submits a print job to an IPP Printer.  This
   person may or may not be within the same security domain as the
   Printer.  This person may or may not be geographically near the
   printer.

2.2.  Administrator

   A human user who established policy for and configures the print
   system.

2.3.  Operator

   A human user who carries out the policy established by the
   Administrator and controls the day-to-day running of the print
   system."

As Nancy said, we need also:  Application, System.

Cheers,
- Ira

On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. <
[email-masked]> wrote:

> To direct this dialog towards actionable changes to the use cases draft,
> is there specific draft text that should be updated to make the roles and
> their relevance to a use case or usage scenario more clear?
>
>
>
> Thanks,
>
> Dave
>
>
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* Sunday, December 08, 2013 12:20 PM
>
> *To:* [email-masked]
> *Subject:* Re: [sacm] FW: New Version Notification for
> *Kent Landfield*
> *McAfee | An Intel Company*
> Direct: +1.972.963.7096
> Mobile: +1.817.637.8026
> *Web: *www.mcafee.com
>
>
>
> *From: *<Romascanu>, "Dan (Dan)" <[email-masked]>
> *Date: *Sunday, December 8, 2013 7:43 AM
> *To: *Adam Montville <[email-masked]>, Ira McDonald <
> [email-masked]>, Michael Hammer <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, David
> Waltermire <[email-masked]>, "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *Re: [sacm] FW: New Version Notification for
> *From:* Adam Montville [mailto:[email-masked]<[email-masked]>]
>
> *Sent:* Friday, December 06, 2013 3:12 AM
> *To:* Ira McDonald; Michael Hammer
> *Cc:* Romascanu, Dan (Dan); [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> *Subject:* RE: [sacm] FW: New Version Notification for
> I like this set of terminology.  End User, Operator, Administrator, and
> Application.  Then, Application can potentially have further specification
> as we move forward.  For example, Analysis Application, Acquisition
> Application, and so on.
>
>
>
>  ------------------------------
>
> *From:* Ira McDonald [[email-masked]]
> *Sent:* Thursday, December 05, 2013 8:48 AM
> *To:* Michael Hammer
> *Cc:* [email-masked]; [email-masked];
> [email-masked]; Adam Montville; [email-masked];
> [email-masked]
> *Subject:* Re: [sacm] FW: New Version Notification for
> On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer <
> [email-masked]> wrote:
>
> This message and attachments may contain confidential information. If it
> appears that this message was sent to you by mistake, any retention,
> dissemination, distribution or copying of this message and attachments is
> strictly prohibited. Please notify the sender immediately and permanently
> delete the message and any attachments.
> . . .
>
>

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 9 Dec 2013 20:10:26 -0500

Hi,

I'd have to go look up a reference, but I believe the rfc editor considers
it bad form to capitalize things that don't need to be capitalized.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: sacm [mailto:[email-masked]] On Behalf Of Ira McDonald
Sent: Monday, December 09, 2013 3:35 PM
To: Waltermire, David A.; Ira McDonald
Cc: [email-masked]
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

Hi Dave,

"3.1. END-USER

3.2. OPERATOR

3.3. ADMINISTRATOR

definitions:

2.2.  Administrator

2.3.  Operator

Cheers,

- Ira

 <http://sites.google.com/site/blueroofmusic>
 <http://sites.google.com/site/highnorthinc>

On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A.
<[email-masked]> wrote:

To direct this dialog towards actionable changes to the use cases draft, is
there specific draft text that should be updated to make the roles and their
relevance to a use case or usage scenario more clear?

Thanks,

Dave

From: sacm [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Sunday, December 08, 2013 12:20 PM

To: [email-masked]

+1

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096 <tel:%2B1.972.963.7096>  
Mobile: +1.817.637.8026 <tel:%2B1.817.637.8026> 
Web: www.mcafee.com <http://www.mcafee.com/> 

From: <Romascanu>, "Dan (Dan)" <[email-masked]>
Date: Sunday, December 8, 2013 7:43 AM
To: Adam Montville <[email-masked]>, Ira McDonald
<[email-masked]>, Michael Hammer <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, David Waltermire
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

+1

Dan

Speaking as contributor - better to say it clearly if there are reasons to
wonder

From: Adam Montville [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 3:12 AM
To: Ira McDonald; Michael Hammer
Cc: Romascanu, Dan (Dan); [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

Whatever we choose, I would prefer to choose terms that we can easily use
consistently.  

Adam

(I'm assuming, but perhaps shouldn't, that when I comment like this it's as
a contributor)

  _____  

From: Ira McDonald [[email-masked]]
Sent: Thursday, December 05, 2013 8:48 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked]; [email-masked];
Adam Montville; [email-masked]; [email-masked]
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

Hi,

Cheers,

- Ira

 <http://sites.google.com/site/blueroofmusic>
 <http://sites.google.com/site/highnorthinc>

On Thu, Dec 5, 2013 at 9:12 AM, Michael Hammer
<[email-masked]> wrote:

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; [email-masked]

Dan

> +1-603-828-1401 <tel:%2B1-603-828-1401> 
>

...

---

From: Adam Montville <[email-masked]>
Date: Tue, 10 Dec 2013 12:25:05 +0000

Thanks for pointing that out, David.  This might be stylistic in some ways, but these aren't titles they are roles.  From that perspective we could treat them as proper nouns, which would technically warrant capitalization.  But, better to stick with what the Editor would prefer, I think.

Adam

________________________________
From: sacm [[email-masked]] on behalf of ietfdbh [[email-masked]]
Sent: Monday, December 09, 2013 7:08 PM
To: 'Ira McDonald'; 'Waltermire, David A.'
Cc: [email-masked]
Subject: Re: [sacm] FW: New Version Notification for draft-ietf-sacm-use-cases-05.txt

Hi,

I’d have to go look up a reference, but I believe the rfc editor considers it bad form to capitalize things that don’t need to be capitalized.

David Harrington
[email-masked]<mailto:[email-masked]>
+1-603-828-1401

Hi Dave,

"3.1. END-USER

3.2. OPERATOR

3.3. ADMINISTRATOR

definitions:

2.2.  Administrator

2.3.  Operator

On Mon, Dec 9, 2013 at 3:12 PM, Waltermire, David A. <[email-masked]<mailto:[email-masked]>> wrote:
+1. I too like this approach. This has been a good discussion.

Thanks,
Dave

From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, December 08, 2013 12:20 PM

+1

Kent Landfield

McAfee | An Intel Company
Direct: +1.972.963.7096<tel:%2B1.972.963.7096>
Mobile: +1.817.637.8026<tel:%2B1.817.637.8026>
Web: www.mcafee.com<http://www.mcafee.com/>

+1

Dan

Adam

Winter  579 Park Place  Saline, MI  48176  734-944-0094<tel:734-944-0094>
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<tel:906-494-2434>

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk

Dan

...

...

. . .

---

From: Michael Hammer <[email-masked]>
Date: Tue, 10 Dec 2013 14:50:21 +0000

If they are formal terms defined in a document, I don't think capitalization
is a problem.

How else do you distinguish them from randomly chosen English words?

After all the whole reason to distinguish MUST versus must is just that.

But, might be good to clarify that with Editor.

Mike

From: sacm [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Tuesday, December 10, 2013 7:25 AM
To: ietfdbh; 'Ira McDonald'; 'Waltermire, David A.'
Cc: [email-masked]
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

Thanks for pointing that out, David.  This might be stylistic in some ways,
but these aren't titles they are roles.  From that perspective we could
treat them as proper nouns, which would technically warrant capitalization.
But, better to stick with what the Editor would prefer, I think. 

Adam

  _____  

From: sacm [[email-masked]] on behalf of ietfdbh
[[email-masked]]

Hi,

 

David Harrington

+1-603-828-1401

Hi Dave,

"3.1. END-USER

3.2. OPERATOR

3.3. ADMINISTRATOR

definitions:

2.2.  Administrator

2.3.  Operator

Cheers,

- Ira

Thanks,

Dave

To: [email-masked]

+1

Kent Landfield

+1

Dan

 

Adam

  _____  

Hi,

Cheers,

- Ira

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; [email-masked]

Dan

...

...

. . .

---

From: Ira McDonald <[email-masked]>
Date: Tue, 10 Dec 2013 10:00:47 -0500

Hi,

Actor roles are titlecase in IETF AAA Framework (RFC 2904).

Cheers,
- Ira

On Tue, Dec 10, 2013 at 9:50 AM, Michael Hammer <
[email-masked]> wrote:

> If they are formal terms defined in a document, I don’t think
> capitalization is a problem.
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Adam Montville
> *Sent:* Tuesday, December 10, 2013 7:25 AM
> *To:* ietfdbh; 'Ira McDonald'; 'Waltermire, David A.'
>
> *Cc:* [email-masked]
> Thanks for pointing that out, David.  This might be stylistic in some
> ways, but these aren't titles they are roles.  From that perspective we
> could treat them as proper nouns, which would technically warrant
> capitalization.  But, better to stick with what the Editor would prefer, I
> think.
>
>
>
> Adam
>
>
> *From:* sacm [[email-masked]] on behalf of ietfdbh [
> [email-masked]]
> *Sent:* Monday, December 09, 2013 7:08 PM
> *To:* 'Ira McDonald'; 'Waltermire, David A.'
> *Cc:* [email-masked]
> I’d have to go look up a reference, but I believe the rfc editor considers
> it bad form to capitalize things that don’t need to be capitalized.
>
>
>
>
>
> David Harrington
>
> [email-masked]
>
> +1-603-828-1401
>
> *From:* sacm [mailto:[email-masked]] *On Behalf Of *Ira McDonald
> *Sent:* Monday, December 09, 2013 3:35 PM
> *To:* Waltermire, David A.; Ira McDonald
> *Cc:* [email-masked]

---

From: "ietfdbh" <[email-masked]>
Date: Tue, 10 Dec 2013 15:02:57 -0500

Hi,

I looked at rfc2904 (AAA Framework)

I notice that both User and user are used ;-)

I see that "AAA Server" is often capitalized, whereas other uses of the term
server are not capitalized: print server, authorization servers, RADIUS
server, etc.

But, even "AAA server" is often not capitalized (sections 4.3, 6.1, 7, 8, 9)

So, RFC2904 may not be good example of preferred usage.

The RFC Editor guidelines call for consistency in capitalization across
related documents.

Our charter calls for the reuse of existing standards where possible.

So I asked myself, do potential related documents (e.g., SNMP, NETCONF, NEA,
etc.) use these terms (end-point, operator, administrator, and application),
and do they capitalize them?

RFC 3411 (SNMP Architecture) doesn't use them much, but when used they are
in lower case.

Application is used, but it is only capitalized when referring to a specific
type of application, such as a "Command Responder Application".

(and title and TOC and first word in a sentence of course), otherwise it is
lowercase. 

RFC4741 (NETCONF) uses application in lowercase; they use administrator in
lowercase. They don't use end-point or operator.

RFC5209 (NEA Overview) uses application, administrator, operator in
lowercase, except one use of "Enterprise Administrator".

They don't use end-point.

David Harrington

+1-603-828-1401

From: Ira McDonald [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 10:01 AM
To: Michael Hammer
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [sacm] FW: New Version Notification for
draft-ietf-sacm-use-cases-05.txt

Hi,

Cheers,

- Ira

On Tue, Dec 10, 2013 at 9:50 AM, Michael Hammer
<[email-masked]> wrote:

Mike

Cc: [email-masked]

Adam

  _____  

Hi,

 

David Harrington

Hi Dave,

"3.1. END-USER

3.2. OPERATOR

3.3. ADMINISTRATOR

definitions:

2.2.  Administrator

2.3.  Operator

Cheers,

- Ira

Thanks,

Dave

To: [email-masked]

+1

Kent Landfield

+1

Dan

 

Adam

  _____  

Hi,

Cheers,

- Ira

Mike

-----Original Message-----
From: sacm [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
Sent: Thursday, December 05, 2013 4:52 AM
To: David Harrington; 'Waltermire, David A.'; 'Adam Montville'; 'Henk
Birkholz'; [email-masked]

Dan

...

...

. . .