> How long does an IESG ballot take? When would it be done?
IESG normally meets every other Thursday. Our last meeting was yesterday.
IPP should be formally discussed by IESG in either two or four weeks' time.
(Normally it would just be two weeks, but these are long documents.)
Up until this point, IESG has been waiting until I could recommend
the documents to it; and until recently I was waiting for the revisions
in response to my suggestions for changes. (IESG won't ballot the
document unless/until the AD in charge of the working group recommends
that it do so.)
> Isn't there some IESG expert that can bless this proposal now, so that we can
> discuss it and put it in our documents?
>> I'm afraid that the WG is running out of patience with this prolonged
> process and I'm trying to see how we can work out a technical solution.
> Can't you forward the ipp scheme proposal to some experts for review
> now to see if it is acceptable and correct?
With all due respect, there's a shortage of patience on both sides,
and the "other side" includes a number of IESG and IAB folks.
*I'm* the expert. The rest of IESG would prefer to avoid reading the
IPP documents; they'd far rather trust my judgement and vote "No Objection"
But a strong objection from any IESG member can cause the process to
take a lot longer. But my opinion is irrelevant, as is the opinion of
other experts, if there's strong objection from other IESG members
who have read the documents.
I personally think the overall proposal to use ipp: is sound and
reasonably detailed, but the solution to allow both ipp: and http:
in IPP protocol elements is marginal. I'd like the proposal better
if it said "clients and servers SHOULD use ipp: URLs in IPP protocol
elements".
The proposal would be stronger if it provided some justification for
using http: in IPP protocol elements at all. It should also
explain why using http: when talking to proxies isn't an attempt
to subvert a site's firewall security policy. It probably needs
to describe a common case where talking directly to the server's
IPP port doesn't work, and the reason it doesn't work is something
other than "access to the IPP port is turned off at the firewall".
My opinion is irrelevant, as is the opinion of other experts,
if there's strong objection from other IESG members to any use
of http: in IPP protocol elements.
It's not like this is the only problem with the documents. If past
history is any guide, it's going to be an tough sell for me to
talk the rest of IESG into letting IPP get away with "SHOULD implement"
TLS, but I agreed that I would make that pitch. And I seem to recall
(I don't have the document in front of me) that IPP refused to add
the security considerations text regarding downloadable drivers -
I'm not the only one on IESG who cares about such things. And
it's always possible that IESG folks will find other things to object to.
But at this point I think it's to the point that I can should it to
IESG, let them comment on it and recommend changes, and have the
IPP editors do at most one more pass. Assuming, of course, that
IPP is willing to make the changes that IESG requests.
The IPP group's work (at least on these documents) is 99% done. It
mostly remains for me to sell the work to the IESG. But because this
group has generated a fair amount of unfavorable attention from day one,
it wouldn't surprise me if a number of IESG members paid particular
attention to it.
So the group should expect that there will be one more round of
changes requested. Most of the changes that IESG requests are
minor and they're usually editorial in nature.
Keith