Subject: [sacm] comments on draft-waltermire-sacm-use-cases-05

From: Chris Inacio <[email-masked]>
Date: Wed, 31 Jul 2013 22:09:26 +0000

At a minimum we need to caveat network scanning using PING to say that with an IPv6 network, that isn't a practical method.

Endpoint / Asset : we should either discuss or acknowledge virtual machines (read virtual assets?) and how they should be handled here.

The ability to assess non-software vulnerabilities (section 4.4) seems very challenging.

The rest of the draft had to many "todo"'s still to do more meaningful review.

--
Chris Inacio
[email-masked]

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 1 Aug 2013 01:37:29 +0000

Chris,

I hope you won't mind if I piggyback with a few comments
of my own on this document and on your very good comments.

> Endpoint / Asset : we should either discuss or acknowledge virtual
> machines (read virtual assets?) and how they should be handled here.

I agree. Virtual machines were intended to be included in
the RFC 5209 definition of endpoint. However, that's not
entirely clear from the text of that definition. It was
explained obliquely later in RFC 5209. I suggest that we
append the following sentence to the second paragraph in
the endpoint definition in draft-waltermire-use-cases:

Virtual devices (e.g. VM images) are also considered to
be endpoints.

> At a minimum we need to caveat network scanning using PING
> to say that with an IPv6 network, that isn't a practical method.

In my view, the use case document should not spend much
space talking about HOW the use cases can be met (e.g.
doing asset discovery through ping or by monitoring MIBs)
and instead focus on describing WHAT the use cases are,
by which I mean "what problems we're trying to solve".

We need to maintain our focus on defining the problem
and should not stray into solving the problem yet. If
you want to have side conversations on ways to solve
the problem, that's fine and good. But those ideas
should not end up in the use case document.

I realize this may result in a rather short use case
document. Don't worry. The charter calls for the use
cases to eventually be combined with the requirements
and architecture into a single document. This will
make the document plenty long enough. And short is good.

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Chris Inacio
> Sent: Wednesday, July 31, 2013 6:09 PM
> To: [email-masked]
> Subject: [sacm] comments on draft-waltermire-sacm-use-cases-05
> 
> 
> 
> At a minimum we need to caveat network scanning using PING to say that
> with an IPv6 network, that isn't a practical method.
> 
> Endpoint / Asset : we should either discuss or acknowledge virtual
> machines (read virtual assets?) and how they should be handled here.
> 
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>

---

From: Adam Montville <[email-masked]>
Date: Thu, 1 Aug 2013 05:10:45 +0000

> Stephen Hanna
> Sent: Wednesday, July 31, 2013 6:38 PM
> To: Chris Inacio; [email-masked]
> Subject: Re: [sacm] comments on draft-waltermire-sacm-use-cases-05
> 
> Chris,
> 
> I hope you won't mind if I piggyback with a few comments of my own on this
> document and on your very good comments.
> 
> I agree. Virtual machines were intended to be included in the RFC 5209
> definition of endpoint. However, that's not entirely clear from the text of
> that definition. It was explained obliquely later in RFC 5209. I suggest that we
> append the following sentence to the second paragraph in the endpoint
> definition in draft-waltermire-use-cases:
> 
> Virtual devices (e.g. VM images) are also considered to be endpoints.

Is this really needed?  To me, a VM can have an IP address, and that's covered.  I guess it doesn't matter either way, but if examples start becoming the spirit of the definition, then we're going to have a long list of things as technologies evolve.  Toasters?

> In my view, the use case document should not spend much space talking
> about HOW the use cases can be met (e.g.
> doing asset discovery through ping or by monitoring MIBs) and instead focus
> on describing WHAT the use cases are, by which I mean "what problems
> we're trying to solve".

+1, a lot.  

> 
> We need to maintain our focus on defining the problem and should not stray
> into solving the problem yet. If you want to have side conversations on ways
> to solve the problem, that's fine and good. But those ideas should not end up
> in the use case document.

+1.  A bit of context for those who are reading and saying, "but, we have working examples today!"  We do have working examples outside the context of IETF, but we do not have proper use cases yet documented.  I suspect, but we will prove it out in this WG, that the requirements and architecture derived from these use cases will largely match the technologies we have available to us today, but that we will need to step from where we are to a better solution over time.

> 
> I realize this may result in a rather short use case document. Don't worry. The
> charter calls for the use cases to eventually be combined with the
> requirements and architecture into a single document. This will make the
> document plenty long enough. And short is good.

I prefer "concise and representative is good."  Whether it's short or long doesn't matter as much to me, as long as we have a body of use cases that represents the problems we want to solve and are concise in their description.

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Chris Inacio
> ...

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.