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

From: Bhumip Khasnabish <[email-masked]>
Date: Tue, 25 May 2010 12:33:31 -0400

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:+001-781-752-8003, [email-masked])

© 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é.

---

From: Mark Carlson <[email-masked]>
Date: Tue, 25 May 2010 10:45:45 -0600

Bhumip,

Not sure why you are doing this. The information you need is largely already
available on 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_Interface_%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 
<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

*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?csnumber=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

[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.
> Bhumip Khasnabish (Mobile:+001-781-752-8003, [email-masked] 
> <mailto:[email-masked]>)
>
> © 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clouds
>

---

From: Mark Webb <[email-masked]>
Date: Tue, 25 May 2010 13:06:28 -0400

I think the cloud-standards.org wiki is a fine effort.  Ad-hoc and  
informal, but with fine goals.

However, it doesn't capture the full picture or all significant SDO  
and forum working on cloud related standards and profiles.  TMF (very  
important IMO) and ITU-T cloud working group, (less significant now  
but carries weight) are two that are not on this site.

There is work to be done IMO.

Mark Webb

On May 25, 2010, at 12:45 PM, Mark Carlson wrote:

> an entry describing their cloud work, and they use a standard  
> template already
> 1. The name of the specification
>
> 2. A short statement (<100 words) of the purpose and function of the  
> specification The SNIA Cloud Data Management Interface (CDMI) is the  
> 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.
>
> 4. If the specification is part of a group of explicitly related  
> 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
>
> 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
>
> 14. URI for the SDO's posting location, (if any) for notices from  
> under number 15. SNIA 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).
>
> 17. A list (or URI pointer to same) of the other specifications*  
> that are normatively referenced in the specification.
>
>
> dates and times", ISO 8601:20044 - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874
>
> 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. Key words for use in RFCs to Indicate  
> Requirement Levels - http://www.ietf.org/rfc/rfc2119.txt
>
> [RFC2045] IETF RFC 2045. Multipurpose Internet Mail Extensions  
> (MIME) Part One: Format of Internet Message Bodies - http://www.ietf.org/rfc/rfc2045.txt
>
> [RFC2578] IETF RFC 2578. Structure of Management Information Version  
> 2 (SMIv2) - http://www.ietf.org/rfc/rfc2578.txt
>
> [RFC2616] IETF RFC 2616. Hypertext Transfer Protocol -- HTTP/1.1 - http://www.ietf.org/rfc/rfc2616.txt
>
> [RFC3280] IETF RFC 3280. Internet X.509 Public Key Infrastructure  
> Certificate and Certificate Revocation List (CRL) Profile - http://www.ietf.org/rfc/rfc3280.txt
>
> [RFC3530] IETF RFC 3530. Network File System (NFS) version 4  
> Protocol - http://www.ietf.org/rfc/rfc3530.txt
>
> [RFC3986] IETF RFC 3986. Uniform Resource Identifier (URI): Generic  
> Syntax - http://www.ietf/org/rfc/rfc3986.txt
>
> [RFC4346] IETF RFC 4346. The Transport Layer Security (TLS) Protocol  
> Version 1.1 - http://tools.ietf.org/rfc/rfc4346.txt
>
> [RFC4627] IETF RFC 4627. The application/json Media Type for  
> JavaScript Object Notation (JSON) - http://www.ietf.org/rfc/rfc4627.txt
>
> [RFC5246] IETF RFC 5246. 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).
>
> Algorithms", Chapter 16, August 1993, http://www.repairfaq.org/filipg/LINK/F_crc_v3.html
>
> Syntax, Version 1.0, June 1999. Specification and Technical  
> Corrigendum - http://www.rsa.com:80/rsalabs/node.asp?id=2138
>
> [REST] "Representational State Transfer" - http://www.ics.uci.edu/~fielding/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.
>

---

From: Bhumip Khasnabish <[email-masked]>
Date: Tue, 25 May 2010 13:15:49 -0400

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 <[email-masked]>wrote:

> 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.*
>
> *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
>
> *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)
>
> 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
>
>
> applicable to development and use of the specification.* SNIA IP Policy<http://www.snia.org/about/corporate_info/ip_policy/>
>
> 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
>
> *17. A list (or URI pointer to same) of the other specifications* that are
> normatively referenced in the specification. *
>
>
> interchange formats -- Information interchange -- Representation of dates
> and times", ISO 8601:20044 -
> 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
>
> [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) -
> 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
>
> *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,
> [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>
>
> the specification may (speculatively) interoperate or act in complementary,
> compatible fashion. *
>
> OCCI - see OGF entry.
>
> clouds mailing [email-masked]://www.ietf.org/mailman/listinfo/clouds
>
>

-- 
Best Regards.

---

From: Bhumip Khasnabish <[email-masked]>
Date: Tue, 25 May 2010 13:17:30 -0400

Thanks a lot Mark (M. Webb) and I agree.

Best.
Bhumip

On Tue, May 25, 2010 at 1:06 PM, Mark Webb <[email-masked]> wrote:

> However, it doesn't capture the full picture or all significant SDO and
> forum working on cloud related standards and profiles.  TMF (very important
> IMO) and ITU-T cloud working group, (less significant now but carries
> weight) are two that are not on this site.
>

-- 
Best Regards.

---

From: "Carl Williams" <[email-masked]>
Date: Tue, 25 May 2010 13:28:07 -0400

Hi Mark,

  I agree with you and support a “Gap Analysis” that should be published in
internet-draft form.

Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark Webb
Sent: Tuesday, May 25, 2010 1:06 PM
To: [email-masked]
Subject: Re: [clouds] Clouds SDO gap analysis template (a Table)

I think the cloud-standards.org wiki is a fine effort.  Ad-hoc and informal,
but with fine goals.

Mark Webb

Bhumip,

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

Cloud Standard

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

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 

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 

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 

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 

[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 

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. 

-- mark

Dear All,

Best Regards.

Bhumip

---

From: Mark Carlson <[email-masked]>
Date: Tue, 25 May 2010 11:49:02 -0600

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:
> 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.
> On Tue, May 25, 2010 at 12:45 PM, Mark Carlson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Bhumip,
>
>     available on http://cloud-standards.org
>     <http://cloud-standards.org/> wiki. Each SDO has already created
>     *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.*
>
>     *5. URI for the normative text of the specification
>     *http://www.snia.org/tech_activities/standards/curr_standards/cdmi
>     specification. *Storage Networking Industry Association
>
>     *7. URI for the SDO* http://snia.org <http://snia.org/>
>
>     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
>
>     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
>
>     *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/>
>
>     participants or individuals regarding claims under the rules
>     stated under number 15.* SNIA IP Policy
>     *15. Interoperability, conformance, or certification test activity
>     for the specification (by owner name or URI). *
>
>     None
>
>     *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 -
>     [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 -
>     [RFC2119] IETF RFC 2119 <http://tools.ietf.org/html/rfc2119>. Key
>     words for use in RFCs to Indicate Requirement Levels -
>     [RFC2578] IETF RFC 2578 <http://tools.ietf.org/html/rfc2578>.
>     Structure of Management Information Version 2 (SMIv2) -
>     [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 -
>     application/json Media Type for JavaScript Object Notation (JSON)
>     - http://www.ietf.org/rfc/rfc4627.txt
>
>     *18. A list (or URI pointer to same) of the other specifications*
>     under number 17). *
>     <http://www.rsa.com/rsalabs/node.asp?id=2138>
>
>     *19. A list (or URI pointer to same) of other specifications* with
>     *20. A list (or URI pointer to same) of other specifications*
>     similar to this specification. (Whether or not substitutable.) *
>
>     None.
>
>>     Attached please find a template (a Table) that can be utilized
>>     for Clouds SDO gap analysis.
>>     © 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é.
>>
>>
>>     [email-masked]  <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Sam Johnston <[email-masked]>
Date: Tue, 25 May 2010 20:17:33 +0200

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 <[email-masked]> wrote:

>> of data and individual data elements. The functional interface allows CRUD
>> Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet
>> Message Bodies - http://www.ietf.org/rfc/rfc2045.txt
>>
>> http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm<http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm>
>>

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 27 May 2010 00:58:25 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Sam Johnston
Sent: Tuesday, May 25, 2010 1:18 PM
To: Mark Carlson
Cc: [email-masked]
Subject: Re: [clouds] Clouds SDO gap analysis template (a Table)

Bhumip/Mark,

Sam

Thanks,

-- mark

Dear Mark,

Thanks again.

Best.

Bhumip

On Tue, May 25, 2010 at 12:45 PM, Mark Carlson <[email-masked]>
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.

Cloud Standard

SOURCE 

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

SUBJECT 

OPTIONAL 

Final standard 

None 

OCCI - see OGF entry. 

None. 

-- mark 

Dear All,

Best Regards.

Bhumip

-- 
Best Regards.

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 27 May 2010 10:02:37 +0300

Hi Linda, 

Two minor items that come to my mind. 

1) "Cloud Computing" is largely a marketing term. Many of us (including me) are not good in marketing. For discussions it therefore helps to translate the cloud terminology into something that many of us understand. 

2) Keeping up with all the "cloud" work is in some sense quite easy to do. Why? It seems that most organizations just look around what other SDOs are doing and try to figure out what cloud computing actually means.

We typically try to work on well-defined scoped work (see all the working group charters). Some SDOs have taken a different approach and that's fine as well. So far, I have not seen anyone proposing detailed *technical* work. I am looking forward to see technical contributions from Sam (in the mail thread below) and others. 

In starting new work there are additional aspects to consider (beyond what http://tools.ietf.org/html/rfc5434 says), namely:

1) Are there deployed solutions available that require standardization? (Not everything requires interoperability.) Bringing work to the IETF that has found acceptance in the marketplace already offers some advantages over starting with a clean slate. 

2) Do those companies producing whatever solutions (such as virtualization, etc.) demand that their work gets standardized? If not, then the outcome of standardization will have a hard time to find acceptance. 

Ciao
Hannes

PS: Just something to think about. When I helped to bring OAuth to the IETF nobody was talking about cloud computing. It was just about delegated authentication on the Internet. Now, a year later some people refer to the very same use cases but use the term "cloud" somewhere in the description even though nothing has changed compared to last year from a technical point of view. 

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Linda Dunbar
	Sent: 27 May, 2010 08:58
	To: 'Sam Johnston'; 'Mark Carlson'
	Cc: [email-masked]
	Subject: Re: [clouds] Clouds SDO gap analysis template (a Table)

	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: [email-masked] [mailto:[email-masked]] On Behalf Of Sam Johnston
	Sent: Tuesday, May 25, 2010 1:18 PM
	To: Mark Carlson
	Cc: [email-masked]
	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

	
	Thanks,
	
	-- mark

	Dear Mark,

	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. 

	Thanks again.

	Best.

	Bhumip

	On Tue, May 25, 2010 at 12:45 PM, Mark Carlson <[email-masked]> 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.

	Cloud Standard

	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. 

	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 <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 

	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 

	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?csnumber=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. 

	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. 

	
	-- mark 

		Dear All,

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

		Best Regards.

		Bhumip

		
		© 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é.

	

	
	-- 
	Best Regards.

	© 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é.

---

From: Song Haibin <[email-masked]>
Date: Thu, 27 May 2010 17:05:15 +0800

Hi Hannes,

In general, I agree with you. I'm not sure this kind of general gap analysis
between SDOS is helpful or not. How much does it help to determine what
protocol should be developed in IETF?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Thursday, May 27, 2010 3:03 PM
> To: ext Linda Dunbar; Sam Johnston; Mark Carlson
> Cc: [email-masked]
> 1) "Cloud Computing" is largely a marketing term. Many of us (including
me)
> are not good in marketing. For discussions it therefore helps to translate
the
> cloud terminology into something that many of us understand.
> 

I agree with that. A small piece of work that needs interoperability is
always good. "Cloud" means different things to different people.

> 2) Keeping up with all the "cloud" work is in some sense quite easy to do.
> Why? It seems that most organizations just look around what other SDOs are
> doing and try to figure out what cloud computing actually means.
> 

> We typically try to work on well-defined scoped work (see all the working
> group charters). Some SDOs have taken a different approach and that's fine
> as well. So far, I have not seen anyone proposing detailed *technical*
work. I
> am looking forward to see technical contributions from Sam (in the mail
> thread below) and others.
> 

+1

> In starting new work there are additional aspects to consider (beyond what
> http://tools.ietf.org/html/rfc5434 says), namely:
> 
> 1) Are there deployed solutions available that require standardization?
(Not
> everything requires interoperability.) Bringing work to the IETF that has
> found acceptance in the marketplace already offers some advantages over
> starting with a clean slate.
> 

Or you can come up with a concrete problem that industrial world agrees on,
and try to solve it here.

> 2) Do those companies producing whatever solutions (such as
virtualization,
> etc.) demand that their work gets standardized? If not, then the outcome
of
> standardization will have a hard time to find acceptance.
> 
> Ciao
> Hannes
> 
> PS: Just something to think about. When I helped to bring OAuth to the
IETF
> nobody was talking about cloud computing. It was just about delegated
> authentication on the Internet. Now, a year later some people refer to the
> very same use cases but use the term "cloud" somewhere in the description
> even though nothing has changed compared to last year from a technical
> point of view.
> 

I'm reading OAuth stuff these days. Is it widely deployed now? I would like
to get more information about it (privately, not in this thread).

BR,
Haibin

> 	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
> 		From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Sam Johnston
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
> 
> 
> 
sites
> <[email-masked]> wrote:
> 
> 	Bhumip,
> 
<http://cloud-standards.org/>
> wiki. Each SDO has already created
template
> 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.
> 
most
> specifications from the same source, the name of the group of
specifications.
> Not applicable
specification
> as described by the SDO's process. SNIA Architecture (Final Standard)
> 
available. US
> 	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
> 
> 
lifecycle
> 	15. Interoperability, conformance, or certification test activity
for the
> 	17. A list (or URI pointer to same) of the other specifications*
that are
> 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
> 	[RFC2119] IETF RFC 2119 <http://tools.ietf.org/html/rfc2119> . Key
> 	[RFC2045] IETF RFC 2045 <http://tools.ietf.org/html/rfc2045> .
> 	[RFC2578] IETF RFC 2578 <http://tools.ietf.org/html/rfc2578> .
> 	[RFC2616] IETF RFC 2616 <http://tools.ietf.org/html/rfc2616> .
List
> 	[RFC3530] IETF RFC 3530 <http://tools.ietf.org/html/rfc3530> .
> 	[RFC3986] IETF RFC 3986 <http://tools.ietf.org/html/rfc3986> .
> 	[RFC4346] IETF RFC 4346 <http://tools.ietf.org/html/rfc4346> . The
> 	[RFC5246] IETF RFC 5246 <http://tools.ietf.org/html/rfc5246> . The
that are
> Syntax, Version 1.0, June 1999. Specification and Technical Corrigendum -
> <http://www.ics.uci.edu/%7Efielding/pubs/dissertation/rest_arch_style.htm
> >
> 
which
> the specification may (speculatively) interoperate or act in
complementary,
> 	20. A list (or URI pointer to same) of other specifications* similar
to this
> the content of this email if you are not the intended recipient of the
> communiqué.
> 
>

---

From: Mark Webb <[email-masked]>
Date: Thu, 27 May 2010 09:16:33 -0400

Linda,

In principle I think you have a good point that I agree with in the  
longer term.  I think if the IETF community wants to be relevant to  
whatever cloud computing is, then the group needs to find something  
within the scope of IETF _and_ not already being worked by some other  
SDO or forum where a significant contribution, (job to be done,  
problem to be solved) needs to be made.

I see the "gap analysis" as only a means to that end, (identify a real  
concrete problem & potential solution in need of standardization at  
this point in time for cloud).

Keeping all possible outcomes in play also means to me that IETF may  
have no _significant_ new cloud value at this snapshot in time, (as  
unpopular as that may be).

Mark Webb

PS: with the understanding that individuals, groups, organizations  
will shop SDOs for path of least resistance for their own benefit.

On May 27, 2010, at 1:58 AM, Linda Dunbar wrote:

> 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
> 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 Tue, May 25, 2010 at 12:45 PM, Mark Carlson <[email-masked] 
> > wrote:
> Bhumip,
>
> dates and times", ISO 8601:20044 -http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874
>
> Requirement Levels -http://www.ietf.org/rfc/rfc2119.txt
>
> (MIME) Part One: Format of Internet Message Bodies -http://www.ietf.org/rfc/rfc2045.txt
>
> JavaScript Object Notation (JSON) -http://www.ietf.org/rfc/rfc4627.txt
>
> Algorithms", Chapter 16, August 1993,http://www.repairfaq.org/filipg/LINK/F_crc_v3.html
>

---

From: Gene Golovinsky <[email-masked]>
Date: Thu, 27 May 2010 08:27:13 -0500

Mark and all.

One of the areas where I am convinced Cloud can benefit from IETF efforts is logging.
As I mentioned a few months ago "Auditability" for any Cloud infrastructure and applications either does not exist at all or in its enfancy.
CloudAudit is making very good progress towards some aspects of "Auditability", but it is mostly geared towards identifying and locating appropriate compliance documents in the defined namespace.
I have in mind logging Syslog style. The content of the logs for the Cloud should be different from your traditional server, router, switch log since the managed entity itself is obfuscated in the cloud.
This leads to almost impossible forensics and compliance objectives unless Cloud participating entity logs information consistently and in interoperable manner.

I'll be sending high level proposal soon. I believe it will be specific enough and complimentary to CloudAudit efforts.

--Gene

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Webb
Sent: Thursday, May 27, 2010 8:17 AM
To: Linda Dunbar
Cc: [email-masked]
Subject: Re: [clouds] Clouds SDO gap analysis template (a Table)

Linda,

In principle I think you have a good point that I agree with in the longer term.  I think if the IETF community wants to be relevant to whatever cloud computing is, then the group needs to find something within the scope of IETF _and_ not already being worked by some other SDO or forum where a significant contribution, (job to be done, problem to be solved) needs to be made.

I see the "gap analysis" as only a means to that end, (identify a real concrete problem & potential solution in need of standardization at this point in time for cloud).

Keeping all possible outcomes in play also means to me that IETF may have no _significant_ new cloud value at this snapshot in time, (as unpopular as that may be).

Mark Webb

PS: with the understanding that individuals, groups, organizations will shop SDOs for path of least resistance for their own benefit.

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

Bhumip/Mark,

Sam

On 25 May 2010 19:49, Mark Carlson <[email-masked]<mailto:[email-masked]>> 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

Thanks again.

Best.

Bhumip

On Tue, May 25, 2010 at 12:45 PM, Mark Carlson <[email-masked]<mailto:[email-masked]>> 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.

SOURCE

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

SUBJECT

OPTIONAL

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/>

None

[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?csnumber=40874

[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

[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>

OCCI - see OGF entry.

None.

-- mark

Best Regards.
Bhumip

Bhumip Khasnabish (Mobile:+001-781-752-8003, [email-masked]<mailto:[email-masked]>)

clouds mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
clouds mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clouds

--
Best Regards.

Bhumip Khasnabish (Mobile:+001-781-752-8003, [email-masked]<mailto:[email-masked]>)

_______________________________________________
clouds mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clouds

_______________________________________________
clouds mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/clouds

---

From: Mark Carlson <[email-masked]>
Date: Thu, 27 May 2010 07:44:41 -0600

+1 to this. This is a great example of where IETF can aid the cloud efforts.
The cloud efforts at the various SDOs always look for other existing 
standards
to leverage. CDMI, for example, references 
<http://cdmi.sniacloud.com/cdmi_spec/2-references/2-references.htm> no 
fewer than 10 existing IETF RFCs.
SNIA recently embarked on an effort to add more interoperable auditing 
to CDMI
and would readily reference the IETF work if it incorporated the 
requirements of
data and storage management.

-- mark

On 5/27/10 7:27 AM, Gene Golovinsky wrote:
> As I mentioned a few months ago "Auditability" for any Cloud 
> infrastructure and applications either does not exist at all or in its 
> enfancy.
>
> CloudAudit is making very good progress towards some aspects of 
> "Auditability", but it is mostly geared towards identifying and 
> locating appropriate compliance documents in the defined namespace.
>
> I have in mind logging Syslog style. The content of the logs for the 
> Cloud should be different from your traditional server, router, switch 
> log since the managed entity itself is obfuscated in the cloud.
>
> This leads to almost impossible forensics and compliance objectives 
> unless Cloud participating entity logs information consistently and in 
> interoperable manner.
>
> I'll be sending high level proposal soon. I believe it will be 
> specific enough and complimentary to CloudAudit efforts.
>
> --Gene
>
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Mark Webb
> *Sent:* Thursday, May 27, 2010 8:17 AM
> *To:* Linda Dunbar
> *Cc:* [email-masked]
> *Subject:* Re: [clouds] Clouds SDO gap analysis template (a Table)
>
> Linda,
>
> 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:* [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Sam Johnston
> *Sent:* Tuesday, May 25, 2010 1:18 PM
> *To:* Mark Carlson
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [clouds] Clouds SDO gap analysis template (a Table)
>
> Bhumip/Mark,
>
> 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
>
> *9. The language or languages in which the specification is available. 
> *US English
>
>
>     SUBJECT
>
> *11. Does the standard address both functional and management aspects 
> of the service?* Yes. Management is done by setting metadata on 
> lifecycle taxonomy:*
> applicable to development and use of the specification.* SNIA IP 
> Policy <http://www.snia.org/about/corporate_info/ip_policy/>
>
> the specification (by owner name or URI).*
>
> None
>
> are normatively referenced in the specification.*
>
>
> dates and times", ISO 8601:20044 
> -http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=40874
>
> words for use in RFCs to Indicate Requirement Levels 
> -http://www.ietf.org/rfc/rfc2119.txt
>
> Internet Message Bodies -http://www.ietf.org/rfc/rfc2045.txt
>
> -http://www.ietf.org/rfc/rfc4627.txt
>
> are referenced in the specification (except the ones listed under 
> number 17).*
>
> Algorithms", Chapter 16, August 
> 1993,http://www.repairfaq.org/filipg/LINK/F_crc_v3.html
>
> 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 content of this email if you are not the intended recipient of
>     the communiqué.
>
>       
>