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

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.

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.

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