-------- Forwarded Message --------
Subject: Re: Use of private OIDs in WG (standard-track) documents
Date: Sat, 28 Mar 2015 22:45:27 +0000
From: Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: Massimiliano Pala <director(_at_)openca(_dot_)org>
(sorry for the previous mail due to an engimail bug that's
been bugging me for a week now:-)
Hi Max,
On 28/03/15 16:04, Massimiliano Pala wrote:
Hi Stephen, all,
it seems that lately we do not agree on many positions :-(
Not to worry.
However, my concern is about a procedure and I do think asking for a
"standardized" approach to how OIDs should be presented in RFCs is not
a bad idea. Why this discussion would be counter productive ?
The discussion on the trans list is fine to have. A discussion of a
generic rule disallowing non IETF OIDs in IETF protocols would be
counterproductive I think. The reason is that no such rule is needed
and even if it were we already have a pretty bizarre process full of
bureaucracy and adding to that is not a good plan. (That's my position
anyway, and that of others, though perhaps not everyone's.)
People using judgement and common sense to establish rough consensus
without overly broad rules/bureaucracy/official positions is a better
way to organise for the IETF.
Anyhow, I did not ask to start a discussion (this could be useful, IMHO),
all I asked is "what is the official position of IETF." - if there is
none, then
we might talk about starting this discussion.
We don't do "official positions" at all really. There are IESG
statements on some process things [1] but this would not fit
there I think, and otherwise we have a set of process RFCs and
BCPs (such as RFC2418 [2]). (And btw, I consider it a good thing
that you've participated in the IETF for 15 years without having
to know much about all of our process-minutae:-)
If you want to make the case that non-IETF arcs ought not be
used in some class of RFC, then you would need to write an I-D
setting out the details. And then you'd want to build support
for that position, to the point where it achieves IETF consensus.
(Frankly, I don't think there's much point in doing so, for
the reasons I and others already set out, but that's how it'd be
done.)
I think the details wrt why such a policy on OIDs would be bad
or pointless have been answered already limit myself to the
process point here. And I'm sending this mainly since this is
the 2nd time you've asked me for an "official position" in the
last week and I've disappointed you both times, so a bit of
a fuller explanation is warranted I guess. (I'm happy to
explain more offlist if that helps too, I'm not sure that all
that needs to be on this list.)
Cheers,
S.
[1] https://www.ietf.org/iesg/statement.html
[2] https://tools.ietf.org/html/rfc2418
When I saw the WG document, I was surprised to see the use of OID raw
values directly in the document - there was no mention about the fact that
the selected OID values were under a private subtree (Google), something
that I have never seen before in a WG document in the past 15yrs.
I want to point out that, in this specific case, there was no mention of
the
OIDs in the IANA section. My guess is that the authors felt that there
was no
need to ask IANA to assign an OID since the used value is already in
control
under its own private sub-tree. Since this document is in its -06
version, I
guess this was approved by the WG chair(s).
/*If this is a perfectly viable option*/, that it should be made clear.
/*If this is not the desired approach*/, also that should be made clear.
I do not understand why _/*asking for an official position about this
would*/__/*
*/__/*be an issue*/_ - it is perfectly ok to say "IETF does not care
about what OIDs
are inside RFCs". I have a preferred approach, but here I am just asking
if we can get an official position about the topic. Are we not allowed
to ask
for clarifications anymore ?
Therefore,*I do reiterate my request for an official position about this
issue*.
This is in the interest of having a clear understanding of what the
desired
procedure (or what is the current best-practice) is and what principle
should be
followed within the IETF community.
Coming to my specific concern, I see potential issues in allowing values
from
different (especially private) sub-trees that are not related to each
other for
OIDs that clearly belong together (e.g., extensions for PKIX protocols
and data
structures - OCSP messages and X509 Certificates - should, logically, be
under
the PKIX OID) might create confusion and it would be quite difficult to
have a clear
understanding of OIDs used in a particular area - very common
engineering principle.
This is why, and this is my personal opinion, a coherent approach is,
IMHO, paramount.
Thanks,
Max
On 3/28/15 9:18 AM, Stephen Farrell wrote:
Max,
On 28/03/15 13:47, Massimiliano Pala wrote:
I think that allowing this as a common practice is a bit dangerous.
What danger do you perceive here? I'm not seeing it. Nor do I see any
need at all for an "official" IETF-wide position, and in fact, such a
position is quite likely to be counterproductive IMO.
And as Phill said, re-numbering, if it breaks code, isn't a good
plan. Asking if it would break code, etc. on the trans list, is a
totally reasonable question btw and that discussion is already
happening there.
S.
PS: This isn't about a MIB, but a PKI thing.