Re: [clouds] Clouds SDO gap analysis template (a Table)

[Linda Dunbar <[e-mail]>]

I don’t think it is realistic for IETF to keep up with all the Cloud work
done by other SDO. “Cloud” is just too big a scope for one IETF working
group. We should focus on one concrete problem. Other SDO’s work will be
background and justify why this problem has to be solved by IETF instead of
other SDO. 

 

 

Linda Dunbar

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Sam Johnston
Sent: Tuesday, May 25, 2010 1:18 PM
To: Mark Carlson
Cc: [e-mail]
Subject: Re: [clouds] Clouds SDO gap analysis template (a Table)

 

Bhumip/Mark,

 

In terms of gap analysis, I'd be more interested in seeing other groups
feeding into IETF than having it picking up the scraps. I certainly intend
to submit CloudAudit, and ideally [parts of] OCCI to the I-D/RFC process for
a start. IETF is well known for having clean, interoperable specifications
which is something specialist groups are not so good at.

 

Sam

 

On 25 May 2010 19:49, Mark Carlson <[e-mail]> wrote:

That's great. When the IETF decides what it wants to do, you should
also create and maintain an entry up there.

Thanks,

-- mark


On 5/25/10 11:15 AM, Bhumip Khasnabish wrote: 

Dear Mark,

 

Thanks for your inputs and suggestions. 

 

Yes, we'll utilize all of the relevant existing information from the sites
that you mention and a few others.

 

As you know our objective is to determine the gaps (existing and emerging)
and focus on where IETF can contribute in terms of standardization (protocol
development, protocol extension recommendation, etc.) and profile
development for Cloud-based services. 

 

Hope these help clarify matters.

 

Thanks again.

 

Best.

 

Bhumip

 


 

On Tue, May 25, 2010 at 12:45 PM, Mark Carlson <[e-mail]>
wrote:

Bhumip,

Not sure why you are doing this. The information you need is largely already
available on http://cloud-standards.org <http://cloud-standards.org/>  wiki.
Each SDO has already created 
an entry describing their cloud work, and they use a standard template
already
to describe each standard.

For example, here is one for an already finalized standard:


http://cloud-standards.org/wiki/index.php?title=SNIA_Cloud_Data_Management_I
nterface_%28CDMI%29


Cloud Standard


1. The name of the specification 

SNIA Cloud Data Management Interface
    

2. A short statement (<100 words) of the purpose and function of the
specification The SNIA Cloud Data Management Interface (CDMI) is the
functional interface that applications will use to create, retrieve, update
and delete data elements from the cloud. As part of this interface the
client will be able to discover the capabilities of the cloud storage
offering and use this interface to manage containers and the data that is
placed in them. In addition, metadata can be set on containers and their
contained data elements through this interface. 

3. The version number (or other distinct identifier) and date of the most
recently approved version of the specification. 

SNIA Architecture - 1.0 standard 

4. If the specification is part of a group of explicitly related
specifications from the same source, the name of the group of
specifications. Not applicable 

5. URI for the normative text of the specification
http://www.snia.org/tech_activities/standards/curr_standards/cdmi 


SOURCE 


6. The name of the SDO that generated/authored/hosted the specification.
Storage Networking Industry Association 

7. URI for the SDO http://snia.org <http://snia.org/>  

8. The level of approval that the SDO has conferred on the specification as
described by the SDO's process. SNIA Architecture (Final Standard) 

9. The language or languages in which the specification is available. US
English 


SUBJECT 


10. Which of the categories of Cloud services does the standard address?
(Infrastructure as a Service - IaaS, Data Storage as a Service - DaaS,
Platform as a Service - PaaS, Software as a Service - SaaS) DaaS (Cloud
Storage) 

11. Does the standard address both functional and management aspects of the
service? Yes. Management is done by setting metadata on containers of data
and individual data elements. The functional interface allows CRUD semantics
for storage of data via HTTP. 


OPTIONAL 


12. The level of approval of the specification in this generic lifecycle
taxonomy: 

Final standard 


13. URI for the applicable SDO's patent and copyright rules, if any,
applicable to development and use of the specification. SNIA IP Policy
<http://www.snia.org/about/corporate_info/ip_policy/>  

14. URI for the SDO's posting location, (if any) for notices from
participants or individuals regarding claims under the rules stated under
number 15. SNIA IP Policy
<http://www.snia.org/about/corporate_info/ip_policy/>  

15. Interoperability, conformance, or certification test activity for the
specification (by owner name or URI). 

None 

16. Known implementations of the specification (by owner name or URI). 

The SNIA Cloud Storage TWG is producing an open source reference
implementation. 

17. A list (or URI pointer to same) of the other specifications* that are
normatively referenced in the specification. 


[ISO-8601] International Standards Organization, "Data elements and
interchange formats -- Information interchange -- Representation of dates
and times", ISO 8601:20044 -
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnum
ber=40874 

[ITU-T509] International Telecommunications Union Telecommunication
Standardization Sector (ITU-T), Recommendation X.509: Information technology
- Open Systems Interconnection - The Directory: Public-key and attribute
certificate frameworks, May 2000. Specification and technical corrigenda -
http://www.itu.int/ITU-T/publications/recs.html 

[RFC2119] IETF RFC 2119 <http://tools.ietf.org/html/rfc2119> . Key words for
use in RFCs to Indicate Requirement Levels -
http://www.ietf.org/rfc/rfc2119.txt 

[RFC2045] IETF RFC 2045 <http://tools.ietf.org/html/rfc2045> . Multipurpose
Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
- http://www.ietf.org/rfc/rfc2045.txt 

[RFC2578] IETF RFC 2578 <http://tools.ietf.org/html/rfc2578> . Structure of
Management Information Version 2 (SMIv2) -
http://www.ietf.org/rfc/rfc2578.txt 

[RFC2616] IETF RFC 2616 <http://tools.ietf.org/html/rfc2616> . Hypertext
Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt 

[RFC3280] IETF RFC 3280 <http://tools.ietf.org/html/rfc3280> . Internet
X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile - http://www.ietf.org/rfc/rfc3280.txt 

[RFC3530] IETF RFC 3530 <http://tools.ietf.org/html/rfc3530> . Network File
System (NFS) version 4 Protocol - http://www.ietf.org/rfc/rfc3530.txt 

[RFC3986] IETF RFC 3986 <http://tools.ietf.org/html/rfc3986> . Uniform
Resource Identifier (URI): Generic Syntax -
http://www.ietf/org/rfc/rfc3986.txt 

[RFC4346] IETF RFC 4346 <http://tools.ietf.org/html/rfc4346> . The Transport
Layer Security (TLS) Protocol Version 1.1 -
http://tools.ietf.org/rfc/rfc4346.txt 

[RFC4627] IETF RFC 4627 <http://tools.ietf.org/html/rfc4627> . The
application/json Media Type for JavaScript Object Notation (JSON) -
http://www.ietf.org/rfc/rfc4627.txt 

[RFC5246] IETF RFC 5246 <http://tools.ietf.org/html/rfc5246> . The Transport
Layer Security (TLS) Protocol Version 1.2 -
http://tools.ietf.org/rfc/rfc5246.txt 

 

18. A list (or URI pointer to same) of the other specifications* that are
referenced in the specification (except the ones listed under number 17). 

[CRC] Williams, Ross, "A Painless Guide to CRC Error Detection Algorithms",
Chapter 16, August 1993, http://www.repairfaq.org/filipg/LINK/F_crc_v3.html 

[PKS12] RSA Laboratories, PKCS #12: Personal Information Exchange Syntax,
Version 1.0, June 1999. Specification and Technical Corrigendum -
http://www.rsa.com:80/rsalabs/node.asp?id=2138
<http://www.rsa.com/rsalabs/node.asp?id=2138>  

[REST] "Representational State Transfer" -
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm>  

[RESTful Web] Richardson, Leonard and Sam Ruby, RESTful Web Services,
O'Reilly, 2007. 

[SIRDM] Storage Industry Resource Domain Model -
http://www.snia.org/education/storage_networking_primer/sirdm/ 


19. A list (or URI pointer to same) of other specifications* with which the
specification may (speculatively) interoperate or act in complementary,
compatible fashion. 

OCCI - see OGF entry. 

20. A list (or URI pointer to same) of other specifications* similar to this
specification. (Whether or not substitutable.) 

None. 

-----------------------------------

The template can be found here:
http://cloud-standards.org/wiki/index.php?title=Template

-- mark 



On 5/25/10 10:33 AM, Bhumip Khasnabish wrote: 

Dear All,

 

Attached please find a template (a Table) that can be utilized for Clouds
SDO gap analysis.

 

Very much appreciate your comments, inputs, suggestions for updating it.

 

The plan is to populate this template with SDOs' information, 

once this template is finalized through email discussion.

 

Thanks a lot for your support and contributions

 

Best Regards.

Bhumip

 

 


Bhumip Khasnabish (Mobile:[phone], [e-mail])

© 2010 Bhumip Khasnabish. Do not view, print, forward, and save the content
of this email if you are not the intended recipient of the communiqué.

 
_______________________________________________
clouds mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/clouds
  


_______________________________________________
clouds mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/clouds




-- 
Best Regards.

Bhumip Khasnabish (Mobile:[phone], [e-mail])

© 2010 Bhumip Khasnabish. Do not view, print, forward, and save the content
of this email if you are not the intended recipient of the communiqué.


_______________________________________________
clouds mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/clouds