Subject: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed

From: Loa Andersson <[email-masked]>
Date: Tue, 25 Oct 2016 10:40:32 +0800

Working Group,

Even though there is a (albeit tepid) wg consensus to request
publication for this draft, we cannot proceed at this time.
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.

We will therefore keep draft-ietf-mpls-tp-mfp-use-case-and-requirements
alive while waiting for a solutions document to mature, and then
revisit the decision to publish this document or include some or all of 
the information in it in the solutions document.

/Loa
for the MPLS wg co-chairs
-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Oct 2016 08:35:57 +0100

> Once there is reasonable progress on a solutions document we can

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

---

From: Rolf Winter <[email-masked]>
Date: Tue, 25 Oct 2016 12:37:39 +0000

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:[email-masked]] On Behalf Of Stewart Bryant
Sent: Dienstag, 25. Oktober 2016 09:36
To: [email-masked]; <[email-masked]>
Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-requirements - Working Group Last Call closed

> Once there is reasonable progress on a solutions document we can 

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.

Stewart

_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 25 Oct 2016 14:28:05 +0100

Hi Rolf

It needs further discussion if chairs have drafts rejected out of policy 
rather than on a case by case basis.

My understanding of Loa's comment is that policy is the high order bit.

Maybe the RTG ADs can provide some guidelines?

Stewart

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 25 Oct 2016 22:17:56 +0000

Hi Stewart,

You may have missed the earlier mails and discussion on this thread. Rolf has summarized accurately that Loa's mail is referring to this draft and not to a policy change.

Thanks,
Deborah

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Tuesday, October 25, 2016 9:28 AM
> To: Rolf Winter <[email-masked]>; [email-masked]; <[email-masked]>
> <[email-masked]>
> Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-
> requirements - Working Group Last Call closed
> 
> Hi Rolf
> 
> > 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."
> >
> > Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-
> requirements - Working Group Last Call closed
> >
> >
> >
> 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.
> about this new IESG policy preventing WGs approaching their problems in the
> manner that best suits each problem.
> >

---

From: Loa Andersson <[email-masked]>
Date: Wed, 26 Oct 2016 11:10:42 +0800

Deborah,

with all due respect and without getting into "he said, she said, he
said. ... " debate, but I find what you say here not fully accurate.

I find myself quoted in such a way that inply that I without
reservations support the change in document procedures that I seen
developing over a little more than a year. In fact I have very strong
reservations.

First, mail mail say that we can not proceed at this time, and then
point to the change in procedure that stops us.

The earlier procedure were captured in RFC 4929

   "Whenever any extension or change to the (G)MPLS protocols is
    desired, a problem statement and/or requirements statement must
    be produced and must be submitted to IETF as an Internet-Draft."

The draft under discussion is a perfect example of this.

The RFC goes on and says that the IETF will evaluate the requirments,
praxis has been that the requirements has been published.

The earlier procedure hasa served us well.

Only that in this case we fail because the IESG has changed the the
procedure to "work in parallel".

I think that two years ago (to be on the safe side) there would have
been no problem publishing the ID as an RFC, at lest not for the reasons
that stop it now.

It surprises me that we don't accept what Jari said in his report from
the IESG retreat - "one size does not fit all".

That said I don't exclude that we will tweak the model to be more
iterative, but:

- first, we should not change in mid-process
- second, agreement on requirements, will always precede agreement on
   architecture, frameworks, solutions and operational models. The time
   span needed for "predede" is a matter of case by case.

I think that the ue of the word "parallel" is misleading, I guess what 
we are looking for is "iterative", i.e. an early step does not have to
be fully completed before the next step is started, the latter step
should be allowed to have an impact on the earlier.

It should also be noted that we have players within the industry that
communicate with us through requirements, but has no immediate intention
to be involved in the solutions work.

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 28 Oct 2016 12:30:14 +0100

I don't think that there is a policy that dictates rejecting this draft,
although common sense might!

First RFC 4929:
   This
   document is directed to multi-vendor fora and Standards Development
   Organizations (SDOs)
and
  This document does not modify IETF processes.

Furthermore, RFC 4929 says "a problem statement and/or requirements statement
must be produced and must be submitted to IETF as an Internet-Draft" but does
not say "and will be published as an RFC".

So let's leave RFC 4929 out of it?

Second, the IESG has not made an IESG statement on this topic. As Rolf says,
this was a blog post from Jari reporting on the IESG retreat
(https://www.ietf.org/blog/2016/05/). Anyway, the main message is clearly that
work on solutions should not be held up by work on use cases and requirements.
The subsidiary message is that use case and requirements documents "need not
necessarily always be RFCs". So there is clearly no policy here: no rules to be
applied, and only advice that could be relevant.

So maybe we can let go of that part of the discussion and focus on what is more
interesting for the WG, viz. "What is the lasting value of publishing this
document as an RFC? How will it shape the Internet in five years time?"

If there are people who intend developing solutions (or an applicability
statement) then why wouldn't it work to roll this material into that document?

If there is no one planning a solution, then what is the intention of writing
down requirements? Who is subject to this requirement? What is the document
actually saying?

Personally, I should think that the document is intended to encourage
implementers to develop solutions, but that the authors themselves do not intend
making such solutions. Will an RFC simply be published and forgotten? What will
be its value?

I'd suggest keeping the I-D alive as a WG document for 12 month to see if anyone
starts work on the solution. If they do, we roll it in with their work. If not
we let it expire and consider it archived."

But I'd also say that the cost of publishing  small RFC is small. It doesn't do
significant harm to publish it. So if the WG is determined on that approach,
let's just get on with it. (More cycles have been burned talking about whether
to publish than were ever spent discussing the content!)

Adrian

> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: 26 October 2016 04:11
> To: BRUNGARD, DEBORAH A; Stewart Bryant; Rolf Winter; [email-masked]; <rtg-
> [email-masked]>
> > You may have missed the earlier mails and discussion on this thread. Rolf
has
> summarized accurately that Loa's mail is referring to this draft and not to a
policy
> change.