Re: iCAP, OPES and the IETF

OPES has had two BoFs already with no IESG action. As far as I can tell, 
the IESG is more interested in shutting groups down in the apps area at the 
moment. By "unlikely in the near future", I therefore mean "in time to have 
a WG meeting at London".
Buts lets try to separate the two issues (as Ian did somewhat better than I).

Documenting iCAP v1.0 as Information now has zero impact on OPES. OPES is 
still free, as the charter states, to examine iCAP and determine if 
development of iCAP is the appropriate path for OPES services. (It may or 
may not be - that is for the WG to decide).
So, even if OPES is chartered before London, I think we still need to 
submit  iCAP v1.0 as Informational. I have not yet seen any compelling 
argument not to do this.
John

At 10:40 AM 05/06/01 -0700, Michael W. Condry wrote:
> John-
> Why do you say that the creation of OPES is "unlikely in the near future?"
>
> What is the data that supports this?
>
> Michael
> At 06:09 PM 6/5/2001 +0200, John Martin wrote:
> > Markus,
> >
> > First let me make one thing clear: the additions we made were those that 
> > were made on various mailing lists, including ietf-openproxy and were 
> > mostly involving two things: fixing actual bugs in the text (and 
> > examples) and fixing the text (where it was sometimes obvious that there 
> > were multiple, different authoring styles, for example).
> > So, this new edited version is simply an update of the existing draft 
> > which fixes some more of the bugs in that document (and which will of 
> > course be widely distributed for comment before being sent to the RFC 
> > editor - sorry if that wasn't implicit in what I said).
> > I do indeed want to see iCAP further developed and yes,I agree that an 
> > IETF working group is the appropriate place for this to happen. That is 
> > completely separate to documenting what already exists as 
> > "Informational". (If for no other reason than version 1.0 is not going to 
> > change significantly now that it has been implemented). I just want a 
> > fixed spec which we agree to code to and I have got the feeling that we 
> > were at a convergence point with the current version.
> > The problem is that today, no such group exists and isn't likely to in 
> > the near future: OPES has had its two BoFs, for example and so has some 
> > hoops to jump through if it is to be chartered. I'm not even sure that 
> > OPES would be the correct group since its charter is much wider than the 
> > scope of iCAP...?
> > Some specific points below:
> > At 10:50 AM 05/06/01 -0400, Markus Hofmann wrote:
> > > John,
> > >
> > > > At the moment, however, we have a specification which is still fluid and
> > > > for coding purposes, this is not acceptable.
> > >
> > > Agreed. So let's work together - within the IETF - to make sure that
> > > we quickly get a stable and well-accepted iCAP version, which will NOT
> > > be a standalone protocol approach, but will also integrate into a more
> > > complete protocol framework.
> > There is now "within the IETF" right now so the best way to proceed, in 
> > my opinion, is to submit what has already been agreed and to move on. If 
> > that means a version 2.0 produced within WG XYZ, fine. At least in the 
> > short term we have something to code to.
> > Note that by "short term", I mean a few months, not a few years.
> >
> > > > For this reason, a few of us got together in order to go over the 
> > > existing
> > > > document and produce something we could nail down and publish.
> > >
> > > Did you attach a version of or include a pointer to the updated
> > > document? I would expect that you solicit comments and feedback from
> > > the networking community before even considering submission as RFC -
> > > that would not only be fair to the "large number of people" that
> > > "developed, improved dramatically and made [iCAP] real due to the
> > > hard", but would allow anybody in helping to make the specification
> > > even better and stronger.
> > Again apologies that I didn't make this clearer: yes, we'll send out the 
> > draft for comments before it is submitted to the RFC editor.
> > > > Note that this does not preclude further development of iCAP. In fact, I
> > > > would argue that setting a 1.0 in stone as an Informational (or
> > > > Experimental) RFC gives us a clean slate from which to continue 
> > > rather than
> > > > falling into the creeping featurism trap. I would hope that this
> > > > development will take place within the *standards process* of the 
> > > IETF but
> > > > since there is no appropriate working group there at the moment, I cannot
> > > > predict what will happen.
> > >
> > > I completely agree with you on the following issues:
> > >
> > > (a) iCAP should be further developed and get set in stone within
> > >     the IETF - this ensures that it will NOt be a standalone
> > >     aprroch, but will fit into an overall protocol framework.
> > Great.
> >
> > > (b) Further development and standardization of iCAP should take
> > >     place within an IETF WG, and NOT aside as submission from
> > >     a few individuals.
> > Agree. By "further development" I mean a version *after* the current one, 
> > though. The current one is pretty static with regards functional 
> > specification; it is just the documentation that was broken.
> > > (c) We need to get the appropriate WG that covers iCAP official.
> > >     iCAP perfectly fits into the OPES framework, iCAP is on the
> > >     OPES charter, so let's work together to make it happen and
> > >     get OPES official (together with the IESG, our ADs, etc, of
> > >     course). We would then have the appropriate WG to take on
> > >     the iCAP issue.
> > I don't disagree with you but I suspect that the IESG will want to make 
> > that decision. I do not want to tie iCAP to a group that doesn't exist; 
> > on the other hand, I am pretty happy if iCAP can be further developed 
> > within a group that does exist.
> > > > With regards iCAP and ECMA it is very simple. We will also submit iCAP to
> > > > ECMA. The version submitted will be identical to that finally 
> > > published by
> > > > the RFC editor (i.e. after integrating corrections from either the RFC
> > > > editor or the IESG, to whom the RFC editor may defer).
> > >
> > > What's the reason for submitting to two different standards bodies? I
> > > cannot see how this should benefit the networking community. I'm
> > > mostly concerned that - although starting as identical - both versions
> > > will evolve into different flavors of iCAP. How do you want to make
> > > sure that the iCAP versions of both standards bodies will stay
> > > identical? To which version should a vendor implement? Vendors would
> > > probably end up with havinf to implement both flavors - and that's
> > > exactly what we want to avoid by standardizing protocols (well, one
> > > might argue that the nice thing about standards is the "s" :) But,
> > > having two different "standardized" versions of iCAP is certainly not
> > > of interest to the networking community!
> > I don't believe this will happen. The version submitted to ECMA will be 
> > the version that is published by the RFC editor. In my opinion, the 
> > former takes precedence. If ECMA produces an incompatible spec - which 
> > I'm sure it wont - then that is no longer "iCAP 1.0" but something else. 
> > We (NetApp) will work very hard to ensure that doesn't happen.
> > > So, I'm looking forward to your contributions to the IETF/OPES effort
> > > and to seeing you at the OPES Workshop this Wednesday. I'm sure you'll
> > > provide some valuable input.
> > I will not be at the OPES workshop this Wednesday - its a 12 hr flight 
> > for me -  but some folks from NetApp will be. If there is dial-in 
> > facilities, I can try to call in.
> > Rgds,
> > John
> > ---------------------------------------------------------------
> > Network Appliance           Direct / Voicemail: +31 23 567 9615
> > Kruisweg 799                               Fax: +31 23 567 9699
> > NL-2132 NG Hoofddorp               Main Office: +31 23 567 9600
> > ---------------------------------------------------------------
> Michael W. Condry
> Director,  Network Edge Technology
---------------------------------------------------------------
Network Appliance           Direct / Voicemail: +31 23 567 9615
Scorpius 2                                 Fax: +31 23 567 9699
NL-2132 LR Hoofddorp               Main Office: +31 23 567 9600
---------------------------------------------------------------