Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements

Hi Stewart,

I don't think the IESG has made a strict policy in this regard. Below is the blog post extract that talks about this. I read it as a recommendation to focus on protocol work and not let requirements work stall important protocol specifications and as a clarification that there is no actual need to go through a problem definition/use cases/requirements stage before protocol work can start. But, as the text states, there is no one-size-fits-all approach. Not sure this is actually controversial and needs further discussion.

"We also discussed the role of requirement, use case, and problem definition documents in IETF work. There is no one-size-fits-all approach to different working groups. But the IESG wanted to be clear that the essence of IETF work and the energy often comes from working on protocol solutions. We were concerned about cases where it takes a long time to get to that work. Working groups should NOT feel they need to sequence their work in waterfall style. In fact, working in parallel with solutions and other supporting documents (and code!) is often the best approach. And some of the supporting documents need not necessarily always be RFCs; wikis, for instance, are a fine approach as well."

From: https://www.ietf.org/blog/2016/05/ 

Best,

Rolf

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Dienstag, 25. Oktober 2016 09:36
To: mpls@ietf.org; <rtg-ads@ietf.org>
Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed

On 25/10/2016 03:40, Loa Andersson wrote:
> Working Group,
>
>
> Our AD and the IESG recommend working in parallel with requirements 
> and solutions.  The fact is that have been no drafts on solutions.
> Once there is reasonable progress on a solutions document we can 
> proceed.

This change of policy by the IESG is something that I think needs wider discussion.

Sometimes this is right, but other times it is useful to establish the requirements in the absence of a decision on the solution to harden the foundations of the project.

It is not uncommon for people to game the requirements to give the edge to their preferred solution. In these circumstances, taking an objective look at the requirements and freezing them through publication can help.
Also in some cases there may be a matter of IESG policy that needs to be frozen before important decisions in the solution can be made.

Now I am not sure that this applies to this specific case, but I am worried about this new IESG policy preventing WGs approaching their problems in the manner that best suits each problem.

Perhaps a discussion for the open meeting?

Stewart

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls