Hello again folks,

I can't type in all the editorial suggestions right now, but at least
I wanted to provide some overall comments that cause the
document to seem quite inaccurate in many of its claims.
Here are my general comments.

- The requirements need to be distinguished from the desirable features.
For instance, section 4.7 describes a desirable feature, not a requirement.
  Moreover, the desirable feature may be unattainable.  This is important,
  because if feature is *required*, a solution not providing the *required*
  feature "must" be considered incomplete and rejected.

- The problem statement clauses should be located in an initial section.
  Each problem statement should have a motivation.

- There is no problem statement supporting sections 4.4 or 4.6

- There is no motivation for section 4.4

- There is nothing specific to DMM in sections 4.4 or 4.6

- Section 5 should cross-reference section 4.6, and they should both
  be rewritten to eliminate redundant extra verbiage of which there is
  too much.

- PS7 claims that deployment (of "something":  existing IETF solutions?)
  is too complicated.  Compared to what???  3GPP solutions?? Dozens
  of incompatible clunky slow portal authentication design botches?
  This point strikes me as basically wrong, but it can be rescued if a
  target level of deployment complexity is described.

- REQ3 claims that we should target IPv6 because of tools available for IPv6
  that are not available for IPv4.  Please identify at least one.

- Section 1 claims that user traffic patterns have shifted to become
  more localized.  This is probably false, but I can imagine several
  ways to change it so that it becomes true.  It is important for this
  purpose to clarify what is intended by "peer communications".

- What is an "IP session"?  Wasn't IP supposed to be connectionless?
  I strongly suggest not trying to define such a thing.  Perhaps it
  was intended to indicate a "flow" instead.

- It is claimed that a centralized architecture requires more resources
  than a distributed architecture.  This is usually false.  For instance,
  if a centralized node requires 100 units, and 100 distributed nodes each
  require 1.03 units, the distributed architecture requires 3 more units
  overall.  Even so, the additional expense of the distributed architecture
  would often be a bargain for reasons of redundancy, resiliency, etc.

I will do the editorial suggestions tomorrow.  Also I can volunteer to
rewrite various parts if extra effort is needed.

Regards,
Charlie P.


On 4/24/2013 2:14 PM, Charles E. Perkins wrote:
Hello folks,

I have many editorial comments which I will submit later today.

However, I think the draft has a major organizational problem. Namely,
the "problem statements", instead of being properly collected together
in an initial section, are sprinkled in along with various statements of
requirements.

I remember there was previously a problem statement draft that
enumerated the PSs in the current requirements draft.  I think it is
O.K. (perhaps not optimal, but O.K.) for the problem statements to
be in the requirements draft, but not as currently situated.

This, along with the various other editorial clarifications that are
needed, lead me to believe that the draft is not yet ready, but I do
not think that there are major problems, and that the next draft
probably could be ready for advancement.

Regards,
Charlie P.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm



--
Regards,
Charlie P.

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm

Reply via email to