tosca-interop — archive

Interop Guide - What is the Appropriate Track For Now?

From: Paul Lipton <[email protected]>
To: [email protected]
Date: Mon, 14 Jan 2013 20:58:00 -0000

Option 2 also does NOT lead to conflicting normative standards documents because the Interop Guide (don’t even call it a WD) has no standing. You can upload all the normative stuff you want into Kavi (and we have done so in the past). In terms of OASIS standards, it doesn’t mean anything. Use it to implement something related to TOSCA, if it makes you happy, but make no claims relative to the Interop Guide, of course. Make your claims regarding the spec, which is normative. As per your question below, Doug, your point is well-taken. As with any other bug/issue/improvement in the spec, the Interop SC will need to open JIRA issues for any changes to the spec that it wishes to recommend. The process would be no different than what we did for Spec v1. I would recommend the Interop SC first open JIRA bug issues that do not change the function or scope of the spec as soon as they can. They could probably be considered for a non-material change to Spec v1, or later in a v1 errata, or at least put into the first v.next CSD that way. Enhancements and new material such as BASH script stuff should be put in a JIRA issue when the Interop SC a little later, but before the “pipeline” for v.next is empty again, no doubt. Thanks, Paul From: [email protected] [mailto:[email protected]] On Behalf Of Doug Davis Sent: Monday, January 14, 2013 3:28 PM To: [email protected] Subject: RE: [tosca-interop] Re: Interop Guide - What is the Appropriate Track For Now? Option 1 is the only one presented that doesn't lead us to conflicting normative documents. If the spec is missing something, which is implied when people say the guide currently contains stuff needed in order to achieve interop, then open a new bug report and let's fix it. This is no different than if I noticed something missing from the spec today by just reading it and wanted to get it fixed - the fact that it was found as part of the development of the interop guide should be irrelevant to how it gets resolved in the spec. Question: for each normative statement in the guide, is there a bug report for it? If not, why not? If so, let's get it resolved and propose an v.errata or v1.next be published at the same time as the interop guide. I don't see why this would impact interop or usefulness of the interop guide. thanks -Doug ________________________________________________________ STSM Standards Architect IBM Software Group (919) 254-6905 IBM 444-6905 [email protected] The more I'm around some people, the more I like my dog. "Lipton, Paul C" ---01/14/2013 02:31:21 PM---Doug, I'm merging in Thomas's question and my response below, as the thread accidently got split. From: "Lipton, Paul C" < [email protected] > To: Doug Davis/Raleigh/IBM@IBMUS, Cc: " [email protected] " < [email protected] >, "Simon D Moser ( [email protected] )" < [email protected] >, Matt Rutkowski/Austin/IBM@IBMUS, "Probst, Richard ( [email protected] )" < [email protected] > Date: 01/14/2013 02:31 PM Subject: RE: [tosca-interop] Re: Interop Guide - What is the Appropriate Track For Now? Sent by: < [email protected] > Doug, I’m merging in Thomas’s question and my response below, as the thread accidently got split. We are on the same page in just about every way. I’m fine with normative things going into the spec and agree that is the ONLY place for normative content. It’s simple. If normative things belong in the spec and only the spec; either v1, v1.errata (limited to a narrow set of corrections), or v.next (v2), then don’t produce a Committee Note that contains normative things. The current Interop Guide appears to have normative things and is not the TOSCA spec. As Doug says, that’s bad. So, our choices are simple: 1. Take the normative things (all of them) out of the Interop Guide (might reduce usefulness, but I have no objection) 2. Keep the Interop Guide at the WD level until v.next starts. Do not position the current WD or advance it as a Non-Standards Track work product (CND) in any fashion. When v.next begins, put the normative stuff in the spec and advance the v.next spec, as we normally do. Note: a. There are no functional problems with this. Implementers inside or outside the TC can access the current document by using the public URL provided by Kavi until v.next begins. b. Because normative stuff with standing belongs in the spec (as Doug said) and a CN, which is essentially intended for marketing material and high-level whitepapers, is the wrong track, we take care to keep our normative stuff where it belongs, in the spec (as per Doug). c. A non-normative Interop/Best Practices guide becomes a separate consideration, at that point. Thanks, Paul From: [email protected] [ mailto:[email protected] ] On Behalf Of Doug Davis Sent: Monday, January 14, 2013 2:04 PM To: Lipton, Paul C Cc: [email protected] ; Simon D Moser ( [email protected] ); Matt Rutkowski; Probst, Richard ( [email protected] ) Subject: [tosca-interop] Re: Interop Guide - What is the Appropriate Track For Now? Paul, there are a couple of different topics here, IP vs normative text. I won't touch the IP one because I don't really think that's relevant to what's the main point, which is whether a scenario doc is a 'spec' or more like a 'white paper'. IMO, anything normative about TOSCA goes into the spec - period. If its too late for the current release then it goes in the next one. If we can't wait for a full release then there's an errata process. Creating a "sibling spec" for "things we didn't get into the real spec" is going to cause endless confusion since you will immediately have conflicts. For example, if something isn't mandated in the spec, but it is mandated in the 'sibling spec' then that's a conflict since people are 100% compliant with the spec if they don't support those mandated pieces - after all, they followed _the_ spec. When people say they support tosca v1.0 are they supporting "v1.0" or "v1.0+sibling spec" ? Its going to be a mess. This isn't rocket science and we've done this before (think WS* specs/processes). I don't see the need to think of this as something new or special - just follow the normal process. Its really very simple. As we do our interop testing, and coding, if people find issues we can open a new bug with the TC. We'll discuss it and as part of the resolution we'll decide whether it should go into v2 or v1.next. Then at some point someone will propose to release a new "spec" - whether that's v2, or v1.next or an errata is something they (and the tc) will decide at that point based on which issues are resolved, which need to be visible immediately, etc... thanks -Doug ________________________________________________________ STSM Standards Architect IBM Software Group (919) 254-6905 IBM 444-6905 [email protected] The more I'm around some people, the more I like my dog. "Lipton, Paul C" ---01/14/2013 01:02:59 PM---Hi all, Matt suggested we take this Interop SC discussion offline due to lack of time. Here's my co From: "Lipton, Paul C" < [email protected] > To: " [email protected] " < [email protected] >, Cc: "Simon D Moser ( [email protected] )" < [email protected] >, Matt Rutkowski/Austin/IBM@IBMUS, "Probst, Richard ( [email protected] )" < [email protected] >, Doug Davis/Raleigh/IBM@IBMUS Date: 01/14/2013 01:02 PM Subject: Interop Guide - What is the Appropriate Track For Now?