Mobile Communication Congestion Exposure Scenario
draft-ietf-conex-mobile-06

[Ballot comment]
Thank you for addressing my DISCUSS position comments about the security consideration. I've cleared the DISCUSS. I do have a couple of new comments about the new text in section 6:

The security considerations cited 3 documents as having security considerations that apply to this draft. Those need to be normative references, since they must be read to understand the security considerations. (This shouldn't create a downref problem, since this draft is informational.)

s/"... are discussing additional security considerations... "/"... discuss additional security considerations..."

Previous Comments:


There is an IPR declaration that lists this as an "associated draft". I'm not sure what to make of that, but it was not mentioned in the shepherd review.

This reads much like an advocacy white paper. There's useful information in it, but I would have preferred less of the marketing tone. But that's just me, and I don't expect that to change this late in the process.

[Ballot comment]


- There is a huge amount of sales-speak in this document.  Frankly
there is so much of that here, and no counterpoint nor real analysis
that is technically, but fairly, critical of conex, that this seems
like marketing material. Why are the authors, the WG, the area and
the IETF producing that kind of thing? I'm sure there are good
reasons to produce the material, but I'm not at all sure that ought
be done within the IETF.

- Same IPR comment as Ben's. Were the WG aware?

[Ballot comment]
Not too happy that a document on the IESG table doesn't take into account the shepherd feedback.
See "A few editing nits that should be addressed before final publication: " at https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/shepherdwriteup/, which corresponds to Tim's OPS DIR feedback below.

My review found several issues with the document references and discussions,
and several of them mirror those of the document shepherd.  I suggest the OPs
ADs heed the document shepherd words.

2.3.  Accounting for Congestion Volume

  3G and LTE networks provide extensive support for accounting and
  charging already, for example cf. the Policy Charging Control (PCC)
  architecture.

issue: There is no reference to the PCC architecture, even though its
referenced several times.

Section 2.4:

  [I-D.briscoe-conex-initial-deploy] provides specific examples of how
  ConEx deployments can be initiated, focusing on unilateral

typo: unilateral

3.1.  Possible Deployment Scenarios

  We present three different deployment scenarios for congestion
  exposure in the figures below:

issue: There are 4 items listed numerically below this statement.
Please adjust this.

issue: The drawings are not close to the deployment scenarios. I would
suggest doing the work to include each drawing with the appropriate scenario.

issue: Figures 1-4 refer to objects "UE", "eNB", "S-GW", and "P-GW". These
are not defined in the document anywhere.

6.  Security Considerations

  Security considerations for applying CONEX to EPS include, but are
  not limited to, the security considerations that apply to the CONEX
  protocols.

issue: There should be a reference to the draft that discusses the security
considerations that apply to the CONEX protocols

References:

I-D.briscoe-conex-initial-deploy - "work in progress" is stated, but draft is
expired.

I-D.briscoe-tsvwg-ecn-encap-guidelines - also expired

Appendix B:

    The EPS architecture and some of its standardized interfaces are
    depicted in Figure 1.

This should be Figure 5, which is also distant from the description. More
effort should be used to place descriptions and figures in close
proximity.

[Ballot discuss]
The security considerations section seems substantially incomplete. The phrase "include, but are not limited to" seems to indicate that people thought there were additional considerations. Please write them down, or explain why there really aren't additional considerations.

[Ballot comment]
There is an IPR declaration that lists this as an "associated draft". I'm not sure what to make of that, but it was not mentioned in the shepherd review.

This reads much like an advocacy white paper. There's useful information in it, but I would have preferred less of the marketing tone. But that's just me, and I don't expect that to change this late in the process.

1. Summary

Mirja Kühlewind is the document shepherd and Martin Stiemerling the responsible Area Director.

This document describes deployment scenarios for ConEX in cellular networks. The intention is to inform mobile network operators about possible use cases and therefore this document  is informational. The working group considers this document as important as this is one of the main use cases and initial deployment scenarios for ConEx.

2. Review and Consensus

There was large consents in the working group to adopt and follow-on with this document as this is one of the main initial use cases.

This document has seen 4 revision and was serval times presented in the working group session. There has been no controversial discussion about the document in the meetings or on the list as this document is information and only explains concepts (which are detailed in other ConEx documents) for a different audience. Discussion and feedback mostly (only) led to changes that improve the readability. The document has only seen a small number of reviews but received a detailed review by at least on of the experts in the working group.

The document is written and co-authored by people that are also active in the 3GPP community (which the document is directed to) and therefore does not needed any additional non-working group reviews.

To my knowledge no issues with this document exist.

3. Intellectual Property

All author have confirmed conformance with BCP 78/79 and that there are no IPR disclosures on the document.
Ying Zhang’s email address should be updated in the authors information of the draft.

4. Other Points

This document has no IANA consideration as it is only informational.

Further there is only one normative reference to 'ConEx Concepts and Use Case' RFC (6789). This reference could even be moved to informational as well, however, to get a good understanding of the basic ConEx concept the reading can be recommended.

This document refers multiple times to an expired draft (draft-briscoe-conex-initial-deploy). The authors may consider to remove this reference and add needed text (if any) to this document instead before publication.

The document states that ECN usage is beneficial. However, the document implicitly assume a new ECN feedback that provides more accurate ECN information as currently under standardization in tcpm. This document may state this more explicitly and refer to the accECN requirements document (draft-ietf-tcpm-accecn-reqs-08) which is already in the RFC Editor queue.

A few editing nits that should be addressed before final publication:

- The text in section 3.1 (at the beginning and the end) talks about 3 scenarios while a fourth scenario was added with the last revision. Further it should be mention that the new ConEx-lite scenario can actually be implemeted without the use of the ConEx protocol itself.

- Beginning of section 3 says: "At the time of writing, the CONEX mechanism is still work in progress in the IETF working group." This is not quite true anymore and can be removed.

- End of 3.1 says " A more detailed description will be provided in a future version of this document." This sentence can also be removed.

- Appendix B refers to figure 1 but should refere to figure 5

- The Security Considerations section says: "Security considerations for applying CONEX to EPS include, but are not limited to, the security considerations that apply to the CONEX protocols." The "not limited to"-part sounds to me like there are security considerations missing. However, this document has no need to discuss security consideration as it is only informational. Therefore this sentence should be removed.

These are really only nits that have been overlooked in the final revision and can easily be applied with a next revision after IESG review. Otherwise the document is well written and very nice to read.

The idnits check mentioned outdated reference:

  == Outdated reference: A later version (-04) exists of
    draft-briscoe-tsvwg-ecn-encap-guidelines-03

  == Outdated reference: A later version (-13) exists of
    draft-ietf-conex-abstract-mech-08

  == Outdated reference: A later version (-08) exists of
    draft-ietf-conex-destopt-05
   
However, all these docs are close to publication and the references should anyway be replaced by the respective RFC before publication.

1. Summary

Mirja Kühlewind is the document shepherd and Martin Stiemerling the responsible Area Director.

This document describes deployment scenarios for ConEX in cellular networks. The intention is to inform mobile network operators about possible use cases and therefore this document  is informational. The working group considers this document as important as this is one of the main use cases and initial deployment scenarios for ConEx.

2. Review and Consensus

There was large consents in the working group to adopt and follow-on with this document as this is one of the main initial use cases.

This document has seen 4 revision and was serval times presented in the working group session. There has been no controversial discussion about the document in the meetings or on the list as this document is information and only explains concepts (which are detailed in other ConEx documents) for a different audience. Discussion and feedback mostly (only) led to changes that improve the readability. The document has only seen a small number of reviews but received a detailed review by at least on of the experts in the working group.

The document is written and co-authored by people that are also active in the 3GPP community (which the document is directed to) and therefore does not needed any additional non-working group reviews.

To my knowledge no issues with this document exist.

3. Intellectual Property

All author have confirmed conformance with BCP 78/79 and that there are no IPR disclosures on the document.
Ying Zhang’s email address should be updated in the authors information of the draft.

4. Other Points

This document has no IANA consideration as it is only informational.

Further there is only one normative reference to 'ConEx Concepts and Use Case' RFC (6789). This reference could even be moved to informational as well, however, to get a good understanding of the basic ConEx concept the reading can be recommended.

This document refers multiple times to an expired draft (draft-briscoe-conex-initial-deploy). The authors may consider to remove this reference and add needed text (if any) to this document instead before publication.

The document states that ECN usage is beneficial. However, the document implicitly assume a new ECN feedback that provides more accurate ECN information as currently under standardization in tcpm. This document may state this more explicitly and refer to the accECN requirements document (draft-ietf-tcpm-accecn-reqs-08) which is already in the RFC Editor queue.

A few editing nits that should be addressed before final publication:

- The text in section 3.2 (at the beginning and the end) talks about 3 scenarios while a fourth scenario was added with the last revision. Further it should be mention that the new ConEx-lite scenario can actually be implemeted without the use of the ConEx protocol itself.

- Beginning of section 3 says: "At the time of writing, the CONEX mechanism is still work in progress in the IETF working group." This is not quite true anymore and can be removed.

- End of 3.1 says " A more detailed description will be provided in a future version of this document." This sentence can also be removed.

- Appendix B refers to figure 1 but should refere to figure 5

- The Security Considerations section says: "Security considerations for applying CONEX to EPS include, but are not limited to, the security considerations that apply to the CONEX protocols." The "not limited to"-part sounds to me like there are security considerations missing. However, this document has no need to discuss security consideration as it is only informational. Therefore this sentence should be removed.

These are really only nits that have been overlooked in the final revision and can easily be applied with a next revision after IESG review. Otherwise the document is well written and very nice to read.

The idnits check mentioned outdated reference:

  == Outdated reference: A later version (-04) exists of
    draft-briscoe-tsvwg-ecn-encap-guidelines-03

  == Outdated reference: A later version (-13) exists of
    draft-ietf-conex-abstract-mech-08

  == Outdated reference: A later version (-08) exists of
    draft-ietf-conex-destopt-05
   
However, all these docs are close to publication and the references should anyway be replaced by the respective RFC before publication.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-conex-mobile-05, which is currently in Last Call, and has the following comments:

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

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not 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:  (Mobile Communication Congestion Exposure Scenario) to Informational RFC


The IESG has received a request from the Congestion Exposure WG (conex)
to consider the following document:
- 'Mobile Communication Congestion Exposure Scenario'
  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 2015-09-03. 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 memo describes a mobile communications use case for congestion
  exposure (ConEx) with a particular focus on those mobile
  communication networks that are architecturally similar to the 3GPP
  Evolved Packet System (EPS).  The draft provides a brief overview of
  the architecture of these networks (both access and core networks),
  current QoS mechanisms and then discusses how congestion exposure
  concepts could be applied.  Based on this, this memo suggests a set
  of requirements for ConEx mechanisms that particularly apply to these
  mobile networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-conex-mobile/ballot/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/1922/

1. Summary

Mirja Kühlewind is the document shepherd and Martin Stiemerling the responsible Area Director.

This document describes deployment scenarios for ConEX in cellular networks. The intention is to inform mobile network operators about possible use cases and therefore this document  is informational. The working group considers this document as important as this is one of the main use cases and initial deployment scenarios for ConEx.

2. Review and Consensus

There was large consents in the working group to adopt and follow-on with this document as this is one of the main initial use cases.

This document has seen 4 revision and was serval times presented in the working group session. There has been no controversial discussion about the document in the meetings or on the list as this document is information and only explains concepts (which are detailed in other ConEx documents) for a different audience. Discussion and feedback mostly (only) led to changes that improve the readability. The document has only seen a small number of reviews but received a detailed review by at least on of the experts in the working group.

The document is written and co-authored by people that are also active in the 3GPP community (which the document is directed to) and therefore does not needed any additional non-working group reviews.

To my knowledge no issues with this document exist.

3. Intellectual Property

All author except Ying Zhang have confirmed conformance with BCP 78/79 and that there are no IPR disclosures on the document. Ying Zhang’s email address (ying.zhang@ericsson.com) is not valid anymore as she left Ericsson. I’m still trying to get a new email address to contact here. This should potentially also be updated in the authors information of the draft.

4. Other Points

This document has no IANA consideration as it is only informational.

Further there is only one normative reference to 'ConEx Concepts and Use Case' RFC (6789). This reference could even be moved to informational as well, however, to get a good understanding of the basic ConEx concept the reading can be recommended.

This document refers multiple times to an expired draft (draft-briscoe-conex-initial-deploy). The authors may consider to remove this reference and add needed text (if any) to this document instead before publication.

The document states that ECN usage is beneficial. However, the document implicitly assume a new ECN feedback that provides more accurate ECN information as currently under standardization in tcpm. This document may state this more explicitly and refer to the accECN requirements document (draft-ietf-tcpm-accecn-reqs-08) which is already in the RFC Editor queue.

A few editing nits that should be addressed before final publication:

- The text in section 3.2 (at the beginning and the end) talks about 3 scenarios while a fourth scenario was added with the last revision. Further it should be mention that the new ConEx-lite scenario can actually be implemeted without the use of the ConEx protocol itself.

- Beginning of section 3 says: "At the time of writing, the CONEX mechanism is still work in progress in the IETF working group." This is not quite true anymore and can be removed.

- End of 3.1 says " A more detailed description will be provided in a future version of this document." This sentence can also be removed.

- Appendix B refers to figure 1 but should refere to figure 5

- The Security Considerations section says: "Security considerations for applying CONEX to EPS include, but are not limited to, the security considerations that apply to the CONEX protocols." The "not limited to"-part sounds to me like there are security considerations missing. However, this document has no need to discuss security consideration as it is only informational. Therefore this sentence should be removed.

These are really only nits that have been overlooked in the final revision and can easily be applied with a next revision after IESG review. Otherwise the document is well written and very nice to read.

The idnits check mentioned outdated reference:

  == Outdated reference: A later version (-04) exists of
    draft-briscoe-tsvwg-ecn-encap-guidelines-03

  == Outdated reference: A later version (-13) exists of
    draft-ietf-conex-abstract-mech-08

  == Outdated reference: A later version (-08) exists of
    draft-ietf-conex-destopt-05
   
However, all these docs are close to publication and the references should anyway be replaced by the respective RFC before publication.