Subject: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63

From: Eliot Lear <[email-masked]>
Date: Sun, 14 Aug 2005 16:26:34 +0200

Hi,

I would request that the chairs call for consensus on the points
discussed at IETF 63.  As I recall there were four major decisions:

 - discarding of UDP options

 - advancing of Juergen's architecture draft separately

 - creating an SSH draft

 - moving forward solely on the basis of that draft

Perhaps others might disagree with my recollection.  I'll not argue for
or against in this message, but plan to do so on each of these questions
as they are called (hopefully separately).

Eliot

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 15 Aug 2005 02:34:07 +0200

Eliot,

Thanks for the request.

As stated at the saag session, I think that the following decisions
made the ISMS session need approval from the mailing list:

  1. The ISMS WG will work on one transport protocol only

  2. ISMS will use SSH as transport protocol

These issues are not exactly the ones from your list, but they
are targeting at the same direction and reflect the discussion
at the Paris session.

For 1. I am not aware of contrary opinions.  I see consensus on 1.
Anyone who disagrees, please speak up soon.

For 2. there was a clear preference at the session.  However,
there were statements challenging this decision on the list,
mainly from people in favor of BEEP.  At the session there
were also also people favoring TLS+SASL, but so far they did
not express severe concerns on the mailing list about choosing
SSH instead.

Concerns were raised at the meeting that none of the alternatives
(TLS+SASL, BEEP, SSH, and DTLS) are sufficiently described by an
Internet draft (for BEEP we have the most detailed description)
for making the decision.

However, we need to make progress and arguments have been exchanged
extensively.  Therefore I ask particularly people who did not
participate in the Paris session to express their concerns about
ISMS using SSH as transport protocol.

Thanks,

    Juergen

---

From: Eliot Lear <[email-masked]>
Date: Mon, 15 Aug 2005 15:27:35 +0200

Juergen:

> Anyone who disagrees, please speak up soon.

I do.  First, your use of the term "transport protocol" here is
confusing.  We agreed on several actions, one of which was dropping UDP,
which is a transport (L4) protocol.  I am neutral on whether we drop UDP
at this time.  If someone wants to work on it, I don't particularly
mind, so long as they come to the table with a concrete proposal I can
evaluate.

In addition, I object to the idea that we are anywhere near prepared to
eliminate ANY alternative given that today we have barely one (if one).
   We are also not in a position to compare "best" proposals.  It is
premature to eliminate ANY EK solution.

> Internet draft (for BEEP we have the most detailed description)

In addition to these concerns, I also raised the concern that if this
group chooses SSH where NETCONF has chosen BEEP for p2p/call home, we
end up moving AWAY from our goal of integration of security management.

> extensively.  

Juergen, the progress we need to make is on the drafts and not on
deciding prematurely which one is best.  So I ask that the group refute
[1] and encourage further development on all drafts.

Eliot

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 15 Aug 2005 19:18:56 +0200

Eliot,

Thanks for your comments.  Please see replies inline.

--On 8/15/2005 3:27 PM +0200 Eliot Lear wrote:

> confusing.

Please suggest a better term.

>             We agreed on several actions, one of which was dropping UDP,

I think going for just one solution was unchallenged by WG members
and I do not see this decision highly dependent on whether or not
UDP was already eliminated or not.
Do you really think that we should go for more than one solution?

> premature to eliminate ANY EK solution.

You say we cannot decide now.  The ADs had good reasons for giving
us a short-lived initial charter.  According to the current (extended)
one we can either agree or terminate.  There is the chance of following
Bert's recommendation to and extend the charter again until an interim
meeting.  This could create a better foundation for our decision,  but
the progress we can make until then is limited.  I am sure that we
could apply the same argument (the foundation for the decision is too
weak) again at the interim meeting.  Therefore I clearly prefer to
make the decision now on an admittedly not 100% solid foundation.

> [1] and encourage further development on all drafts.

The progress we need to make as WG is described by our charter saying

| Aug 05  Working group will recharter to include publication goals
|         or shutdown if no consensus on a technical direction is
|         reached by this time.

Thanks,

    Juergen

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 15 Aug 2005 14:39:18 -0400

Hi,

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Quittek

> make the decision now on an admittedly not 100% solid foundation.

I agree that it is simply too early to eliminate any options. But at
the same time we need to agree on a WG direction to which we will
commit our limited resources. My issue is largely with the wording.
>From the Mirrriam-Webster dictionary:

Eliminate "to cast out or get rid of : REMOVE, ERADICATE <the need to
eliminate poverty> b : to set aside as unimportant : IGNORE"

Focus "a center of activity, attraction, or attention <the focus of
the meeting was drug abuse> b : a point of concentration"

I believe the WG consensus is to FOCUS on one solution at this time,
to determine whether it is a viable solution or not. SSH with a RADIUS
backend appears to be the consensus of the WG as a solution to FOCUS
our efforts on in the near future. This consensus appears to be based
on the wide deployment of these protocols, the willingness of editors
to produce written proposals, and to a lesser degree the compatibility
with the Netconf decision to select SSH as their primary
(application-transport) protocol.

I do not believe we should eliminate/eradicate/remove/ignore the BEEP
proposal, but it should be an area of secondary focus. We should not
assign any working group resources to work on this proposal, but we
should not discourage willing editors from producing such concrete
proposals, and should not ban discussion of the secondary-focus
concrete proposals from the mailing list of this WG because the
difference between SSH and alternative proposals could prove to
highlight some differences between the proposed solutions, as was the
case in the Netconf WG.

To put this into product-development terms, we should first assign
engineers to work on releasing an SSH/RADIUS feature because that
appears to have the greatest demand from customers, and, after we
release the SSH/RADIUS solution, if customer demand proves sufficient
to justify developing BEEP support as well, we could do so in a later
release.

David Harrington
[email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Mon, 15 Aug 2005 16:28:54 -0400

As an AD, I would be uncomfortable with a charter that did not pick
some direction to focus on.  There are a lot of reasons for this.  One
is that we've been spending a lot of energy on this decision and it
would concern me if we cannot at least decide on a direction after
having spent this long thinking about it.  Also, as David points out,
we do have limited resources and I need to make sure that we commit to
a task that I believe we can accomplish.

So, I do think it is important that we focus on some mandatory to
implement solution in our charter.  I also think it is important that
we identify such a solution at the time of chartering, although I am
open to arguments why this is not the case.

However I do understand David and Eliot's concerns.  I would support a
charter that focused on one direction but allowed for parallel
development of alternatives.

If we found that at some future time that the primary focus did not
meet our needs we could recharter to change our focus.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 16 Aug 2005 07:46:03 +0200

Hi Juergen,

> Please suggest a better term.

I think simply distinguishing between UDP and TCP (which as you recall
was one of the columns on the board at one point) and then the specific
substrates (TLS, SSH, TLS/BEEP) would be sufficient.  N.B., I think
there was only one sketch of a proposal in the UDP column.

> Do you really think that we should go for more than one solution?

Here I believe there was some confusion in the room (and I may have been
one of the people confused).  In the end, I would prefer one solution,
as that is best for interoperability, as I believe one of the ADs
mentioned in another contentious area.  But we are not at the end, and
this is the source of the confusion.  Right now we are at a point where
there is only one proposal on the table that we seem to have eliminated.

Before we even consider knocking the number of proposals down to one, we
should probably start with MORE than one.  This has all the benefits
I've previously mentioned to you.

> us a short-lived initial charter.  

Let's be careful not to conflate the need for a the charter revision
with a choice of protocol.    I believe the ADs should assist us in
developing a viable charter that gets us to a point where we can decide
amongst the choices.

>
> Therefore I clearly prefer to

Think about this statement.  This is the fundamental problem I have.  We
can and should do better than this.  I've clearly stated a right hand /
left hand problem with NETCONF and this group involving choice of
substrates.  I know that Bert stated his concern about which protocol is
mandatory.  I think both are problems that need to be addressed.

As I said in the working group, we can do anything with either protocol.
 It's only a matter of bits.  But if we do one thing where NETCONF did
another, we're not doing a very good job of resource management either
in the IETF or back in our companies, for that matter!

> |         or shutdown if no consensus on a technical direction is

A viable consensus is to proceed to develop several choices from which
we will choose one or more to be standardized.

Eliot

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 16 Aug 2005 19:09:29 +0200

Juergen (and your co-chair:-),

I struggle with the way you do this.  You ask for those who disagree with
1. The ISMS WG will work on one transport protocol only
to speak up so the list will contain only or mostly contrary views.  How then do
you judge
rough consensus on this if those in favour have not spoken?

(I am in favour)

Tom Petch

----- Original Message -----
From: "Juergen Quittek" <[email-masked]>
To: "Eliot Lear" <[email-masked]>; <[email-masked]>
Sent: Monday, August 15, 2005 2:34 AM
Subject: Call for consensus,was: [Isms] request for confirmation (or lack
thereof) of thedecisions made at IETF63

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 17 Aug 2005 00:13:22 +0200

Tom,

> rough consensus on this if those in favour have not spoken?

We had a lot of people at the session who were in favor.
The intention of the call for consensus is finding out if there
is a significant number of people who disagree, but could not
join us at the meeting or who changed their minds after the
session  Also people should speak up who discovered new problems
with this way, that have not been considered yet.

Thanks,

    Juergen

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 25 Aug 2005 17:05:58 -0700

>>>>> On Mon, 15 Aug 2005 02:34:07 +0200, Juergen Quittek <[email-masked]> said:

Juergen> As stated at the saag session, I think that the following decisions
Juergen> made the ISMS session need approval from the mailing list:

Juergen> 1. The ISMS WG will work on one transport protocol only

Juergen> 2. ISMS will use SSH as transport protocol
...
Juergen> For 1. I am not aware of contrary opinions.  I see consensus on 1.
Juergen> Anyone who disagrees, please speak up soon.

Sorry for the delay of about 10 days, but it's been a very busy 10
days following vacation (which is really short for
"let-build-up-happen-at-work").

Trying to be brief, but I'll probably fail.

1) I do think we should pick one transport as mandatory, and that
   transport should be SSH since it is the most widely deployed.
2) I think it would be a mistake to only work on just that one for
   various reasons.
   2a) I don't know for sure, as I documented in a long message
       sometime in July, whether eliminating UDP from ISMS proposals
       is a wise choice.  Maybe it would be ok, but I'm not at all
       comfortable with saying we don't need it (and forcing a fall
       back to USM doesn't help me at all).
   2b) SSH, though quite popular, only meets the criteria of some of
       the operators out there.  Locking down to just one pretty much
       tells the rest of them to conform, which I doubt they'll do.
   2c) If SSH is replaced by something in the future in operational
       environments and we've only put work forward in one solution
       then I worry that we'll be back at some point in the future
       starting from too little work.
3) I do think we should focus, however, but if someone was willing to
   write an ID and he/she had volunteers to read and review it,
   great.  Why would I want to stop him/her?  If Eliot wants to
   provide further work in BEEP, I think that's excellent since I
   don't know if it'll be used in the future.  If his prediction that
   it's needed for network is true, I'd much rather have an ID ready
   to go in that case than no work done on it.
4) Personally, I don't care if netconf failed to support call home for
   netconf/SSH and the only option is netconf/BEEP.  The best solution
   there is not to force ISMS to use BEEP because another WG made a
   bad decision.  The right thing to do is see if netconf will update
   their document to allow for call home support.  There is almost no
   deployment of BEEP today and a lot of SSH.  If that changes, great,
   and I'd rather have a draft to support it.  But the only reason I'm
   writing so much is that I do agree that SSH should be the mandatory
   one based on today's world.
5) If I need to commit to reading/reviewing/what-have-you on documents
   I'm very willing to commit to helping out with SSH, DTLS and
   probably TLS as well since it'd be easy to do both DTLS and TLS at
   once so why wouldn't ya?  I wouldn't commit my personal resources
   to BEEP, but I don't care if others do.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 25 Aug 2005 17:07:59 -0700

>>>>> On Mon, 15 Aug 2005 15:27:35 +0200, Eliot Lear <[email-masked]> said:

Eliot> In addition to these concerns, I also raised the concern that if this
Eliot> group chooses SSH where NETCONF has chosen BEEP for p2p/call home, we
Eliot> end up moving AWAY from our goal of integration of security
Eliot> management.

I do want netconf and SNMPv3 to converge, as I've been saying for
ages.  But I don't necessarily think that netconf/beep will actually
prevail in the market.  I think it's more likely to see netconf/ssh
get fixed faster than netconf/BEEP to get widely deployed.  Maybe I'm
wrong.  I simply don't know.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 25 Aug 2005 17:18:34 -0700

>>>>> On Thu, 25 Aug 2005 17:05:58 -0700, Wes Hardaker <[email-masked]> said:

...
Wes> 5) If I need to commit to reading/reviewing/what-have-you on documents
Wes> I'm very willing to commit to helping out with SSH, DTLS and
Wes> probably TLS as well since it'd be easy to do both DTLS and TLS at
Wes> once so why wouldn't ya?  I wouldn't commit my personal resources
Wes> to BEEP, but I don't care if others do.
6) If forced, I'd rather see 1 SSH RFC and 0 others than 0 total.  IE,
   if the choice was SSH only or WG closure, SSH would be better than
   nothing at all.

-- 
Wes Hardaker
Sparta, Inc.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 26 Aug 2005 07:27:18 -0700

Wes,

Thanks for your message.  I'm a bit beyond the protocol discussion at
this point.  BEEP is just bits, same as SSH.  I suspect we could redo
lots of stuff in SSH that BEEP has done, and it wouldn't kill me.

To be very brief, my greater concern is an implementation of the CH
functionality, which has for the moment been ruled out of scope.

Eliot

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 29 Aug 2005 18:58:24 +0200

Dear all,

Hereby Ken and I state that the WG has achieved rough consensus on
two issues:

  1. The ISMS WG will work on one transport protocol only.
  2. ISMS will use SSH as transport protocol.

The consensus is not as clear as these statements look like.
There was quite some controversy discussion that is partially
reflected by the following comments on the consensus:

  - The WG focuses its resources on one transport protocol that is
    most promising in the near future.
  - SSH is the protocol to which the new charter of the WG will be
    restricted. The ISMS WG does not claim that SSH is the only
    suitable choice.
  - The WG encourages people developing solutions based on alternative
    transport protocols, such as BEEP or TLS, to pursue their work in
    parallel to the work done by the ISMS WG and to discuss their
    progress and results on the ISMS mailing list and at ISMS sessions.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2005 18:36:00 -0400

One other thing I think you should encourage is people working on
non-SSH solutions to give input to the architectural extensions.