It may have been clear to the IESG that there was disagreement. That is not
a barrier to adoption of a specification.
What is a barrier is when the disagreement comes from a statement from the
original proposers of the project that they are not interested in
addressing a set of requirements that are normally considered for a
proposal of that type and that they will ignore all attempts to raise those
requirements or proposals to meet them regardless of the merits.
It was not clear to the IESG that this was the case because it was not
clear to the AD that it was the case.
The IETF has a long tradition of publishing closed development efforts as
RFCs. But those RFCs are expected to be INFORMATIONAL. Had the AD and IESG
been aware of the nature of the consensus backing CBOR it is unlikely that
it would have agreed on PROPOSED STANDARD.
An appeal was raised. If you think that the process has to be followed or
bad things will result then you should insist that the IESG address the
matter in an official capacity to avoid the setting of the precedent you
want to avoid.
I find it rather interesting that there has been more concern about the
correct way to handle the non-handling of the appeal than there ever was
about the rather minor changes to the specification I proposed that could
have avoided the need for process questions at all.
I also find it rather interesting that people who don't have a need to
efficiently transport binary blobs of data about are so committed to making
it difficult for me to do that with a specification that is as close to
JSON as possible. If I have a 1Gb video file that I want to shove down a
pipe, I certainly don't want to add another 333MB of overhead just to use
JSON. Nor do I want to have a protocol that requires me to deal with two
different data models, two different encoders and two different parsers
when I can meet the exact same need by adding tags to JSON to give me a
length bounded chunk encoding.
Such an encoding is not JSON but it is close enough to JSON that I can use
one set of tools to encode/decode both formats. That is not true if I use
the JSON subset of CBOR.
On Thu, Feb 20, 2014 at 2:30 PM, S Moonesamy <sm+ietf(_at_)elandsys(_dot_)com>
wrote:
Dear IESG,
At 06:11 20-02-2014, Ralph Droms wrote:
My concern is that we not establish some de facto extension to our
processes by labeling this particular example of complaint resolution as a
formal appeal.
I share the concern that the IESG will establish the case at
http://www.ietf.org/mail-archive/web/ietf/current/msg86168.html as a
extension to the processes if it is labelled as a formal appeal.
There was the following comment from Hadriel Kaplan during the Last Call (
http://www.ietf.org/mail-archive/web/ietf/current/msg81414.html ):
"I think publishing it as Proposed Standard would be ok if there
wasn't strong disagreement, but it appears there is strong
disagreement, including on how it came to be."
It was clear to the IESG that there appeared to be strong disagreement.
I'll highlight the following from Section 6.5.2 of RFC 2026:
"The IESG is the principal agent of the IETF for this purpose, and it
is the IESG that is charged with ensuring that the required procedures
have been followed, and that any necessary prerequisites to a standards
action have been met."
I have the following question:
Is it the responsibility of the IESG to respond to an appeal about a
process
issue once a draft has gone through an IETF Last Call?
Regards,
S. Moonesamy
--
Website: http://hallambaker.com/