Subject: [sacm] BOF process and some observations

From: Sean Turner <[email-masked]>
Date: Tue, 02 Oct 2012 08:42:09 -0400

I've gotten a lot of question about how the BOF process works.  I'll try 
to give you my summary of what's going on and some observations.  Much 
of this is summarized in:
- s5 of https://www.ietf.org/tao.html.
- https://datatracker.ietf.org/doc/rfc2418/
- https://datatracker.ietf.org/doc/rfc5434/

A BOF has been approved because I'm convinced, as the sponsoring Area 
Director (AD), that some of the questions in s1 of RFC 5434 have been 
answered.  Particularly, there's a community interested (evident from 
sacm's ml) and that there's some part of the problem that could be done 
in the IETF.  The mailing list has been around for about 2 years so, in 
my mind, it's time to see if sacm is ready for prime time (i.e., time to 
put up or shut up).

In general, you get two shots at forming a WG. I'm counting this as BOF 
try 1.  It'll be clear during the BOF whether it's going well or not. 
Trust me on this.  And, just because a WG isn't formed doesn't mean the 
work won't get picked by/adopted by/directed to another WG.

As far as the BOF goes, I think you should expect that most people that 
attend the BOF will have read the "charter" messages, the sacm-related 
drafts, and whatever presentations get posted to the meeting materials 
manager but that's about it.  That is, I'd expect most people won't have 
read all the list's messages, won't have attended the side-meetings, and 
probably aren't on non-IETF sacm-related mailing lists.  The set of 
slides that comprises the agenda need to lead everybody, including IAB 
and IESG members some number of which I expect to attend the BOF, 
towards being able to say yes to all 5 of the BOF questions.  That is, 
the presenters need to define what sacm is, have some use cases, explain 
what's left to be done (i.e, how the existing work fits/doesn't fit), 
describe the proposed-WG's items, etc.

And now for some concerns that I'd be remiss in not asking before the BOF:

As noted in the TAO, most BOFs that fail to result in a WG fail 
predominantly because not enough people can agree on a focus for the 
work, which could also categorized as the problem not being understood. 
  I have to admit that I'm concerned about sacm's scope.  The sacm 
problem space is pretty wide and it's not clear that all of it ought to 
be done in the IETF.  It's okay, but probably not necessary, to explain 
the entire sacm problem space, but it needs to be clear what's proposed 
for the IETF and what's not.  It'll make it easier to answer the 1st and 
3rd BOF questions.

I'm also concerned that there's already a fairly substantial amount of 
already published work in this space.  How do they all relate, which 
parts are required for sacm, which parts are optional for sacm, and 
which parts are missing for sacm?  What (if any) change control issues 
arise if we adopt/refer to non-IETF specifications?

I say this knowing there are, but there'd better be non-USG use cases. 
It'd be good to hear from those that would use sacm to say yep we're 
looking for that.

Another thing I've been wondering is whether sacm targets, which can be 
just about any IP-based box, OS, application running on the box/OS 
(right?), are ready to adopt yet another interface.  Are the router, 
firewall, OS, and phone folks on board?  I'd rather not build something 
hoping that they will come, if you know what I mean.

What can/can't be done with existing protocols/models/languages 
developed in the IETF?  Having multiple ways to manage/monitor/collect 
something is non-ideal so I'm dying to know why for example netconf 
can't be used or can't be extended and then used.

spt

---

From: Michael Hammer <[email-masked]>
Date: Tue, 2 Oct 2012 13:29:24 +0000

To help gain focus, folks should understand that the IETF defines success as
completion of the WG, not a life-long old boys club.
It is not a one-shot deal.  You can create a series of WGs to tackle
subsequent elements of work over time.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sean
Turner
Sent: Tuesday, October 02, 2012 8:42 AM
To: [email-masked]
Subject: [sacm] BOF process and some observations

I've gotten a lot of question about how the BOF process works.  I'll try to
give you my summary of what's going on and some observations.  Much of this
is summarized in:
- s5 of https://www.ietf.org/tao.html.
- https://datatracker.ietf.org/doc/rfc2418/
- https://datatracker.ietf.org/doc/rfc5434/

A BOF has been approved because I'm convinced, as the sponsoring Area
Director (AD), that some of the questions in s1 of RFC 5434 have been
answered.  Particularly, there's a community interested (evident from sacm's
ml) and that there's some part of the problem that could be done in the
IETF.  The mailing list has been around for about 2 years so, in my mind,
it's time to see if sacm is ready for prime time (i.e., time to put up or
shut up).

In general, you get two shots at forming a WG. I'm counting this as BOF try
1.  It'll be clear during the BOF whether it's going well or not. 
Trust me on this.  And, just because a WG isn't formed doesn't mean the work
won't get picked by/adopted by/directed to another WG.

As far as the BOF goes, I think you should expect that most people that
attend the BOF will have read the "charter" messages, the sacm-related
drafts, and whatever presentations get posted to the meeting materials
manager but that's about it.  That is, I'd expect most people won't have
read all the list's messages, won't have attended the side-meetings, and
probably aren't on non-IETF sacm-related mailing lists.  The set of slides
that comprises the agenda need to lead everybody, including IAB and IESG
members some number of which I expect to attend the BOF, towards being able
to say yes to all 5 of the BOF questions.  That is, the presenters need to
define what sacm is, have some use cases, explain what's left to be done
(i.e, how the existing work fits/doesn't fit), describe the proposed-WG's
items, etc.

As noted in the TAO, most BOFs that fail to result in a WG fail
predominantly because not enough people can agree on a focus for the work,
which could also categorized as the problem not being understood. 
  I have to admit that I'm concerned about sacm's scope.  The sacm problem
space is pretty wide and it's not clear that all of it ought to be done in
the IETF.  It's okay, but probably not necessary, to explain the entire sacm
problem space, but it needs to be clear what's proposed for the IETF and
what's not.  It'll make it easier to answer the 1st and 3rd BOF questions.

I'm also concerned that there's already a fairly substantial amount of
already published work in this space.  How do they all relate, which parts
are required for sacm, which parts are optional for sacm, and which parts
are missing for sacm?  What (if any) change control issues arise if we
adopt/refer to non-IETF specifications?

I say this knowing there are, but there'd better be non-USG use cases. 
It'd be good to hear from those that would use sacm to say yep we're looking
for that.

Another thing I've been wondering is whether sacm targets, which can be just
about any IP-based box, OS, application running on the box/OS (right?), are
ready to adopt yet another interface.  Are the router, firewall, OS, and
phone folks on board?  I'd rather not build something hoping that they will
come, if you know what I mean.

What can/can't be done with existing protocols/models/languages developed in
the IETF?  Having multiple ways to manage/monitor/collect something is
non-ideal so I'm dying to know why for example netconf can't be used or
can't be extended and then used.

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