>>>>> "Stephen" == Stephen Farrell <stephen.farrell@xxxxxxxxx> writes:
Stephen> Absolutely. And I don't think any AD would or should do
Stephen> that. As it happens, my experience over the last 3 years
Stephen> is that the IESG have self-regulated in a way that would
Stephen> have addressed this anyway. Many or maybe all new ADs (me
Stephen> included) seem to start out being a bit too enthusiastic
Stephen> about some aspect of the IETF but after a while, and
Stephen> sometimes a quiet chat or two, we've all settled down to a
Stephen> better balance between making progress and being
Stephen> picky. (Not sure if all authors would agree mind you:-)
HI.
I'm hearing your concern that you believe getting detailed guidance here
would take years and that you think this document is important to
publish sooner than that.
Please read below; I have a specific proposal that I think we can move
on quickly.
I also hear you saying that the IESG will self-regulate to avoid
gumming up the works.
I agree with that.
However, that self regulation will be applied very late in the process.
As a result the BCP will have very little impact except on security
considerations text.
And yes, I'd say that this has been a defect of the IESG of the last
three years.
This guidance is something we need WG chairs to understand early in the
process, not ADs to understand late in the process.
As a specific example, I cannot get the guidance from this BCP to know
how to approach the issues I bring up for any of the working groups
I've ever chaired.
You haven't told me enough to do my job.
Yes, I can try and build consensus within the WG on how the WG feels
about passive attacks.
I don't need this BCP to do that.
What I don't get is a sense of the community's input in how I should
balance the issues surrounding existing protocols and architecture
re-use in my work. Some aspects of that will be WG specific. Some
aspects will be places where IETF-wide balance and area-wide balance are
important.
Providing help with that is one of the major values of BCPs like this.
Stephen> I also don't want to see us wait years before we reduce the
Stephen> real consensus that exists to words in an RFC. Doing the
Stephen> most-significant-bit of that now is important IMO.
OK.
I proposed this in my first message but I'll be more clear.
Right now, we decide that the balances I'm looking for are dynamic.
We delegate to the IESG to keep the community informed on the current
balance it sees in the form of an IESG statement.
To move forward I'm looking for:
1) Paragraph describing the existing protocols issue (just what the
issue is, not current thinking) in this document
2) Paragraph describing the architectural re-use issue in this document.
3) Paragraph in this document stating that the IESG will give community
guidance on how they are approaching these issues and update that
guidance as appropraite.
4) Commitment that the IESG is OK with 3.
If we can do that I'm happy accepting that we can handle the issue on an
ongoing basis.
I'm happy to help with 1 and 2 above.
>> Please, whatever you do, remove section 3 on the process note.
>> As it stands, it reads as follows:
>>
>> * We're unable to find a way for the IESG and IAB to publish a
>> document together
Stephen> That's accurate. Bit, isn't it;-)
I object to a statement claiming that the IESG and IAB cannot publish a
joint architectural statement under our current processes being in a
IETF consensus document.
I believe it to be false.
I appreciate that you failed to think of a way to do so, but I've come
up with several options that I think would work.
I'm not going to get into why I think you're wrong because I agree with
you that it doesn't matter for this document.
I do understand that I'm claiming a number of people who have thought
about how to publish a joint statement and failed to come up with an
answer are wrong. I'd be happy to discuss details in personal mail if
anyone really cares. Again, I don't think it matters for this document.
even if we've somehow boxed ourselves in that manner, it's not something
we need to say in this document and saying it makes us look foolish.
I hear your concern that you want to explain why it is different. I'm
not actually sure we'll all agree on why it is different. For me it's
different because we have more of a community-focused process now. I'm
not sure we can do better than saying how we used to do it and that
we're doing what we do now.