Web Real-Time Communication Use Cases and Requirements
draft-ietf-rtcweb-use-cases-and-requirements-16

[Ballot comment]

Thanks for addressing my discuss points (and sorry
it took so long)

Didn't check these.

- intro: I don't get how the document is planned to be
used later, but that's ok. For now however, I'm reading
the requirements as if those are the ones that the WG
are working to, since I've no other sensible choice
really. (And the plan confuses me more if W3C are
taking these as real but rtcweb isn't.)

- F10: heh, which video codec exactly? :-)

- F11: Is 2804 the exactly right reference, maybe 7258
is worth adding (now its published) as that also
envisages non-targetted PM whereas 2804 is really only
considering targetted wiretap. Or maybe refer to both.

- F19: Is acquiring call metadata via TURN considered a
breach of F11? If not, then shouldn't that also get a
mention somewhere?

- F35: the title of 3.3.9 is about files but the
requirement is about data, seems like a mismatch

- 3.3.10: I've heard this use-case before. It was
outlandish then. Not objecting though.

[Ballot discuss]

Discuss updated for -15, a bit more mail to check stuff and
then we're likely done.

Nice document, thanks. But I have some issues to check.
Nothing huge I'd say.

(1) Cleared, WG assured me they would consider LoF/TOFU.

(2) F20: Is there not a missing requirement that one
ought not be able to easily consume the bandwidth of
someone else's TURN server just because you once made a
call via that?

(3) Cleared. WG assured me it'll be handled in the
security draft.

(4) 3.3.12.1 - if the sound file can be local and
played as a result of gameplay then that implies some
form of authorization for access to files on the local
filesystem - is that requirement actually being worked?

(5) 6.2: why is revocation only "expected" and not a
MUST? And why doesn't this section have any 2119 terms?
I think privilege revocation has to be a 2119 MUST.
(But am open to argument that that MUST ought apply to
the API not protocol.)

[Ballot discuss]

Discuss updated Oct 21.

Nice document, thanks. But I have some issues to check.
Nothing huge I'd say.

(1) Cleared, WG assured me they would consider LoF/TOFU.

(2) F20: Is there not a missing requirement that one
ought not be able to easily consume the bandwidth of
someone else's TURN server just because you once made a
call via that?

(3) Cleared. WG assured me it'll be handled in the
security draft.

(4) 3.3.12.1 - if the sound file can be local and
played as a result of gameplay then that implies some
form of authorization for access to files on the local
filesystem - is that requirement actually being worked?

(5) 6.2: why is revocation only "expected" and not a
MUST? And why doesn't this section have any 2119 terms?
I think privilege revocation has to be a 2119 MUST.
(But am open to argument that that MUST ought apply to
the API not protocol.)

[Ballot comment]

Didn't check these.

- intro: I don't get how the document is planned to be
used later, but that's ok. For now however, I'm reading
the requirements as if those are the ones that the WG
are working to, since I've no other sensible choice
really. (And the plan confuses me more if W3C are
taking these as real but rtcweb isn't.)

- F10: heh, which video codec exactly? :-)

- F11: Is 2804 the exactly right reference, maybe 7258
is worth adding (now its published) as that also
envisages non-targetted PM whereas 2804 is really only
considering targetted wiretap. Or maybe refer to both.

- F19: Is acquiring call metadata via TURN considered a
breach of F11? If not, then shouldn't that also get a
mention somewhere?

- F35: the title of 3.3.9 is about files but the
requirement is about data, seems like a mismatch

- 3.3.10: I've heard this use-case before. It was
outlandish then. Not objecting though.

[Ballot discuss]
Thank you for writing a good document. Before recommending the final approval, I would like to see a response to Brian Carpenter's Gen-ART review, however. I believe that at least his first comment on different combinations of IPv4/IPv6 is something that deserves to be addressed in the document.

OLD:
  o  Clients can be on networks with a NAT using any type of Mapping
      and Filtering behaviors (as described in RFC4787).
NEW:
  o  Clients can be on networks with a NAT or IPv4-IPv6 translation devices using any type of Mapping
      and Filtering behaviors (as described in RFC4787).

[Ballot discuss]
I have not seen any reply to Tina's OPS-DIR review, dated from April 25th. That makes it a DISCUSS to me, even if not all points in Tina's feedback are DISCUSS-worthy.
See http://www.ietf.org/mail-archive/web/ops-dir/current/msg00274.html

[Ballot comment]
- References please

  Assuming that ICE will be used, this means that the service provider
  would like to be able to provide several STUN and TURN servers (via
  the app) to the browser; selection of which one(s) to use is part of
  the ICE processing.

-  But in addition to this, the users can send and receive files stored
  in the file system of the device used.

3.3.9.2. Additional Requirements

  ----------------------------------------------------------------
  REQ-ID      DESCRIPTION
  ----------------------------------------------------------------
  F35    The browser must be able to send reliable
          data traffic to a peer browser.
  ----------------------------------------------------------------

Do you want to say?

F35    The browser must be able to send files to a peer browser.

Does "data traffic" = file?
Also, reliability is implicit, not?

-
particiapants  -> participants

- section 3.3.11. Multiparty video communication,  3.3.12, and potentially so other: Any connection with "Use Cases for Telepresence Multistreams", RFC 7205?

- Why are the API requirements in an appendix?
Because there are not normative? If so, make it clear.

[Ballot comment]
This document is a mishmash of UI requirements, local browser implementation requirements, and protocol requirements, with no distinctions being made among them. Given the IETF's notorious lack of skill in producing good UI work, and a great deal of text over the years indicating that we don't do UI and we don't constrain local implementation choices when they don't affect interoperability, I'm very dubious about the worth of this document. Then the introductions says:

  This document was developed in an initial phase of the work with
  rather minor updates at later stages.  It has not really served as a
  tool in deciding features or scope for the WGs efforts so far.  It is
  proposed to be used in a later phase to evaluate the protocols and
  solutions developed by the WG.

So the document was not found to be of use on input to the WG, and it's not clear to me what exactly happens if the evaluation concludes that the protocols and solutions don't meet these requirements at the end.

I don't see the point in publishing this document, certainly at this time.

Moreover, there are things in this document which strike me as problematic. I suspect things like those said in 3.3.1.1 will end up being (inappropriately) used as a bludgeon later, for no good reason: "Well, the requirements document published by the IETF says that you have to have a self-view during session establishment. You don't have self-view during session establishment. You're non-conformant and therefore will not be allowed in the market." Even mentioning self-view during session establishment in an IETF document gives me the creeps; I can imagine UIs with the feature, and I can imagine them without.

Some of the requirements seem awfully suspicious. For example:

  F13    The browser must encrypt, authenticate and
          integrity protect media and data on a
          per-packet basis, and must drop incoming media
          and data packets that fail the per-packet
          integrity check.  In addition, the browser
          must support a mechanism for cryptographically
          binding media and data security keys to the
          user identity (see R-ID-BINDING in [RFC5479]).

Maybe "per-packet encryption" means something magical, but can't we imagine a protocol decision that ends us up with stream-based or body-based encryption that is not "per-packet" that would still be perfectly reasonable? I wonder whether this document is over-constraining.

And finally, we have stuff like this:

"3.3.10.  Hockey Game Viewer"
"3.4.2.  Fedex Call"

Cute, but seriously? Do we really need cultural references like this?

I can't support the publication of this document. I won't stand in the way if it has consensus behind it, but I don't see the point.

[Ballot comment]
Thanks for addressing my DISCUSS.

The requirements listed in 3.3.7.2 are incorrect. First, F17 does not derive from the use case described in 3.3.7.1. Second, the text listed for F22 is not the appropriate text. To be consistent with how F22 is used in the rest of the document, it should say:

"The browser should be able to take advantage
          of available capabilities (supplied by network
          nodes) to prioritize voice, video and data
          appropriately."

[Ballot comment]
Thank you for addressing Alissa's DISCUSS, and I agree with the proposed text.

I noticed a couple of things other ADs didn't comment on yet:

3.3.12.1.  Description

  Note: the difference regarding local audio processing compared to the
  "Multiparty video communication" use-case is that other sound objects
  than the streams must be possible to be included in the
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  spatialization and mixing.  "Other sound objects" could for example
  be a file with the sound of the tank; that file could be stored
  locally or remotely.

This is really rough. Perhaps "other sound objects must be allowed to be included with the audio streams in spatialization and mixing"?

In these requirements:

  ----------------------------------------------------------------
  Requirements related to audio processing
  ----------------------------------------------------------------
  REQ-ID      DESCRIPTION
  ----------------------------------------------------------------
  F27    The browser must be able to apply spatialization
          effects when playing audio streams.
  ----------------------------------------------------------------
  F28    The browser must be able to measure the
          voice activity level in audio streams.
  ----------------------------------------------------------------
  F29    The browser must be able to change the
          voice activity level in audio streams.
  ----------------------------------------------------------------
  F30    The browser must be able to process and mix
          sound objects (media that is retrieved from
          another source than the established media
          stream(s) with the peer(s) with audio streams.
  ----------------------------------------------------------------

F27 says "when playing". The other requirements don't. Is it obvious to everyone but me whether F28 and F29 apply to a browser sending audio, a browser receiving audio, or both?

[Ballot comment]
Thank you for addressing Alissa's DISCUSS, and I agree with the proposed text.

I noticed a couple of things other ADs didn't comment on yet:

3.3.12.1.  Description

  Note: the difference regarding local audio processing compared to the
  "Multiparty video communication" use-case is that other sound objects
  than the streams must be possible to be included in the
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  spatialization and mixing.  "Other sound objects" could for example
  be a file with the sound of the tank; that file could be stored
  locally or remotely.

This is really rough. Perhaps "other sound objects must be included with the audio streams in spatialization and mixing"?

In these requirements:

  ----------------------------------------------------------------
  Requirements related to audio processing
  ----------------------------------------------------------------
  REQ-ID      DESCRIPTION
  ----------------------------------------------------------------
  F27    The browser must be able to apply spatialization
          effects when playing audio streams.
  ----------------------------------------------------------------
  F28    The browser must be able to measure the
          voice activity level in audio streams.
  ----------------------------------------------------------------
  F29    The browser must be able to change the
          voice activity level in audio streams.
  ----------------------------------------------------------------
  F30    The browser must be able to process and mix
          sound objects (media that is retrieved from
          another source than the established media
          stream(s) with the peer(s) with audio streams.
  ----------------------------------------------------------------

F27 says "when playing". The other requirements don't. Is it obvious to everyone but me whether F28 and F29 apply to a browser sending audio, a browser receiving audio, or both?

[Ballot discuss]

Nice document, thanks. But I have some issues to check.
Nothing huge I'd say.

(1) F13: Authenticate is ambiguous here (and in WebRTC
generally). There appears to be an understated need for
an IdP here, and its really the IdP's that are
authenticating (one another and) the endpoints. Did the
WG discuss any form of endpoint auth that's based on
e.g. an SSH leap-of-faith like setup where the
endpoints can re-authenticate one another after a first
contact? It'd be a bad thing if the WG made that
impossible and effectively required IdPs I think. 

(2) F20: Is there not a missing requirement that one
ought not be able to easily consume the bandwidth of
someone else's TURN server just because you once made a
call via that?

(3) F36: Its not clear to me that this can ever be done
safely, since JS code with this privilege can take
screenshots every 10ms and hence get everything.  A
"must" level requirement seems quite inappropriate even
if there is a real requirement there to allow some
support for screensharing.

(4) 3.3.12.1 - if the sound file can be local and
played as a result of gameplay then that implies some
form of authorization for access to files on the local
filesystem - is that requirement actually being worked?

(5) 6.2: why is revocation only "expected" and not a
MUST? And why doesn't this section have any 2119 terms?
I think privilege revocation has to be a 2119 MUST.
(But am open to argument that that MUST ought apply to
the API not protocol.)

[Ballot comment]

- intro: I don't get how the document is planned to be
used later, but that's ok. For now however, I'm reading
the requirements as if those are the ones that the WG
are working to, since I've no other sensible choice
really. (And the plan confuses me more if W3C are
taking these as real but rtcweb isn't.)

- F10: heh, which video codec exactly? :-)

- F11: Is 2804 the exactly right reference, maybe 7258
is worth adding (now its published) as that also
envisages non-targetted PM whereas 2804 is really only
considering targetted wiretap. Or maybe refer to both.

- F19: Is acquiring call metadata via TURN considered a
breach of F11? If not, then shouldn't that also get a
mention somewhere?

- F35: the title of 3.3.9 is about files but the
requirement is about data, seems like a mismatch

- 3.3.10: I've heard this use-case before. It was
outlandish then. Not objecting though.

[Ballot comment]
I support Alissa's discuss and appreciate you addressing her security concerns.

In Section 6.2, can you repeat the requirement to prevent wiretapping in this list?  Other security requirements are repeated and this one if important in light of the revelation on GHCQ gaining access to Yahoo web chat a couple of months ago.

[Ballot discuss]
Section 6 strikes me as somewhat incomplete. I can appreciate that this is not the place to discuss every security issue relevant to RTCWEB, but this section makes it sound as if the security threats are limited to DoS and surreptitious stream creation, leaving out considerations related to confidentiality, user identity, etc. At the very least, it seems like this section should stress that the scope of the discussion here is limited to those things (and maybe give a reason why?), and that a fuller treatment of the relevant security threats and mitigations is available in draft-ietf-rtcweb-security and draft-ietf-rtcweb-security-arch.

[Ballot comment]
The requirements listed in 3.3.7.2 are incorrect. First, F17 does not derive from the use case described in 3.3.7.1. Second, the text listed for F22 is not the appropriate text. To be consistent with how F22 is used in the rest of the document, it should say:

"The browser should be able to take advantage
          of available capabilities (supplied by network
          nodes) to prioritize voice, video and data
          appropriately."

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

Write-up by Magnus Westerlund for
draft-ietf-rtcweb-use-cases-and-requirements-14

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational RFC as indicated in header on first page. Appropriate
due to the nature of it describing use-cases and derived requirements
for the WebRTC system.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document discusses a number of usages of browser based
  real-time communication and data transfer capabilities
  and establish requirements for these usages. The document
  is intended to be used both in IETF and W3C during the
  development of the WebRTC specifications.
 

Working Group Summary

  The document has been under development during a longer period
  and a larger number of use cases has been proposed then what
  is included in the document. These that have been included
  has been considered the most basic, most relevant to core
  functionality and without significant controversies.

Document Quality
 
  There has been some concerns about the structure of the document,
  but the WG see no significant need to address this. The document
  is requested to be published as a documentation of the
  core consideration around usages that was of interest during
  the first part of the WebRTC work. The other expected usage of this
  document will be to analyze if the resulting protocol solution
  will enable the considered use cases.
 
  The document has been reviewed and commented on by a significant
  number of people within the WG, including persons active in the W3C
  WEBRTC WG.

Personnel

  Sean Turner is the Document Shepherd. Gonzalo Camarillo and
  Richard Barnes is the Responsible Area Directors.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has review the document in WG last call and again prior
to the publication request. Further the I-D checklist has been manually
checked against the document as well as checking with the ID-Nits tool.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No, and the shepherd doesn't see a need to apply high requirements
regarding document quality to a use-case and requirements document
like this one.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review has been considered required.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, all authors have confirmed that they conform.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure filed.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is a strong consensus and a large number of people have been involved
with the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

ID Nits reports this:

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 6 instances of lines with non-RFC5735-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

This is a false warning due to section references in the document that contains
4 levels of digits.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There are nothing in this document requiring formal review.


(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No RFC will be affected by this documents publication.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This is a use case and requirments document that doesn't define
anything, thus no things specified that requires IANA
registration.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language present.

[Ballot comment]
The change log says that this was done in -11:

  o  Removed the "Conventions" section with the key-words and reference
      to RFC2119.  Also changed uppercase MUST's/SHOULD's to lowercase.

But some of it was reverted: the "Conventions" section and the 2119 reference re-appeared in -12, and remain there in -14.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-rtcweb-use-cases-and-requirements-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Web Real-Time Communication Use-cases and Requirements) to Informational RFC


The IESG has received a request from the Real-Time Communication in
WEB-browsers WG (rtcweb) to consider the following document:
- 'Web Real-Time Communication Use-cases and Requirements'
  as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-04-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes web based real-time communication use-cases.
  Requirements on the browser functionality are derived from the use-
  cases.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

Write-up by Magnus Westerlund for
draft-ietf-rtcweb-use-cases-and-requirements-14

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational RFC as indicated in header on first page. Appropriate
due to the nature of it describing use-cases and derived requirements
for the WebRTC system.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document discusses a number of usages of browser based
  real-time communication and data transfer capabilities
  and establish requirements for these usages. The document
  is intended to be used both in IETF and W3C during the
  development of the WebRTC specifications.
 

Working Group Summary

  The document has been under development during a longer period
  and a larger number of use cases has been proposed then what
  is included in the document. These that have been included
  has been considered the most basic, most relevant to core
  functionality and without significant controversies.

Document Quality
 
  There has been some concerns about the structure of the document,
  but the WG see no significant need to address this. The document
  is requested to be published as a documentation of the
  core consideration around usages that was of interest during
  the first part of the WebRTC work. The other expected usage of this
  document will be to analyze if the resulting protocol solution
  will enable the considered use cases.
 
  The document has been reviewed and commented on by a significant
  number of people within the WG, including persons active in the W3C
  WEBRTC WG.

Personnel

  Magnus Westerlund is the Document Shepherd. Gonzalo Camarillo and
  Richard Barnes is the Responsible Area Directors.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The shepherd has review the document in WG last call and again prior
to the publication request. Further the I-D checklist has been manually
checked against the document as well as checking with the ID-Nits tool.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No, and the shepherd doesn't see a need to apply high requirements
regarding document quality to a use-case and requirements document
like this one.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No special review has been considered required.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, all authors have confirmed that they conform.


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure filed.


(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

There is a strong consensus and a large number of people have been involved
with the document.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

ID Nits reports this:

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 6 instances of lines with non-RFC5735-compliant IPv4 addresses
    in the document.  If these are example addresses, they should be changed.

This is a false warning due to section references in the document that contains
4 levels of digits.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There are nothing in this document requiring formal review.


(13) Have all references within this document been identified as
either normative or informative?

Yes


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No RFC will be affected by this documents publication.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This is a use case and requirments document that doesn't define
anything, thus no things specified that requires IANA
registration.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No formal language present.

A number of editorial comments plus some substantial changes are required prior to a 1 week last call on those changes.

If those changes are accepted, then publication will be requested.