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

["Adrian Farrel" <[e-mail]>]

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

> -----Original Message-----
> From: mpls [mailto:[e-mail]] On Behalf Of Loa Andersson
> Sent: 26 October 2016 04:11
> To: BRUNGARD, DEBORAH A; Stewart Bryant; Rolf Winter; [e-mail]; <rtg-
> [e-mail]>
> Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-
> requirements - Working Group Last Call closed
> 
> 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
> 
> On 2016-10-26 06:17, BRUNGARD, DEBORAH A wrote:
> > 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
> >
> >> -----Original Message-----
> >> From: Stewart Bryant [mailto:[e-mail]]
> >> Sent: Tuesday, October 25, 2016 9:28 AM
> >> To: Rolf Winter <[e-mail]>; [e-mail]; <[e-mail]>
> >> <[e-mail]>
> >> Subject: Re: [mpls] COnsensus call on draft-ietf-mpls-tp-mfp-use-case-and-
> >> requirements - Working Group Last Call closed
> >>
> >> 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
> >>
> >>
> >> On 25/10/2016 13:37, Rolf Winter wrote:
> >>> 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:[e-mail]] On Behalf Of Stewart Bryant
> >>> Sent: Dienstag, 25. Oktober 2016 09:36
> >>> To: [e-mail]; <[e-mail]>
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mpls
> >
> > _______________________________________________
> > mpls mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls
> >
> 
> --
> 
> 
> Loa Andersson                        email: [e-mail]
> Senior MPLS Expert                          [e-mail]
> Huawei Technologies (consultant)     phone: [phone]
> 
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls