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

[Loa Andersson <[e-mail]>]

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]