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

[Rolf Winter <[e-mail]>]

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

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]