[Ietf-not43] example changes

Andrew Newton anewton@ecotroph.net
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

Leslie Daigle wrote:
>> 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).

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.

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

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJgjCC
Ax8wggKIoAMCAQICAwgtAzANBgkqhkiG9w0BAQQFADCBkjELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUx
HTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVl
bWFpbCBSU0EgMjAwMC44LjMwMB4XDTAyMDgzMDAxMzA0N1oXDTAzMDgzMDAxMzA0N1owXzEP
MA0GA1UEBBMGTmV3dG9uMQ8wDQYDVQQqEwZBbmRyZXcxFjAUBgNVBAMTDUFuZHJldyBOZXd0
b24xIzAhBgkqhkiG9w0BCQEWFGFuZXd0b25AZWNvdHJvcGgubmV0MIIBIjANBgkqhkiG9w0B
AQEFAAOCAQ8AMIIBCgKCAQEAuYBxNZFmUWWS+dN6aBcGmYEiGRzoS+MAPLzsamlpAe45HLyM
qi/jMkYGTFFqQewAfq6m6Bqe8GvOQhauFdhXxXF2fuprkxsTDYBazTV9edsH4v1nwBNrTtjn
O90klF2JYae3lxLq9VmnrAy0BMMeiI5W5KG59deSlfLfYrNUKgrJWRG0n+lDoqDUlhsY3Rlp
1V8vyjdkQ6lhJEzQNWnuUAgqWYNlUuZ05gEImorARY4/etptL4+uLZvkKFwq+TJKGHizTayn
m2fCGRrubG2+rd0OE4QclA8H4Y8P8txrnT/2N47JjUDH47u5VjnpSPa5hfmuNrA8v1AoDbx/
Qe0LHQIDAQABozEwLzAfBgNVHREEGDAWgRRhbmV3dG9uQGVjb3Ryb3BoLm5ldDAMBgNVHRMB
Af8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAM9earp4VZUSsCJVLoWh/GOTdLCmdCGu4lzmLDqH
maXGZVeyL+7YViaNHD/QfndxnOmk7+dEEr4t8y8cfeiIs//E9V8t59iB13PZi3PR0FFR8w58
YtE51QQiKdXZWw8Q5QzJKbmAN0q5jiTqBGY510/Kst4VzsHtwwNKPdn+QsFVMIIDHzCCAoig
AwIBAgIDCC0DMA0GCSqGSIb3DQEBBAUAMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz
dGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE
CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJT
QSAyMDAwLjguMzAwHhcNMDIwODMwMDEzMDQ3WhcNMDMwODMwMDEzMDQ3WjBfMQ8wDQYDVQQE
EwZOZXd0b24xDzANBgNVBCoTBkFuZHJldzEWMBQGA1UEAxMNQW5kcmV3IE5ld3RvbjEjMCEG
CSqGSIb3DQEJARYUYW5ld3RvbkBlY290cm9waC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQC5gHE1kWZRZZL503poFwaZgSIZHOhL4wA8vOxqaWkB7jkcvIyqL+MyRgZM
UWpB7AB+rqboGp7wa85CFq4V2FfFcXZ+6muTGxMNgFrNNX152wfi/WfAE2tO2Oc73SSUXYlh
p7eXEur1WaesDLQEwx6Ijlbkobn115KV8t9is1QqCslZEbSf6UOioNSWGxjdGWnVXy/KN2RD
qWEkTNA1ae5QCCpZg2VS5nTmAQiaisBFjj962m0vj64tm+QoXCr5MkoYeLNNrKebZ8IZGu5s
bb6t3Q4ThByUDwfhjw/y3GudP/Y3jsmNQMfju7lWOelI9rmF+a42sDy/UCgNvH9B7QsdAgMB
AAGjMTAvMB8GA1UdEQQYMBaBFGFuZXd0b25AZWNvdHJvcGgubmV0MAwGA1UdEwEB/wQCMAAw
DQYJKoZIhvcNAQEEBQADgYEAz15qunhVlRKwIlUuhaH8Y5N0sKZ0Ia7iXOYsOoeZpcZlV7Iv
7thWJo0cP9B+d3Gc6aTv50QSvi3zLxx96Iiz/8T1Xy3n2IHXc9mLc9HQUVHzDnxi0TnVBCIp
1dlbDxDlDMkpuYA3SrmOJOoEZjnXT8qy3hXOwe3DA0o92f5CwVUwggM4MIICoaADAgECAhBm
RXK3zHT1z2N2RYTQLpEBMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBD
b25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQw
IgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBl
cnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDAwODMwMDAwMDAwWhcNMDQwODI3MjM1
OTU5WjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
Q2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZp
Y2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQDeMzKmY8cJJUU+0m54J2eBxdqIGYKXDuNEKYpjNSptcDz6
3K737nRvMLwzkH/5NHGgo22Y8cNPomXbDfpL8dbdYaX5hc1VmjUanZJ1qCeu2HL5ugL217CR
3hzpq+AYA6h8Q0JQUYeDPPA5tJtUihOH/7ObnUlmAC0JieyUa+mhaQIDAQABo04wTDApBgNV
HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMS0yOTcwEgYDVR0TAQH/BAgwBgEB
/wIBADALBgNVHQ8EBAMCAQYwDQYJKoZIhvcNAQEEBQADgYEAMbFLR135AXHl9VNsXXnWPZjA
JhNigSKnEvgilegbSbcnewQ5uvzm8iTrkfq97A0qOPdQVahs9w2tTBu8A/S166JHn2yiDFiN
MUIJEWywGmnRKxKyQF1q+XnQ6i4l3Yrk/NsNH50C81rbyjz2ROomaYd/SJ7OpZ/nhNjJYmKt
BcYxggMnMIIDIwIBATCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw
ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp
ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44
LjMwAgMILQMwCQYFKw4DAhoFAKCCAWEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDMwMTI4MDgxOTUyWjAjBgkqhkiG9w0BCQQxFgQU+YwOcFA0SGdzGWFr
Q+qP9n5TOyAwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwga0GCyqGSIb3DQEJEAIL
MYGdoIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vy
dmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwgtAzAN
BgkqhkiG9w0BAQEFAASCAQA2/8Ah3jLF3ReW+HQh5pL7Z2YkgrGMaoWictGs0Pj1v0bl6O4K
ixhzU4aFCLcO5KqpWzKT+ay/g7iQdBP/tghsOjgB7xmSMRYGhIgHhx7mWPOWWb+DBUWZRsmz
AE2g4zn0UGcTSeUSqTuebIH1mDzKmTWY+H8vZI7E01WAyAWC1ra7jqFTxxDI7SBdH+5R1udy
sGId0I8aQrGdsCDoHrwRvtFFXn4kx2YoMLNKVnrjk3/L+XLXuPm0DreP69Vt/SFv6/8FxZAg
ZuV/NXCCDqoOFg0dL8wfyoG5dg8z9GUxJPA4v6yUXPzdmz2hC0FXwR/neROgPiFX4uuDjwer
4QI+AAAAAAAA
--=_zak-11935-1043742244-0001-2--