At 06:12 20-09-2013, Harald Alvestrand wrote:
By those who implement them, and those who try to understand how it
works to the degree that they feel assured that there are no
non-understood security risks (intentional or otherwise).
Yes.
From the stack I'm currently working on, I find the ICE spec to be
convoluted, but the SDP spec is worse, becaue it's spread across so
many documents, and there are pieces where people seem to have
agreed to ship documents rather than agree on what they meant.
I have not found security implications of these issues.
I'll quote a message [1] from an ex-IAB member:
"in IPv4 days:
- implement and test
- then write a draft
or,
- BSD IPv4 code is there
- everyone cheated and looked at it
today:
- write a draft with pipe dream
- spam IESG
- then implement
- big issue happen
- go back to 1"
It is an implementor's nightmare to understand a specification when
it is spread across multiple documents. The "Updates" and document
status (label) does not make matters easier. Some parts will not be
committed into the tree as it is not simply a matter of writing code;
there is also the question of who is going to maintain that code.
At 07:34 20-09-2013, John C Klensin wrote:
I don't know of any general solution to those problems, but I
think the community and the IESG have got to be a lot more
willing to push back on a spec because it is incomprehensible or
contains too many options than has been the case in recent years.
If I recall correctly there was a discussion about a solution in
1992. RFC 2026 also considered the problem of too many options and
offered a path to resolve that.
At 08:37 19-09-2013, Phillip Hallam-Baker wrote:
Whatever our personal political views on the matter are, the views
of our audience are likely to be different. Most of our audience are
not US citizens, they are not even from the Anglosphere.
Yes.
of the one CA. That is OK, I don't complaint about that, I have
always understood that anyone who is taking on a position of extreme
responsibility is subject to an equally extreme degree of proof.
Yes.
The process I have seen instead is that people argue about whether a
requirement should be included in the requirements document and the
final requirements document is a list of requirements the noisiest
people in the group thought were important rather than what the
document should be which is a tool to determine whether the design
is capable of addressing the use cases.
The boundary between use cases and edge cases is not always
clear. The requirements document is a long list of stuff to satisfy
the noisiest and the people considered as important. Harald
Alvestrand mentioned "actually finishing our specs". It's difficult
to get there when a working group suffers from exhaustion.
Regards,
-sm
1. http://www.ietf.org/mail-archive/web/ipv6/current/msg07313.html