Re: Last Call: <C> (On Consensus and Humming in the IETF) to Informational RFC

[Victor Kuarsingh <victor@xxxxxxxxxx>]

A few comments.. Attached in line with previous comments.

On 2013-11-09 11:02 AM, "Pete Resnick" <presnick@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx>

"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