Re: [Isms] ISMS charter broken- onus should be on WG to fix it

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eliot,

At the SBSM and ISMS BoF sessions at IETF 58 and 60 the need for
integrating SNMP into existing security frameworks was extensively
discussed.  Wes presented the issue at NANOG and performed a survey
among operators.  The output of all this work is the idenitfication
of a well founded general requirement for working on the integration
of SNMP into existing security frameworks in an IETF working group.

Now you claim that solving this issue is technically wrong without
considering a different problem that you call "call home".  Rather
you request adding the issue of solving the "call home" to the ISMS
charter.

However, nobody raised this issue at the ISMS BoFs nor has the
issue been discussed in depth in the OaM area.  But we should have
such a discussion before adding the issue to any IETF WG charter.
It looks like a good topic for a BoF session in the OaM area.
There we could find out the relevance of the problem and discuss
requirements for potential solutions.  Also there we can identify
which working group would be the right one to deal with the issue.

But until then, I propose that we let the ISMS group work on solving
its original problem.

Thanks,

   Juergen


--On 9/12/2005 9:53 PM +0200 Eliot Lear wrote:

Sam,

I believe the approach you have proposed is quite simply wrong.  As an
AD you're supposed to provide technical oversight and not simply hold a
popularity contest.  If you have technical questions or wish to
challenge me on a technical point, I think that's fair game.

As I've written, the path we are headed down technically will not work
in the face of firewalls and NATs, and nobody has refuted this.

Furthermore you've heard from a reasonably large customer (Boeing) as
well as your predecessor on the prevalence of such middle boxes that
demonstrates the complexity of today's environment and the need for this
sort of functionality as part of the solution.

You've heard from an author of SNMP that the major architectural change
is the use of session based security and NOT CH, the same from the
former O&M AD and IETF chair.  You've heard from a service provider as
well as numerous members of the community who see the problem.

You may or may not have yet heard from other standards bodies but if you
were to delay it is quite possible they will chime in since one was
specifically interested in this sort of function.

The amount of changes required to support CH cannot fully be ascertained
until more of the the [Todo]s are filled in with Dave's draft, but I
don't imagine the work would be much more than:

 - specifying how to initiate the connection and if necessary turn it
 - the identity used for requests received from command generators that
   did not initiate the connection along with potential prepopulating
   of various tables
 - an appendix of how the SNMP-TARGET-MIB would be populated
 - a discussion on when to initiate connections and what to do when
   they fail (mind you this is needed anyway regardless of CH)
 - security considerations involving firewalls, blocking, etc.
 - possibly one additional table describing the state of SSH peer
   connectivity (which probably wouldn't be bad to have anyway).

Decide for yourself if you think this is a substantial amount of text,
but I won't leave it to your imagination for long.  I will attempt this
week to post a derivative of the draft that Dave is working on to give
people an idea of what the changes would be.

Again it's difficult to diff an incomplete specification.

Eliot

"Eliot" == Eliot Lear <lear@xxxxxxxxx> writes:


    Eliot> I request an extension of the deadline for comments to
    Eliot> September 21st on the following basis:

    Eliot>  - the period of comment has been less than a week, far
    Eliot> shorter than the normal period of IETF-wide review.  - of
    Eliot> the time allotted, the principle instigator of this review
    Eliot> has been absent from debate for five days due to prior
    Eliot> commitments.  That was me.

Hi, Eliot.  I have not made any determination as yet about whether I
will pull ISMS from the Thursday telechat and am unlikely to make a
final determination until the time of that telechat.


When I originally ruled call home out of scope I gave you some
suggestions for how to approach things from a process standpoint.  In
evaluating your request I will consider how much progress has been
made on these issues so far and on whether it is likely that you could
make additional progress on these issues by September 21.

Let us go back and consider my original advice to you:

  When the charter is sent to me for IESG review, ask me to send it out
  for external review (IETF wide) rather than just approving it; I will
  honor such a request.  You will need a proposal ready to present to
  the community when the charter comes out for review.  The proposal
  should include proposed modifications to the charter to make call home
  in scope.  In addition you probably want to answer the following
  concerns:

  * People believe that architectural changes to SNMP should happen in
    the management not security area.  Either convince them that this is
    OK in the security area, propose moving the working group, or
    propose splitting the work appropriately.

  * Address the concerns about the lack of MIBs and other facilities for
    managing call home.  Have a proposal ready for what is involved in
    doing the work.


  * Understand concerns Bert is likely to raise and respond to them.



so, here are some specific questions related to our progress to date
on these items.  Answering these questions will help me determine
whether extending the review period to September 21 is likely to be
productive.

1) Have you proposed a specific set of charter changes?  Who has
   supported these charter changes?

2) How have you addressed the specific concerns about the location of
   the work ?  Who has agreed with your proposed resolution?

3) Is there a consensus emerging that CH needs to be solved as part of
    ISMS?  This is the part where additional time is most likely to
    help you, but I think it fair to ask who has supported blocking
    ISMS on CH so far.  Note that people who support CH but who
    believe it could be done in a separate working group or who have
    not expressed an opinion do not count.  They may well count for
    justifying support for a CH BOF or for justification of a
    publication request for an individual submission adding CH to the
    SNMP architecture.


4) What response have you given to concerns about whether the
   architectural extensions for CH are sufficiently well defined?  Who
   has supported this proposal?



5) How are your discussions going with Bert to resolve his concerns?
    What about other key members of the management community who have
    expressed concerns?



Here's how I'm going to make a decision.  I believe that in order to
get a change to the SNMP charter it is necessary to make significant
progress on all of these issues.  I'm going to evaluate your answers
and consider whether I think the progress to date makes it likely that
you will have sufficient support for a new charter by September 21
without significant opposition.  In other words whether the community
and IESG can agree to the new charter by the end of the review period.
If the progress to date makes it likely that we're headed in that
direction, I'll grant the request.  Otherwise I will ask the IESG to
approve the charter on Thursday.


There's an internal issue that may well prevent the charter from being
announced before the 21st even if no formal extension is granted.


--Sam




_______________________________________________
Isms mailing list
Isms@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/isms



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]