Re: [conex] WGLC for draft-ietf-conex-abstract-mech-06.txt

[John Leslie <[e-mail]>]

[e-mail] <[e-mail]> wrote:
> 
> Looks nice, here are some minor comments 

   I am delighted that Phil has responded -- this document has suffered
from too little feedback for too long. :^(

   Alas, I must honestly say I don't think it's ready to go to the IESG.

   I have over 300 words of red scribble on my paper copy, which I
won't reproduce here. Fundamentally, this document isn't clear about
its aims, leaves the reader guessing at the meaning of some important
terms, and states requirements which probably aren't actually required.

   First and foremost, if it intends to set requirements, that should
be clearly stated in the abstract, and the requirements in question
should either _be_ requirements or exceptions should be noted immediately
withing the listed requirement items.

   Whether or not this is a requirements document, some important terms
are not adequately defined. For example

- "flow" leaves me guessing how any node would decide what is within
  the "flow". Is this source+destination IP addresses? Does it include
  source+destination ports in protocols that have "port"? Does it include
  IPv6 Flow-ID?

- The interaction of "Policy", "Policing", "Audit", "Sanction", and
  "punishment" is (IMHO) to hard for the casual reader to grok. Some
  guidance about this needs to appear in the Introduction.

   The reader finds many things hard to follow without a familiarity
with a number of the Informative references. Informative references
should not be necessary to understanding an RFC (though hopefully
they will _improve_ one's understanding).

   Most network operators will choke at the amount of state this
document suggests maintaining in the Audit function. (Myself, I only
choke when I think of maintaining that much state during DDoS. ;)

   The idea of "Credit" fails to clarify whether the credit should
cover every packet in flight: we've had confusion on-list about that
exact question; and it shouldn't be left an open issue.

   If you persist until near the end of the document, you can find the
expectation that there will be multiple Audit functions along the path,
which mostly give less assurance to Policy functions that the naive
reader would expect. This, IMHO, should be clarified earlier (though
not in the Introduction).

   There are a number of details which discuss IPv4 implementations
of re-ECN, while we are chartered for an IPv6 implementation only.
(I can't guarantee this will upset current IESG members, but it
would have upset the ones that chartered us...)

   "Sanction" being "proportionate" to understatement of congestion
sounds like wishful thinking. With 100% auditing and 100% state,
this could be arranged; but it's pretty clear this document isn't
proposing 100% auditing.

   I don't find the inclusion of "Encodings" other than one we're
likely to use helpful, and I do find them distracting. YMMV, of course.

   The Security Considerations section lists a number if issues which
IMHO deserve to be noted but do not need to be solved (at all) for
an Experimental protocol.

   Most of my detailed comments seem more appropriate to be sent in
private email to a Document Editor (but I shall await WGC guidance
before doing so).

--
John Leslie <[e-mail]>