[Ietf-not43] example changes

[Leslie Daigle]

Hmmm.  I agree that splitting these sections allows clarity.

I'm not convinced (from these 2 examples) that the first on is
really "protocol".

Comments inline:

Andrew Newton wrote:
> Based on the point of the MUST/SHOULD language as it relates to protocol 
> requirements and service descriptions, I thought I'd throw a few samples 
> out just to show what am doing.  If you have objections or suggestions, 
> please speak now.
> 
> 
> Example 1:
> 
> Before:
> 3.1.1 Mining Prevention
> 
>    The protocol MUST have a mechanism to limit the amount of data that
>    may be accessed.  The service may have different limits for different
>    types of data, as well as for authenticated and non-authenticated
>    entities.  The protocol SHOULD be capable of expressing to the client
>    these access limitations based on queries per session per unit of
>    time, queries per source IP address per unit of time, and total
>    queries from all client sessions per unit of time.  The service
>    should be able to limit the amount of data based on the above types
>    of limitations.
> 
> After:
> 3.1.1 Mining Prevention
> 
> 3.1.1.1 Protocol Requirement
> 
>    The protocol MUST have a mechanism to limit the amount of data that
>    may be accessed.  The protocol SHOULD be capable of expressing to the
>    client these access limitations based on queries per session per unit
>    of time, queries per source IP address per unit of time, and total
>    queries from all client sessions per unit of time.

I don't see where there is (necessarily) a protocol issue in limiting
the amount of data that is accessed.  The protocol exists to transmit
requests and responses; I don't see why it is not possible to have
a protocol that has NO concept of limits (except the ability to return
a message indicating the fact that the server hit one).


> 
> 3.1.1.2 Service Description
> 
>    The limits placed on differing types of data or applied depending
>    upon access status will most likely differ from server to server
>    based on policy and need.  Servers should express these limitations
>    to the client if policy allows.
> 
> 
> Example 2:
> 
> Before:
> 3.1.7 Decentralization
> 
>    The service must be decentralized in design and principle and must
>    not require the aggregation of data to a central repository, server,
>    or entity.  The service may allow for the optional aggregation of
>    data indexes or hints.  The protocol MUST NOT require aggregation of
>    data indexes or hints.
> 
> After:
> 3.1.7 Decentralization
> 
> 3.1.7.1 Protocol Requirement
> 
>    The protoocl MUST NOT require the aggregation of data to a central
>    repository, server, or entity.  The protocol MUST NOT require
>    aggregation of data indexes or hints to a central repository, server,
>    or entity.

Again, it seems stilted at best to think of the protocol requiring
aggregation of data to a central repository.

When you're using "protocol" here, do you mean "on the wire protocol"
(which is what seems to be the usual use of the word),
or are you trying to talk about the server implementation?  the
conventions or use of a protocol to implement a service? or...?  If
not the first, a different word/phrase would be helpful.

Leslie.