Re: [Isms] charter proposal
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Isms] charter proposal



Hi Juergen,

First let me say that I did not mean to direct the message at you.   As
I recall you played very little part in discussions at the actual
meeting - not that there's anything wrong with that.  My concern is that
we have reached a perverse result without proper consideration of the
ramifications (not that you caused such a result).  Your message
containing the proposed updated charter required me to respond as I find
the charter wholly unacceptable (to the point that if it goes forward
under the current conditions I will appeal).  I recognize, however, that
you are accurately reflecting the sense of the room.

> The TMSM document was written with ssh in mind. This is mentioned in
> the ID. I am happy to leave it to the chairs and the ADs to gauge the
> level of discussion of SSH as a transport on the ISM WG mailing list
> and to compare that to BEEP.

Conveniently it works for both.  And I generally think that the TMSM is
good as far as it goes, and I agree with you that we should separate it
out from protocol, adopt it as a WG doc, and get it done.

As to the below:

> Can't remember whether this is accurate. I do remember jabber log
> statements that call home might be doable with ssh as well - I can't
> judge that at the moment. I do however realize that SNMP right now
> does not have call home - so you are proposing to add a feature to
> SNMP which does not yet exist in that form.

Yes, I am and it's important.  The world is very different from the way
it was when v3 was developed.  Unless people find it necessary to do so
I will not regurgitate the full logic behind this.

> 
> 
>> - There was general preference for a single mechanism between NETCONF
>>   and SSH.
> 
> 
> Not sure I understand the semantics of this sentence...

In other words, better we end up with one protocol rather than two and
in principle I agree with that notion.


> I heard Simon saying that he uses SSH for management, actually using
> passwords authentication (even though he seemed to prefer in principle
> to use public key SSH authentication). Simon, correct me if I am wrong.

Yes, he is sitting next to me (not on the list).  This is what he said.
 However, he went on to vote for BEEP.

> 
> I heard Ruediger saying that he doubts that someone types in SNMP
> messages into SSH (which I can easily agree with) and that he does not
> really care what the security protocol on the wire looks like as long
> as it integrates. Ruediger, correct me if I am wrong.
> 
> 
>> - NETCONF/SSH specifically excluded "call home" functionality.
> 
> 
> Not sure this is accurate. I think NETCONF decided to make a straight
> forward ssh mapping mandatory. Other mappings can be used as well but
> are not mandatory.

Well, the "straight ssh forward mapping" does not support call home.  To
quote draft-ietf-netconf-ssh-04.txt:

>   When NETCONF is run over SSH using the mapping defined in
>   this document, the client is always the manager, and the server is
>   always the agent.


>>In our haste to create a solution that integrates with other security
>>solutions we are producing something that won't integrate with other
>>network management solutions.
> 
> 
> Which ones? I doubt that SNMP based solutions have a call home feature
> right now.

No, I'm referring to {SNMP/NETCONF}/{SSH/BEEP}.  Let's be clear: there
is no call home function in the NETCONF/SSH mapping.  Even if you do
such a thing for SNMP/SSH, one must use two different call home
mechanisms.  This is how things are lining up and it's the wrong way to go.

>>Now you could say that perhaps the NETCONF/SSH specification should have
>>"call home" added to it.  The reason Margaret didn't include it was that
>>she felt if you wanted that sort of thing, use BEEP.  That was her
>>logic.  It's not unreasonable.
> 
> 
> I prefer to let Margaret speak for herself since there are different
> interpretations possible for a statement of the sort "if you wanted
> that sort of thing, use BEEP".

While I agree it's always best if she speaks for herself, I don't
believe I am misrepresenting her opinion.  As you can see she followed
through with it in the draft.

> 
> 
>>I have no problem working through the issues that separate BEEP and SSH.
>>But to have prematurely made the decision is, I assert again, unwise.
> 
> 
> Maybe it is, maybe not. With netconf, we took the approach that SSH is
> mandatory and to let the market sort out the rest. In isms, it was
> somehow determined yesterday that doing this same approach wastes
> resources.

Yes, it's the "somehow" that eludes me.  The decision as I repeatedly
said yesterday is premature.

> 
> If you think this decision is wrong, you should I think primarily
> contact the chairs and the ADs - I am clearly not the one to determine
> concensus. (So I am kind of wondering why this message was directed to
> me and not to the chairs - perhaps too many Juergens around here.)

Again, I apologize if this sounded like a complaint against you.  It was
not meant as such (far from it).  I'm saying that the working group is
going down a perilous path for many many reasons.  It is not just the
chairs and the ADs that need to hear this.  It is the working group as
it is the working group that needs to change course.

Also, all decisions at IETF are confirmed by the mailing list.  I am
saying that this is one we ought not confirm.  Instead, we should
continue with draft development and compare approaches, particularly in
light of the broader context, and then make a decision.

The ADs have made it clear that they want us to finish, and have
suggested that perhaps an interim meeting might help.  I repeat my offer
to the group:  if the group would like to hold an interim meeting, I
would be happy to host it at the end of September in Switzerland.

Eliot

_______________________________________________
Isms mailing list
Isms at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.