Subject: [sfc] Processing of draft-liu-sfc-use-cases-08.txt

From: Thomas Narten <[email-masked]>
Date: Sun, 09 Nov 2014 21:08:58 -0500

This WG has an outstanding issue of what to do with
draft-liu-sfc-use-cases-08.txt. Reviewing some history, when the WG
was originally formed there was a debate about how best to handle SFC
use cases generally. There were some who felt we should have a number
of individual, scenario-specific, use case documents. There were also
calls for a single general use-case document that covered everything,
The WG ended up adopting two more-specific documents
(sfc-use-case-mobility & sfc-dc-use-cases), deferring action on the
more general document draft-liu-sfc-use-cases-08.txt.

Since that decision, there have been repeated calls from the authors
(with support from others) to adopt liu-sfc-use-cases as
well. However, the chairs have hesitated for a number of reasons, as
outlined below.

1) The purpose of use-case documents is to drive requirements. One
doesn't need a use-case document for every possible use case. At some
point, having yet another document yields diminishing returns. we
would observe, that so far, none of the use-case documents seem to
have produced any "requirements" in the sense of pointing out
something SFC needs to do that isn't already covered in the
architecture/problem statement. That suggests to us that the use case
documents have limited value.

2) We continue to have concerns about what additional/different
content liu-sfc-use-cases has compared with the other documents. The
discussions so far have not been very illuminating, being mostly
generic "I think it has value" vs. "don't need it". (Thomas will
separately post a note with specific concerns.)

3) My (Thomas') approach to WG documents is simple and has been
consistent for many years: what is in the best interest of the
community and what is best for the readers of RFCs long after a WG has
finished. Having more documents can make it more difficult for someone
to sift through the various documents to find the ones of value. That
is especially true when the same general topic is covered in multiple
documents. In such cases, there is often overlapping content.

4) The real work of the WG is the architecture and protocols. That is
where the WG should be spending its cycles. Every document a WG takes
on takes WG resources away from other documents (i.e., to review and
iterate). This is not just a WG statement, but an IETF
statement. Every document a WG produces goes through IETF LC and IESG
review. That takes resources. The IETF complains regularly about lack
of cycles and poor quality work reaching the IESG. The best place to
address that concern is at the WG, including by not adopting all
documents that someone wants to publish. We would prefer that the WG
focus its efforts on the documents that matter the most.

5) It would be easy to call for adoption, and most likely there would
be enough show of support to support adoption. However, the IETF is
not a simple democracy where decisions are made by simple vote counts.

Hence, our hesitation in asking for WG adoption of this document. If
the document was an important component to the WG's core deliverables,
we would of course expect the WG to take it on. Absent that, however,
we think it would be better to focus  on core documents.

Thomas & Jim

---

From: Jiangyuanlong <[email-masked]>
Date: Tue, 11 Nov 2014 06:44:47 +0000

Hi Tom,

Please see my comments inline.

Regards,
Yuanlong

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Thomas Narten
Sent: Monday, November 10, 2014 10:09 AM
To: [email-masked]
Subject: [sfc] Processing of draft-liu-sfc-use-cases-08.txt

[JY] I have a different opinion here. The architecture draft has been evolving all the time, quite a few requirements from use cases and other I-Ds are reflected in its newer version, not in its initial version. Furthermore, the use case drafts not only serve the people who are doing SFC architecture, but also help those who are not familiar with SFC to understand the architecture (e.g., those not in the WG, and future developers). 

[JY] This makes sense, but the chairs definitely took a different approach when other use case documents were adopted half a year ago. 

Thomas & Jim

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc