Tom,
On 12/12/2013 23:23, t.p. wrote:
> Jari
>
> I am wondering what the role of the IAB is in this. Statements of
> policy such as this I have seen previously from the IAB, as in the
> RFC2804 that has just been referenced. Whereas the IETF produces the
> engineering, such as TLS or IPsec, which is rather different in nature.
> Does the IAB approve or disapprove of this? Why isn't it involved?
Like RFC 1984 and RFC 2804, this one is intended to be jointly
issued by the IAB and IESG. I don't see any difference (except for
the artefact that it has to be assigned to one of the streams,
which didn't exist when the two previous RFCs were issued).
> And when I look at the IAB website, I am bemused. The IAB is calling
> for papers for a conference on this precise topic, to be held in three
> months, by which time you want this I-D to be signed, sealed and
> delivered.
Yes - this is a statment of principle. We can continue to waste time
wordsmithing, or we can just put it out there and save bits.
So that the IAB can wave it at all participants and say
> 'Discussion over'? Or what?
The discussion of the principle *was* over in Vancouver.
Workshops, and IETF WGs, have to apply the principle to actual
technology.
> It seems to me that this I-D is an ideal candidate to be presented and
> discussed at the conference after which, the IAB can produced a
> carefully considered document.
I hope the workshop will be discussing specific technology, or at
least specific technical guidelines, not wordsmithing the general
principle.
On 13/12/2013 01:37, Stewart Bryant wrote:
> I should add to this response that Dave Crocker
> proposed that we pull back on this BCP and
> explicitly consider its impact in each of our
> working groups.
I strongly disagree. That detailed consideration should
follow *after* the general principle has been committed
to the RFC repository. Otherwise we will simply enter a
maze of looping discussions.
Brian