Hi,
As primary editor of the SSH draft (SSHSM), I spoke with Eliot last
week. I agree that it is difficult for him to develop a reasonable
proposal that piggybacks on the SSH draft, because the SSH draft is so
incomplete.
I am not convinced that SNMP needs to add a new call-home (CH)
functionality, nor that this feature is needed in SNMP now, but there
is a danger that CH might never be possible if we don't consider its
impact on the SSHSM model before SSHSM is cast in stone. If it
complicates the SSHSM model, I would prefer to not include it; a new
model could be developed to replace or supplement the SSHSM model if
demand increases for this functionality.
I recommended to Eliot that he contribute some text for the SSH
document, describing the CH functionality and proposed elements of
procedure, that I could include as an appendix to the SSHSM document
so the WG could review his proposal, and then the WG could decide
whether it should remain as an appendix, be incorporated into the SSH
document, be split out as a separate document, or be abandoned
altogether. I felt this was a reasonable alternative to making the
decision whether CH is or is not in scope at this time. He has not yet
had a chance to develop the text and send it to me.
David Harrington
dbharrington(_at_)comcast(_dot_)net
-----Original Message-----
From: isms-bounces(_at_)lists(_dot_)ietf(_dot_)org
[mailto:isms-bounces(_at_)lists(_dot_)ietf(_dot_)org] On Behalf Of Eliot Lear
Sent: Monday, September 12, 2005 3:53 PM
To: Sam Hartman
Cc: IETF Discussion; iesg(_at_)ietf(_dot_)org; isms(_at_)ietf(_dot_)org
Subject: [Isms] ISMS charter broken- onus should be on WG to fix it
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(_at_)cisco(_dot_)com> 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(_at_)lists(_dot_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/isms
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf