2nd Request for SEMP code and docs (was Re: XMPP is too stuffy)

[tluk...@exnihilum.com]

Jason,

Is there any reason why you haven't responded to my request for the SEMP code and documentation for review?

TL


-----Original Message-----
From: "Jason N. Meiers" [jason....@gmail.com]
Date: 03/09/2009 04:45 AM
To: cloud...@googlegroups.com
Subject: Re: XMPP is too stuffy

Sam, it sounds like you need a huge.
 
Jason


On Mon, Mar 9, 2009 at 2:56 AM, Paul Borrill <pa...@replicus.com> wrote:
Sam, Bravo.  Clean, factual, professional. Well done.

    Paul



Dr. Paul Borrill
President/Founder
REPLICUS Software Corporation
Direct:  (650) 917-9084
Mobile: (650) 380-2698
pa...@replicus.com
http://www.replicus.com/ 






On Mar 8, 2009, at 12:42 AM, Sam Johnston wrote:

Jason,

What you fail to mention about this unknown protocol that you "recommend" is that it is yours. I fail to see how this is even in the same league as the well established XMPP standard and at least some of us have been working on XMPP projects relating to cloud computing since long before even CCIF existed so I dont know what makes you think you might be able to change that now, no matter how much you spam cloud groups. Wheres the standard? Reference implementations? Patent pledges? Is it just me or is the Google Code project you refer to completely empty? The (soon to be deleted) Wikipedia article you created on the subject isnt much better and your leading assertion that "Simple Event Management Protocol (SEMP) is a component of the Internet Protocol Suite" is, to be frank, laughable.

I cant help but to notice that you happen to be offering a commercial SEMP service at UtilityStatus (somewhat the conflict of interest wouldnt you say?), and that your only listed client, CloudAutonomics, happens also to be you! I see that CloudAssets and CloudRequest are you too, as is CAM Solutions. What I dont see is tangible products, or in this case, protocols.

Anyway I dont so much care for your various endeavours but I do care passionately about IP abuse (see here and here), which is why I find your recently registered trademark (#77484486) for "monitoring-as-a-service" rather offensive. Youre no doubt aware my TrustSaaS service which also falls into this category (but which is not marketed as such given my disdain for *aaS), and of the various others such as RedHat (which are, and who beat you to it by a year or two by the way). Indeed you took the liberty of removing them all when you hijacked Wikipedias monitoring as a service article shortly after your questionable trademark was issued; it seems you believe that this gives you the right to hijack articles but as you will soon see, it most certainly does not. I also have plenty of better things to do with my Sunday morning than clean up after spammers.

In summary, given your recent shenanigans with intellectual property abuse I dont see any reason why your commercially-driven "protocol" should get any more discussion than it already has (which, incidentally, is probably more than it ever deserved).

Cheers,

Sam

On Sat, Mar 7, 2009 at 12:30 PM, JM <jason....@gmail.com> wrote:

working many protocols over the years i.e SNMP, JMX and other
proprietary protocols complexity has always been an issue to support
in a continues changing environment. To support more interoperability
I recommend using SEMP (Simple Event Management Protocol ).
http://code.google.com/p/opensemp. This has a canned set of parameters
that vendors can subscribe to and are able to support long term the
mission to provide interoperability between clouds.

JM












<br

[JM]

The open semp docs were on Wikipedia, Sam deleted it yesterday as well
as the Montioring-as-a-Service(TM) after publishing it in the group.
Once I get back to my office computer I'll upload it again.

TL, you don't happen to be friends with Sam do you.

Jason Meiers
Monitoring-as-a-Service(TM)
http://www.utilitystatus.com

On Mar 9, 10:17 am, "tluka...@exnihilum.com" <tluka...@exnihilum.com>
wrote:

> Jason,
>
> Is there any reason why you haven't responded to my request for the SEMP code and documentation for review?
>
> TL
>
> -----Original Message-----
> From: "Jason N. Meiers" [jason.mei...@gmail.com]
> Date: 03/09/2009 04:45 AM
> To: cloud...@googlegroups.com
> Subject: Re: XMPP is too stuffy
>
> Sam, it sounds like you need a huge.
>  
> Jason
>

> On Mon, Mar 9, 2009 at 2:56 AM, Paul Borrill <p...@replicus.com> wrote:
> Sam, Bravo.  Clean, factual, professional. Well done.  
>
>     Paul
>
> Dr. Paul Borrill
> President/Founder
> REPLICUS Software Corporation
> Direct:  (650) 917-9084
> Mobile: (650) 380-2698

> p...@replicus.comhttp://www.replicus.com/ 

>
> On Mar 8, 2009, at 12:42 AM, Sam Johnston wrote:
>
> Jason,
>
> What you fail to mention about this unknown protocol that you "recommend" is that it is yours. I fail to see how this is even in the same league as the well established XMPP standard and at least some of us have been working on XMPP projects relating to cloud computing since long before even CCIF existed so I dont know what makes you think you might be able to change that now, no matter how much you spam cloud groups. Wheres the standard? Reference implementations? Patent pledges? Is it just me or is the Google Code project you refer to completely empty? The (soon to be deleted) Wikipedia article you created on the subject isnt much better and your leading assertion that "Simple Event Management Protocol (SEMP) is a component of the Internet Protocol Suite" is, to be frank, laughable.
>
> I cant help but to notice that you happen to be offering a commercial SEMP service at UtilityStatus (somewhat the conflict of interest wouldnt you say?), and that your only listed client, CloudAutonomics, happens also to be you! I see that CloudAssets and CloudRequest are you too, as is CAM Solutions. What I dont see is tangible products, or in this case, protocols.
>
> Anyway I dont so much care for your various endeavours but I do care passionately about IP abuse (see here and here), which is why I find your recently registered trademark (#77484486) for "monitoring-as-a-service" rather offensive. Youre no doubt aware my TrustSaaS service which also falls into this category (but which is not marketed as such given my disdain for *aaS), and of the various others such as RedHat (which are, and who beat you to it by a year or two by the way). Indeed you took the liberty of removing them all when you hijacked Wikipedias monitoring as a service article shortly after your questionable trademark was issued; it seems you believe that this gives you the right to hijack articles but as you will soon see, it most certainly does not. I also have plenty of better things to do with my Sunday morning than clean up after spammers.
>
> In summary, given your recent shenanigans with intellectual property abuse I dont see any reason why your commercially-driven "protocol" should get any more discussion than it already has (which, incidentally, is probably more than it ever deserved).
>
> Cheers,
>
> Sam
>

> On Sat, Mar 7, 2009 at 12:30 PM, JM <jason.mei...@gmail.com> wrote:
>
> working many protocols over the years i.e SNMP, JMX and other
> proprietary protocols complexity has always been an issue to support
> in a continues changing environment. To support more interoperability

> I recommend using SEMP (Simple Event Management Protocol ).http://code.google.com/p/opensemp. This has a canned set of parameters

[Alexis Richardson]

Jason,

I think what the group is interested in, is the product documentation
and code, for your implementation of SEMP. Because these belong to
you, a fine place to put them is Google code. If you put them there,
then nobody can delete them. We'd all love to see this.

I should point out in passing, that Wikipedia has some rules for
posting content, that may make it difficult for you to talk about SEMP
on there, until you have been able to win wider support for it. This
can take time.

Best wishes,

alexis

[Jason N. Meiers]

Alexis,

good stuff, constructive critic is what a few of us need here. I will post the code, no problem.

Jason

[Paulo Calcada]

Apart from personal considerations, this is a real good thread, so here it's my thoughts about this subjects

I think that Ralph has done a fundamental consideration - We would need always  to separate Service Layer from an Infrastructure layer. Despite the fact that this two layer are completely related to each other, we must realize that depending on which one we are focusing our work,  we could end by having different solution or technologies to work with.

For instance, in the infrastructure layer we always have to deal with the IT administrators perspective, and as an IT administrator, I already have a monitoring and management structure based on SNMP. So, when deciding to migrate to the Cloud, I would be very happy to had just another SNMP node to deal with. I'm aware of all the problems that SNMP have, Some problems were solved by SNMPv3, the security problems for instance, but others still exists, the SMNP complexity is one of those problems. But we must realize that the SNMP complexity is related with its openness and his something that IT administrators already have managed deal with.

Paulo

2009/3/9 Jason N. Meiers <jason....@gmail.com>

[JM]

Paulo, thats exactly the propose of a canned format to simplify the
variables. Vendors add new SNMP parameters every release as and IT
admin you have to update SNMP configuration all the time. This way you
are dependent on vendors changes. In the case of SEMP a canned set of
variables we turn the equasion around that the vendors need to apply
to our cloud managment standards from an IT admin persprective. Does
that make sense?

On 9 Mrz., 12:59, Paulo Calcada <pcalc...@gmail.com> wrote:
> Apart from personal considerations, this is a real good thread, so here it's
> my thoughts about this subjects
>
> I think that Ralph has done a fundamental consideration - We would need
> always  to separate Service Layer from an Infrastructure layer. Despite the
> fact that this two layer are completely related to each other, we must
> realize that depending on which one we are focusing our work,  we could end
> by having different solution or technologies to work with.
>
> For instance, in the infrastructure layer we always have to deal with the IT
> administrators perspective, and as an IT administrator, I already have a
> monitoring and management structure based on SNMP. So, when deciding to
> migrate to the Cloud, I would be very happy to had just another SNMP node to
> deal with. I'm aware of all the problems that SNMP have, Some problems were
> solved by SNMPv3, the security problems for instance, but others still
> exists, the SMNP complexity is one of those problems. But we must realize
> that the SNMP complexity is related with its openness and his something that
> IT administrators already have managed deal with.
>
> Paulo
>

> 2009/3/9 Jason N. Meiers <jason.mei...@gmail.com>

>
>
>
> > Alexis,
>
> > good stuff, constructive critic is what a few of us need here. I will post
> > the code, no problem.
>
> > Jason
>
> > On Mon, Mar 9, 2009 at 11:02 AM, Alexis Richardson <
> > alexis.richard...@gmail.com> wrote:
>
> >> Jason,
>
> >> I think what the group is interested in, is the product documentation
> >> and code, for your implementation of SEMP.  Because these belong to
> >> you, a fine place to put them is Google code.  If you put them there,
> >> then nobody can delete them.  We'd all love to see this.
>
> >> I should point out in passing, that Wikipedia has some rules for
> >> posting content, that may make it difficult for you to talk about SEMP
> >> on there, until you have been able to win wider support for it.  This
> >> can take time.
>
> >> Best wishes,
>
> >> alexis
>

> >> >> Direct:                (6...       
> >> >> Mobile:              (6...       

> >> >> <br- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Paulo Calcada]

Yes, it makes sense, and it's honorable intention. But first, I think that this is the general propose of the UCI working group. And the question here is about using XMPP or a simpler approach (communication mechanism). The other question is if we would be able deploy this set of variables. You must agree that, that was the first intention of the SNMP, and that SNMP, in fact,  has a large group of predefined variables that could be used. Vendors always will want to add extra variables as they always are trying to add extra value to theirs business.


Paulo
cloudviews.org

2009/3/9 JM <jason....@gmail.com>

[Sam Johnston]

Jason,

Perhaps you could also tell us more about the SEMP patent(s) you claimed off-list to have applied for with your stimulus check (as well as licensing arrangements for same) as I can't find them. When exactly did you plan to reveal that your alternative to "stuffy" XMPP was patented?

Also there were four Wikipedia editors involved in the decision to speedy delete your articles as spam, as you well know from the AfD debates you vandalised here and here. One of them was also found to be a copyright violation by the reviewing administrator. Yes I nominated them but it wasn't even me who pulled the trigger.

To be clear, if you upload them again you will be blocked as you have been repeatedly warned by various editors. I would suggest that this page is not appropriate either in light of the consensus.

Thanks,

Sam

P.S. I have no idea who "TL" is (from his earlier post about the domain name it seems that this is quite intentional).

[Jason N. Meiers]

Paulo, agree there will always be a push for adding more variables as long as the mission statement stays the same, to provide a protocol for " IT administrators not vendors" we should be good. i.e. adding a counsel simular to SNMP would help if that is UCI or another. Since this protocol has been introced specifically for cloud computing at the infrastructure level UCI would be best IMHO.

[Jason N. Meiers]

Sam, ZZZZZZZZZZZZZZZZZZzzzzzzzzzzzzzzz

 

It's hard to take you seriously when your goal is to make this group fail not succeed, as described in you blog.

"Cloud Computing Interoperability Forum (CCIF) is dead and doghoused"

http://samj.net/2009/03/cloud-computing-interoperability-forum.html

 

I think everyone benefits if we are able to move this group CCIF forward, including cloud service availability.

[Sam Johnston]

Jason,

As amusing as it is that you should post this here after my attempt to do so was rejected by the moderators, your responses are getting increasingly childish. If you knew what was good for you then you would promptly desist flogging this particular dead horse.

You appear to be specfically avoiding requests for more details (for example the Google Code project remains empty despite your "upload in progress"). More importantly though you are obviously trying to divert attention from the question about your patent(s).

Proposing an open standard without revealing conflicts is one thing, but holding a patent over the proposed technology, in my opinion, is a very serious offense:

1. Patent obvious "intention" that already exists
1a. For extra irony use money intended to stimulate the economy, not constrain it
2. Find an acronym, prepend "open", write some puffery and spam it far and wide
3. Propose your "invention" as a standard, citing yourself as an early adopter
4. ???
5. Profit!

I admit the purpose of the patent is not entirely clear to me - surely you would not be so obnoxious as to attempt to tax the victims who adopted your "open standard"? Was there something else I've missed?

Sam

[Jason N. Meiers]

Sam, you should really call you psyciatrist, doctor or at least your mother.

[Alexis Richardson]

Group,

This group is moderated. If you feel that people's discourse is
crossing the bounds that *you* the community want, please post, or
contact the mods.

alexis

[Jason N. Meiers]

agree, I suggest to kick Sam. He has shown no value add to the group but rather disturbing posts. If you want to kick me thats fine also, democratcy is they way to do it. go4it lets vote.

[Sam Johnston]

On Mon, Mar 9, 2009 at 3:14 PM, Jason N. Meiers <jason....@gmail.com> wrote:

Sam, you should really call you psyciatrist, doctor or at least your mother.

Enough already. In Wikipedia we have a "No Personal Attacks" policy which in a nutshell says "comment on content, not on the contributor". I don't see any reason why the same should not apply here - we are (for the most part) professionals working towards cloud standards.

The community already unanimously decided not to moderate this discussion but that doesn't mean we can't kick/ban squeaky wheels. Unless your very next post answers the outstanding questions about design, code and patents then I'd say it's well past time to consider you be the first to be banned.

Sam

[eprpa...@gmail.com]

Alexis,

Personally I expect this thread to devolve to Nazis at any time now. I
also think it is going too far and becoming personal on the part of
Jason. Now should be the time you step in and moderate it.

Chuck Wegrzyn

[Pat Wendorf]

I agree.  TL/Sam/Jason, please take your discussion of SEMP to the SEMP mailing list.  Real time communication tools are a really great for building cloud systems, but I'm not sure we should get this hung up on the specifics yet.

[Jason N. Meiers]

sounds good. what are next steps for the acceptance. real time call?

[Sam Johnston]

On Mon, Mar 9, 2009 at 3:29 PM, Jason N. Meiers <jason....@gmail.com> wrote:

He has shown no value add to the group but rather disturbing posts.

In addition to identifying serious IP problems with your proposal here's some value add for you:

---------- Forwarded message ----------
From: Sam Johnston <sa...@samj.net>
Date: Fri, Feb 20, 2009 at 5:09 PM
Subject: Re: What about wiki-fying these dicusssions
To: cloud...@googlegroups.com

On Fri, Feb 20, 2009 at 2:21 PM, Stefan <netfo...@gmail.com> wrote:

My original post/question was meant to exclusively raise the issue of directing the efforts with - maybe! - a better framework.

Well you've come to the right place. The Cloud Computing Community's privacy policy addresses many of the issues with other forums (including this one) and mission is simply:

To create an open, unmoderated community in which to further the interests of cloud computing and its users.

It's not incompatible with this group either - you're welcome to augment discussion here with work there and vice versa. We're not trying to build a list (to boostrap a conference for example) or to promote anyone or any commercial entity, just to develop and deliver free (e.g. CC-BY-SA) content for the community to use.

The choice of the MediaWiki software was simply to better integrate the efforts with Wikipedia so as to share our findings with the community at large, only without the encyclopedic requirements:

"Except as otherwise locally overridden by consensus, the policies and guidelines of Wikipedia loosely apply. These typically stem from the five pillars but notability and verifiability requirements may be lightened and controlled original research allowed.

Where content does however meet Wikipedia's standards it should be included in and/or migrated over, in order for us to contribute to the larger community. In particular, controversial topics such as definitions can benefit from the structure provided by Wikipedia and consensus can be reached on article talk pages.

Cloud computing users range from individuals through the largest organisations. Anyone can edit (you don't even need to create an account) so be BOLD and start contributing!"

Deliverables thus far include:

• Cloud Computing Bill of Rights
• Cloud Computing Stack (more from a user/developer than a provider point of view)
• Cloud Computing Incidents Database (CCID)

This is a genuine, open, non-discriminatory, non-commercial environment (indeed the only entity mentioned is in a commitment to hand over the site should a non-profit entity ever be formed). It should be perfect for the type of development discussed here. For those who are not MediaWiki users or Wikipedians the talk pages 'behind' each article promote focused discussion and a and provide a transparent, auditable mechanism for reaching consensus.

To get started just create an account, browse to a page that doesn't already exist (like this one) and create it.

Sam

[Jason N. Meiers]

thats why its open semp and not Cisco/HP XMPP.

[Sam Johnston]

Pat,

On Mon, Mar 9, 2009 at 3:32 PM, Pat Wendorf <dung...@gmail.com> wrote:

I agree.  TL/Sam/Jason, please take your discussion of SEMP to the SEMP mailing list.  Real time communication tools are a really great for building cloud systems, but I'm not sure we should get this hung up on the specifics yet.

The inappropriateness of your comment (as Reuven/Enomaly's employee) aside, there is no SEMP mailing list that I am aware of - and no SEMP so far as we can tell (the Google Code project remains empty). Aside from the various personal attacks from one vendor, the other contributors to this thread (including TL and myself) have raised pertinent points about a proposed standard as well as relevant technical details about a major component - both of which are clearly on topic.

If, as you say, we should "[not] get this hung up on the specifics yet" then when would you say is a good time, bearing in mind that the group has been around for six months already and others (e.g. here and here) are popping up every day to address its charter?

Sam

[Jayson Vantuyl]

@Jason

You hold a patent over "OpenSEMP".

XMPP is an IETF standard with a patent grant.

Sticking the word "Open" on something patented doesn't make it more
"open" than a defined standard, with an explicit IP policy, that has
an implementation that was only recently bought by Cisco.

Your claim is ludicrous.

@Moderators:

This guy is either a profiteer or a troll. Please moderate as such.

I also am against censuring SamJ in any way, as he is only attempting
to add important facts to this discussion, which Jason is curiously
trying to deflect with bad ad hominem attacks.

On Mar 9, 8:24 am, "Jason N. Meiers" <jason.mei...@gmail.com> wrote:
> thats why its open semp and not Cisco/HP XMPP.
>

> On Mon, Mar 9, 2009 at 3:35 PM, Sam Johnston <s...@samj.net> wrote:

> > On Mon, Mar 9, 2009 at 3:29 PM, Jason N. Meiers <jason.mei...@gmail.com>wrote:
>
> >> He has shown no value add to the group but rather disturbing posts.
>
> > In addition to identifying serious IP problems with your proposal here's
> > some value add for you:
>
> > ---------- Forwarded message ----------
> > From: Sam Johnston <s...@samj.net>
> > Date: Fri, Feb 20, 2009 at 5:09 PM
> > Subject: Re: What about wiki-fying these dicusssions
> > To: cloud...@googlegroups.com
>

> > On Fri, Feb 20, 2009 at 2:21 PM, Stefan <netfort...@gmail.com> wrote:
>
> >> My original post/question was meant to exclusively raise the issue of
> >> directing the efforts with - maybe! - a better framework.
>
> > Well you've come to the right place. The Cloud Computing Community's privacy

> > policy <http://wiki.cloudcommunity.org/wiki/Privacy_policy> addresses many
> > of the issues with other forums (including this one) and mission<http://wiki.cloudcommunity.org/wiki/Community>is simply:
>
> > *To create an open, unmoderated community in which to further the
> > interests of cloud computing and its users.*

>
> > It's not incompatible with this group either - you're welcome to augment
> > discussion here with work there and vice versa. We're not trying to build a

> > list (to boostrap a conference <http://cloudslam09.com/> for example) or

> > to promote anyone or any commercial entity, just to develop and deliver free
> > (e.g. CC-BY-SA) content for the community to use.
>
> > The choice of the MediaWiki software was simply to better integrate the
> > efforts with Wikipedia so as to share our findings with the community at
> > large, only without the encyclopedic requirements:
>
> > "Except as otherwise locally overridden by consensus, the policies and

> > guidelines of Wikipedia <http://en.wikipedia.org/wiki/Wikipedia> loosely
> > apply. These typically stem from the five pillars<http://en.wikipedia.org/wiki/WP:5P>but
> > notability <http://en.wikipedia.org/wiki/WP:N> and verifiability<http://en.wikipedia.org/wiki/WP:V>requirements may be lightened and controlled original
> > research <http://en.wikipedia.org/wiki/WP:OR> allowed.

>
> > Where content does however meet Wikipedia's standards it should be included
> > in and/or migrated over, in order for us to contribute to the larger
> > community. In particular, controversial topics such as definitions can
> > benefit from the structure provided by Wikipedia and consensus can be
> > reached on article talk pages.
>

> > *Cloud computing users range from individuals through the largest

> > organisations. Anyone can edit (you don't even need to create an account) so

> > be BOLD <http://en.wikipedia.org/wiki/WP:BOLD> and start contributing!"*
>
> > Deliverables thus far include:
>
> >    - Cloud Computing Bill of Rights<http://wiki.cloudcommunity.org/wiki/CloudComputing:Bill_of_rights>
> >    - Cloud Computing Stack<http://wiki.cloudcommunity.org/wiki/CloudComputing:Stack>(more from a user/developer than a provider point of view)
> >    - Cloud Computing Incidents Database (CCID)<http://wiki.cloudcommunity.org/wiki/CloudComputing:Incidents_Database>

>
> > This is a genuine, open, non-discriminatory, non-commercial environment

> > (indeed the only entity mentioned is in a commitment<http://wiki.cloudcommunity.org/wiki/Community#Organisation>to hand over the site should a non-profit entity ever be formed). It should

> > be perfect for the type of development discussed here. For those who are not
> > MediaWiki users or Wikipedians the talk pages 'behind' each article promote
> > focused discussion and a and provide a transparent, auditable mechanism for
> > reaching consensus.
>

> > To get started just create an account<http://wiki.cloudcommunity.org/index.php?title=Special:UserLogin&retu...>,
> > browse to a page that doesn't already exist (like this one<http://wiki.cloudcommunity.org/wiki/Cloud_Computing_Interoperability_...>)
> > and create it.
>
> > Sam

[Geir Magnusson Jr.]

+1