A few comments.. Attached in line with previous comments.
On 2013-11-09 11:02 AM, "Pete Resnick"
<presnick(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:
Engineering is hard. We've got to do that. Coming to consensus over the
engineering tradeoffs is also hard; there's no one-liner like, "We
always go with the running code". As the document says, the "running
code" bit of the mantra is that we value actual practical experience
over theoretical models. But running code is not itself some sort of
magical thing. We still have to do the rest of engineering and come to
consensus on whether we've gotten it "right". And I do think the
document says that much. I don't think it should go much further.
[VK] I fully agree - engineering is hard, and goes much further then a
specific moment in time when we have our first or subsequent version of
code. An important part of this is how the code/system runs in real
networks/environments and interoperates. Engineering is also a continuous
process in many cases.
I don't think we should enumerate the entire list of what trade-offs
should/can be made or what are all the considerations (list will likely be
very long). Making clear note that such things are part of process should
be sufficient.
On 2013-11-09 8:40 AM, "Randy Presuhn"
<randy_presuhn(_at_)mindspring(_dot_)com> wrote:
"I have very mixed feelings about this. Yes, it is the way
some working groups function. However, implementors are
in the best position to comment on the how difficult it is
to implement the specification correctly, as well as how
elements of the specification contribute to (or reduce)
implementation complexity. Both of these have very real
consequences for interoperability, security, and ensuring
a diverse ecosystem of independent implementations. The
mere fact that someone was able to get something to run
as specified should not carry more weight than their
assessment of how much unnecessary pain or overhead (CPU,
memory, whatever) results from quirks of the specification."
[VK] I would agree that implementors are in a good position to provide
feedback on various technologies and specifications. When exposed to large
networks, we often see code/systems run against a wide range of other
systems and/or technologies which may result in validation or update
requirements to the running code. I have seen many things which required
tweaking after it was in the wild.
From: Andy Bierman <andy(_at_)yumaworks(_dot_)com>
"We just a long debate in NETMOD WG and decided to abandon
the SNMP ifType enumeration in favor of a YANG identity registry.
The key factor was the early implementation experience of
the ietf-interfaces module by 1 vendor."
[VK] I think this is a great use case to exemplify the statements above.
[VK] Overall, I actually like the document and think it definitely helps the
reader (will often be a new person to the IETF) understand some of the
basics on how we reach consensus. My take would be that someone reading
this draft, then experiencing the IETF process both on list and in person
(should they have that opportunity), would gain a good understanding of the
method (as run by capable contributors, working group chairs, ADs,
Directorates etc)
Regards,
Victor K