1 / 8

Considerations on Interoperability & C.

Considerations on Interoperability & C. Franco Travostino travos@nortel.com Area Director, Infrastructure. I wrote software and want it to be …. Interoperable Property of being functional equivalent or interchangeable with another within a given context Conformant

tammy
Download Presentation

Considerations on Interoperability & C.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Considerations on Interoperability & C. Franco Travostino travos@nortel.com Area Director, Infrastructure

  2. I wrote software and want it to be … • Interoperable • Property of being functional equivalent or interchangeable with another within a given context • Conformant • When it is shown to adhere to requirements specified in a document • Without conformance, “interoperable” can mean “bug-compatible”, especially within a small crowd • Certified • Someone hands me a ribbon that is a widely recognized proof that I’ve passed some evaluation [ Compliant ] • Most often used for regulatory compliance, with clear, legally-binding accountabilities, for processes (e.g., Sarbanes-Oxley) or complete engineering artifacts (e.g., a car's emission gas test in my state)

  3. Example: Connectathon™ (1986) • Network proving ground for multi-vendor interoperability • Sun established it for NFS • Yearly event ever since, broader scope • “Connectathon is a place where engineers can gather without marketing hype”

  4. Example: AT&T SVID (1986) • Unix™ System V Interface Definition • Precursor of POSIX, held key to Unix conformance • Documents and companion test suite for conformance • Its being owned by a vendor was controversial (enter the “unix wars”) • BSD, X/Open, OSF, etc.

  5. Example: IETF process (1986?) • The IETF Standards Process requires at least two independent and inter-operable implementations for advancing a protocol specification to Draft Standard • IETF doesn’t run interoperability events • E.g., UNH’s InterOperability Lab host some of them. In this case, Academia brings depth, super-partes reputation, and persistent, funded facilities • “Implementation Reports” fed onto IESG and published • “Note that this is NOT a list of endorsements. Nor should it be assumed that the list is all inclusive. Indeed, there may be many more implementations.”

  6. Decision Points for GGF • What-to • JSDL, GridFTP, BES, Byte IO, etc. • for interoperability and/or conformance • Where-to • GGF actively managing events set in time and space • Or hands-off implementation reports a la IETF • When-to • Aggressive testing can lead to premature ossification! • How-to • Present experimental outcomes • And whether to award certifications to those who pass muster

  7. Further Thoughts • The breadth and novelty of GGF material may warrant a multi-pronged approach • Implementation reports a la IETF, 365 days/yr • Plus, hosting of “OGSA-thon” events, once or twice a year • In either case, locus of testing should best matched to the material • E.g., GridFTP is game for UNH’s IOL, Data Area’s work for SNIA, etc. • Testing from basement, dorm room, Starbucks considered valuable too • Learn impact NATs/FW/middleboxes if any … if skype works why can’t I? • GGF leadership (Chairs, ADs) must be leery of “ossification” effects • Implementation reports seen as necessary but not sufficient to advance Proposed Standards • Overhead of certifications considered harmful?

  8. My Bias (any hat off) — cont’d • I disagree with the text currently in GFD.53 (OGSA Roadmap) 2.3     OGSA BrandingGiven the requirement for consistency across OGSA specifications and other documents, GGF defines in [OGSA-Related Naming Guidelines] the criteria to be used in determining whether to brand entities such as working groups and documents with an OGSA prefix. The OGSA normative documents are expected to be implemented by multiple open-source software (OSS) projects and commercial software vendors. Authors of OGSA Software may claim one of three levels of agreement with the OGSA normative documents:1.      A claim to implement a specification or profile is a statement of “best effort” to satisfy the requirements of the specification.  There are no test mechanisms to guarantee the correctness of the implementation.2.      A claim of conformance to a specification or profile is a statement of intent to interoperate with other conformant implementations.  Two or more implementations may test their conformance by testing how well they interoperate. A conformance claim mechanism as defined in the profileshould be used to communicate conformance.3.      A claim of compliance would imply acceptance by a set of OGSA Compliance Tests. At the time of writing no such tests exist. We may expect that OGSA compliance tests will be developed that define the practical criteria that must be satisfied for a software system to be called “OGSA-compliant.”  Until such a suite is available, claims of OGSA compliance should not be made.

More Related