Subject: [Ietf-not43] example changes

From: [email-masked] (Andrew Newton)
Date: Thu, 23 Jan 2003 14:23:01 -0500

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.

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.

3.1.7.2 Service Description

    Some server operators may have a need to coordinate service in a mesh
    or some other framework with other server operators.  However, the
    ability to operate a CRISP compliant server should not require this.

-andy

---

From: [email-masked] (Leslie Daigle)
Date: Sat, 25 Jan 2003 16:48:36 -0500

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:

>    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).

>    aggregation of data indexes or hints to a central repository, server,

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.

---

From: [email-masked] (Andrew Newton)
Date: Tue, 28 Jan 2003 03:19:52 -0500

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zak-11935-1043742244-0001-2
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

> a message indicating the fact that the server hit one).

Well, it very well could be that the protocol has explicit timing 
considerations or paged results, or some other thing that is definitly 
part of the protocol.  The actual "limit-exceeded" requirement, which is 
part of the protocol, is covered under a different requirement already.

However, the above is all speculation.  The truth is that this is an 
outgrowth of what is currently happening with whois/port 43 with regard 
to throttling.  And that throttling is not part of 954.  So it may not 
be necessary for CRISP as well (as part of the spec).

So I see your point.  But I see three ways to change it:
1) Change the MUST to a SHOULD.
2) Remove the 3.1.1.1 language and just leave 3.1.1.2 so that people 
understand that such things might happen but are not explicitly part of 
the protocol.
3) Remove 3.1.1 completely.

I'm in favor of #2 or #3.

> not the first, a different word/phrase would be helpful.

I was thinking of "on-the-wire" protocol.  However, I still think this 
is needed.  While it seems a little rediculous, lets remember that 954 
would require aggregation of data to meet certain service models.  A 
CRISP protocol with improperly specified referrals (such as the omission 
of an authority component in a URI, or worse, a hard-coded authority 
component in a URI) would also not pass this test.

So I agree this might be a little on the paranoid side, but I think it 
should stay.

-andy

--=_zak-11935-1043742244-0001-2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--=_zak-11935-1043742244-0001-2--