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

[Loa Andersson <[e-mail]>]

Rolf, et.al.,

Yes that might be the only route open to us, but as you said early we
will lose requirement trceability and I don't like that. Does anyone
have an idea how to fix that?

/Loa

On 2016-10-20 16:13, Rolf Winter wrote:
> Hi,
>
> FWIW, to me personally, what Deborah suggests seems the most sensible way forward.
>
> Best,
>
> Rolf
>
> -----Original Message-----
> From: BRUNGARD, DEBORAH A [mailto:[e-mail]]
> Sent: Donnerstag, 6. Oktober 2016 18:00
> To: Rolf Winter; Loa Andersson; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements
>
> Hi,
>
> I agree with Loa on this is not an update of RFC5654. RFC5654 is a document reflecting ITU-T requirements for MPLS-TP. This draft is not a result of a request by ITU-T.
>
> The document is building on RFC6372, but it doesn't necessarily "update" RFC6372. RFC6372 covers a wide range of mechanisms. An implementer of RFC6372 does not have to also implement this document unless they want to support this extra capability. So this capability is not required for any of those existing requirements, it's only needed if one wants this capability, so the requirements can stand on their own. Note, RFC6372 did not update RFC5654.
>
> I'm recommending to hold this document in the WG until a solution document is initiated. By doing a solution document, it will help determine if these requirements and the resulting solution are an update for any of the existing solution documents.
>
> As the document only has two requirements, it can be part of an appendix to a solution document. PCE recently did such a document:
> https://www.ietf.org/id/draft-ietf-pce-pcep-service-aware-13.txt
>
> Of more concern, I've not seen any mailing list discussion on this document or any solution document proposed indicating interest by the WG, I strongly encourage the list be used as progress a solution document. Working in parallel on requirements and a solution is always the best approach. Requirements documents do not need to be published as RFCs, especially these very short type of documents. The IETF Chair summarized this in his May blog on the IESG retreat:
> https://www.ietf.org/blog/2016/05/
>
> Thanks,
> Deborah
>
>> -----Original Message-----
>> From: mpls [mailto:[e-mail]] On Behalf Of Rolf Winter
>> Sent: Thursday, October 06, 2016 7:37 AM
>> To: Loa Andersson <[e-mail]>; [e-mail]
>> Cc: [e-mail]; draft-ietf-mpls-tp-mfp-use-case-and-
>> [e-mail]
>> Subject: Re: [mpls] working group last call on
>> draft-ietf-mpls-tp-mfp-use-case- and-requirements
>>
>> Hi,
>>
>> please see inline.
>>
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: Donnerstag, 6. Oktober 2016 10:09
>> To: [e-mail]
>> Cc: [e-mail]; draft-ietf-mpls-tp-mfp-use-case-and-
>> [e-mail]
>> Subject: Re: working group last call on
>> draft-ietf-mpls-tp-mfp-use-case-and-
>> requirements
>>
>> Working Group, authors,
>>
>> We are past the closing date for this wglc. I'm reluctant to close the last call.
>> The reason is that I received some comments off-line that I'd like to
>> hear feed back on.
>>
>> 1. Existing solution mechanism(s)
>>     ------------------------------
>>     It is said that even though we have no existing implementations of
>>     m:n, there are existing solutions mechanisms that meet the
>>     requirements.
>>     I would like to have this verified if possible.
>>
>> 2. Not an update of 5654
>>     ---------------------
>>     This is probably correct, this document adds two new requirements,
>>     but does in no way change RFC 5654.
>>
>> --- RW
>> This is the text concerning updates of RFC in RFC2223 (it has recently
>> been obsoleted by RFC 7322, but text regarding the reasoning behind
>> updates has basically vanished there as far as I can tell):
>>
>> Updates
>>
>>       To be used as a reference from a new item that cannot be used
>>       alone (i.e., one that supplements a previous document), to refer
>>       to the previous document.  The newer publication is a part that
>>       will supplement or be added on to the existing document; e.g., an
>>       addendum, or separate, extra information that is to be added to
>>       the original document.
>>
>> I think this makes this document an update as it contains an addendum
>> essentially. Or the other way round, if you read 5654, there is no way
>> the reader can tell there are more requirements. An update will make that clear.
>> ---
>>
>> 3. Document structure
>>     ------------------
>>     IESG members has recently expressed opinions that we should not
>>     publish small stand alone document with a small number of use cases
>>     or requirements, thes should rather be kept with the working and
>>     published as appendices to the solutions document.
>>     I would like to hear comments on this.
>>
>> --- RW
>> I can understand this and usually I would agree. But then, given the
>> above that solution document would need to update RFC5654 and that
>> would be strange, having a solution document update a requirements
>> document. It would mix two things I believe should be separate. You
>> unfortunately cannot restrict an update of an RFC to a section of a different RFC.
>>
>> ---
>>
>> 4. The document need to be liaised to ITU-T SG15
>>     ---------------------------------------------
>>     I agree with this, normally we liaise wg consensus texts, and the
>>     document could be liaised when the wglc closes.
>>
>> --- RW
>>
>> Yes, that should be done.
>>
>> Best,
>>
>> Rolf
>>
>> ---
>>
>> To hear the feedback on this I will keep the wglc open for another
>> week starting today.
>>
>> /Loa
>> mpls wg co-chair
>>
>> On 18/09/2016 18:39, Loa Andersson wrote:
>>> Working Group,
>>>
>>> This is to initiate a two week working group last call on
>>> draft-ietf-mpls-tp-mfp-use-case-and-requirements-02.
>>>
>>> Please send your comments to the mpls wg mailing list ([e-mail]).
>>>
>>> There were no IPR disclosures against this document.
>>>
>>> All the authors and contributors have stated on the working group
>>> mailing list that they are not aware of any IPRs that relates to
>>> this document.
>>>
>>> This working group last call ends Oct 2, 2016.
>>>
>>>
>>> /Loa
>>> for the MPLS wg chairs
>>
>> --
>>
>>
>> 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

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]