Melinda (and others),
Please note that there are two questions here, with, at least to
me, are entirely different. The one you are addressing is about
whether the ISE should publish the document and, if so, what
technical and other changes should be made to the I-D before
that is done. Speaking personally, my free advice to Nicos is
to make it a lot more clear in the text that this is not an IETF
standard or other approved document or use of PKCS#8, why he
wants the document in the RFC Series rather than just put up on
some Red Hat web pages, that this is an OID in a Red Hat arc,
and what uses, if any, he expects or invites organizations who
are part of Red Hat's customer base to make use of it. And my
free advice to Adrian is that he not publish the thing unless
those issues are clarified to his satisfaction.
None of that has anything to do with the appeal.
The IESG has recommended that this document not be published
because they have concluded that it "extends an IETF protocol in
a way that requires IETF review and should therefore not be
published without IETF review and IESG approval." That raises
several questions, including whether RFC 5208 is actually "an
IETF protocol", whether adding a new OID definition like this
"extends" PKCS#8 in that way that RFC 4846 and 5742 anticipated
and, even if it did, if, given the nature of OIDs and their
descriptions and of the IANA Considerations of 5208 and 5958,
there is anything about this document that "requires IETF
review". It also raises more general questions such as whether
the procedures the IESG is using for thee reviews and the way in
which their reasoning is documented is consistent with the level
of transparency and openness we expect, whether the statements
suggested by RFC 5742 are sufficient to inform authors and the
ISE, and, if the IESG erred in making a "do not publish"
recommendation in this case, whether there is anything that can
usefully be done to reduce the chances of similar errors in the
future.
And those are the subjects of the appeal.
best,
john
--On Saturday, July 7, 2018 18:18 -0800 Melinda Shore
<melinda.shore@xxxxxxxxx> wrote:
> On 7/7/18 1:11 PM, John C Klensin wrote:
>> As to the arc owner giving others permission to use the OID
>> --assuming that is different from just making a description
>> available -- I see nothing in the I-D that does that unless
>> one construes "full conformance with the provisions of BCP 78
>> and BCP 79" as doing so.
>
> That seems to be a gap in the document. At any rate the
> usual reasons for publishing this sort of thing are to
> either establish a basis for interoperability or to reserve
> a code point. Since this OID comes from Nikos's private arc
> I'm assuming that it's not the latter. Also note that it
> falls under a "gnutls" object hierarchy within Nikos's arc,
> and it may be being used more broadly - dunno.
>
> The attribute seems to me to be generally useful to the
> community more broadly and it's reasonable to think the goal
> here was to document it so that others can use and/or
> implement it. I'm sure there are other possibilities that
> haven't occurred to me and guessing someone's intent can go
> wrong pretty easily, anyway, so I've written to Nikos to ask
> him rather than try to make inferences about it.
>
> Melinda
>
