>>> Randy Turner <rturner at sharplabs.com> 04/28 12:20 AM >>>
> <snip>
>>I would add two other possible options...others on the DL are welcome to
>chime in with their own options.
>>4) Do nothing (for now). Deploy IPP 1.0 and let real world requirements
>start accumulating. I really prefer this option, since I think we are
>REALLY jumping the gun with this effort. With recent comments on the DL, =
I
>think its very important that we concentrate on getting IPP 1.0 "out the
>door" and deployed. We shouldn't appear to be splintering our focus. I do
>think we need to consider notifications for IPP, but beyond that I would
>say any presumptions on our part about what else is "needed" by customers
>is very premature.
I have benefited from this discussion about MIB access, management, =
submission,
SDP, etc. but I too sincerely hope that none of this discussion defocuses =
us from
getting IPP/1.0 out the door and widely deployed. I don't get the feeling =
from this
discussion that "we have done the wrong thing with IPP/1.0" or "we have =
painted
ourselves into a corner". I get the feeling that there is good debate =
going on about
the future relationships of various things that sometimes start to =
overlap. The discussion
has been good. =20
My biggest frustration is with the lack of forward motion by the IESG
on IPP/1.0 in a timely manner, but that does not indicated a problem with =
the
concept and model of IPP/1.0. The only comments that I have heard
that cause the IESG any concern seem to come in on the mapping and use=20
of HTTP/1.1.
So I don't necessarily want to "do nothing (for now)", but if that is what
it takes to show solidarity behind what we have done so far, then so be =
it. I
always fall back to: "If you find that you have a widespead, well adopted
protocol that is ubiquitously implemented and deployed and you find it =
difficult
to rev to the next version because of the widespread deployment, you have
done a GOOD thing. It must have been the right thing at the right time to
fill a need." It is much better to grow from simple to complex and meet =
the
real needs of the growth path, not the proposed needs of the proposed
growth path.
Scott