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

[Loa Andersson <[e-mail]>]

Rolf,

On 06/10/2016 19:37, Rolf Winter wrote:
> 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]; [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.
> ---

I think your reading is correct - and I very much appreciated a model
where w developed things in a series of document - I guess MPLS-TP and
sub-projeccts are what comes to mind.

But the description of updating is obsoleted, i.e. it is history we
can't use to support our arguments. And according to the new orthodoxy
and addendum is not an update.

/Loa


>
> 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]