Regards
On 14/12/2013 03:07, Pete Resnick wrote:
On 12/12/13 7:54 PM, Brian E Carpenter wrote:
Like RFC 1984 and RFC 2804, this one is intended to be jointly
issued by the IAB and IESG.
No. 1984 and 2804 were Informational. This is targeted as a BCP. It will
be a product of the IETF, not the IAB or IESG.
True, but as the document observes we have moved the goalposts by
inventing the streams.
It will be a consensus
document of the IETF. As 2026 says:
While it is recognized that entities such as the IAB and IESG are
composed of individuals who may participate, as individuals, in the
technical work of the IETF, it is also recognized that the entities
themselves have an existence as leaders in the community. As leaders
in the Internet technical community, these entities should have an
outlet to propose ideas to stimulate work in a particular area, to
raise the community's sensitivity to a certain issue, to make a
statement of architectural principle, or to communicate their
thoughts on other matters. The BCP subseries creates a smoothly
structured way for these management entities to insert proposals into
the consensus-building machinery of the IETF while gauging the
community's view of that issue.
Obviously (given the document editors), IESG and IAB members were
interested in "inserting this proposal into the consensus-building
machinery of the IETF". But it is, in the end, going to be a product of
the IETF.
As Jari said, the IAB may explicitly endorse this document, and I think
it would be wonderful if they would.
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).
Which is part of the reason for doing this as a BCP. The IAB gets to
issue its statements as Informational documents in its own stream. The
IESG manages the IETF stream and publishes consensus documents of the
IETF. That's nicely clarified in 5741, so doing this as a BCP is the
most appropriate. And being the consensus of the IETF will (hopefully)
be a stronger statement than "statements from on high."
The discussion of the principle *was* over in Vancouver.
Workshops, and IETF WGs, have to apply the principle to actual
technology.
See other messages. This is just rubbish. The discussion in Vancouver
(especially when one contrasts the IAB plenary from what was said in the
perpass BOF) made it clear that there was still some work to do
clarifying the bounds of the principle.
Well yes, I have to admit that, but if this doesn't sound too facile,
there was pretty clear consensus in Vancouver about the principle
of the principle. As with 1984 and 2804, there is work to do in
getting the words right.
Brian
That said, I do agree that this document is about the general principle,
not the details of how it applies to particular technology. We should
get the document clear that we (the IETF) intend to take seriously the
security threat of pervasive monitoring of data, a threat that we didn't
take as seriously before, and that we will attempt to mitigate that
threat in our protocols, where it is possible *and* sensible. I think
the current rev of the document is darn close (if not already there) on
the general principle, though I'm fine with finding the words to make
the "possible and sensible" part agreeable to folks. But we don't want
to mush the document up so much that it becomes "whenever we feel like
it". The principle has limits, and we should make sure we express that
fact clearly, but (I think) we absolutely do want to say that we have a
general hole to plug in many protocols, one that we didn't think was as
likely to be exploited as it turns out to be. And I think we want to say
that as concisely and generally as we are able to.
I hope the workshop will be discussing specific technology, or at
least specific technical guidelines, not wordsmithing the general
principle.
Yep.
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 said it better than I could. I completely agree.
pr