Re: [conex] I-D Action: draft-ietf-conex-concepts-uses-03.txt

[Alissa Cooper <[e-mail]>]

Hi John,

Thanks for your comments. I have some responses inline and I've also added the issues you raise to trac (http://trac.tools.ietf.org/wg/conex/trac/report/1)

On Oct 25, 2011, at 4:25 PM, John Leslie wrote:
>> 
> I have several issues which deserve discussion here.
> 
>   concepts-uses still ventures farther into mechanism than I'd wish:
> 
>   - "the ConEx Field" implies mechanism; I suggest "ConEx marking".

Fine with me.

>   - "Network provider (or operator)" doesn't work as a definition:
>     I suggest defining "Network Operator (or Provider), and fixing
>     the various places which use these words ambiguously.

Fine with me.

> 
>   - The "User" definiton hides something a bit counter-intuitive:
>     that the sending user is known in some places, the receiving
>     user in others, and neither is knowable in the middle. While
>     the definiton here is probably as good as we can get, I'm
>     afraid our readers will be confused.

If there are specific instances of "user" that you think might cause confusion, that would be helpful to know. At least in 3.1 (where it probably matters the most), I think it's fairly clear that the network operator will be drawing conclusions about its own users.

> 
>   - "Congestion Policer" is not defined.

The editors had some discussion about whether this is necessary. If most people think it is, we can add it. A suggestion:

Congestion policer (discussed in 3.1): A logical entity that allows a network operator to monitor each user's congestion-volume and enforce congestion-volume limits.

> 
>   - In Section 3.1, the general-case description of policer (the
>     second paragraph) is describing mechanism better left to a
>     different I-D. OTOH, the fourth and fifth paragraph are an
>     example appropriate for this document (especially since it
>     is the case found in our Charter).

I think it's hard to understand the last paragraph without explaining at a high level how a congestion policer might work. Perhaps we can split the difference by making it more clear that the token bucket description is an example (i.e., "one way to implement a congestion policer" instead of "a congestion policer can be implemented").

Thanks,
Alissa

> 
> --
> John Leslie <[e-mail]>
>