[H-GEN] Does anyone have experience with the IETF process?

[Benjamin Carlyle]

On Tue, 2006-10-17 at 03:25 +0200, Bruce Campbell wrote:
> On Mon, 16 Oct 2006, Benjamin Carlyle wrote:
> > http://soundadvice.id.au/blog/draft-carlyle-sena-00.txt
...
> > draft. I would also welcome suggestions as to how to proceed from here.
> Start at http://www.rfc-editor.org/ , and look for the guidelines 
> regarding the submission of internet drafts.  If you are intending it as a 
> strawman, doing it as an individual draft would be the best.

Thanks. I had started my reading at RFC2026, and had missed a few useful
links on this page.

> > Does the world need this extension? I think so. There has been increased
> > chatter about subscription and notification since work on atom
> > concluded. There is talk particularly in financial markets about
> > ensuring information is available in a timely and fair manner.
> 
> Ok, comments.  What identifies a particular client?  There is a basic 
> dialback mechanism designed to reduce instances of amplification attacks, 
> but when there are thousands of clients appearing to the server from one 
> IP address (eg, web proxy), what criteria does the server use to block 
> SUBSCRIBE requests until a successful notification has been performed?

Well, the call-back URL identifies the client insofar as such an
identification exists. I would assume that the same kind of blocking
policy would be applied to SUBSCRIBE as is currently applied to GET
requests. SUBSCRIBE consumes server-side resources, so I guess you are
asking about how to fairly allocate those resources between clients.

Being a layered protocol HTTP doesn't really have a notion of client per
se, and I'm not sure this extension is in any position to define such a
notion. I don't think that this draft would make that situation much
worse than what we see today with GET. Do you have an alternative view?

> Secondly, although presumably you intend that standard HTTP authorisation 
> mechanisms be used to determine access to a given resource, this needs to 
> be explicitly stated, lest your name be strung in effigy across multiple 
> mailing lists.

I have toned down the up-front assertion of "security measures" to
simply "dial-back". Under 11.5 Other considerations I have added the
text:

"No new authorization or authentication mechanisms are introduced by
this draft. Existing authentication and authorization mechanims SHOULD
be applied by resources that handle SUBSCRIBE or NOTIFY methods to
prevent unauthorized access."

Is this clear enough, do you think? Do I need to be more explicit
generally about the relationship to RFC2616?

> Thirdly, the time interval to expire subscriptions should be able to be 
> negotiated between the client and server, both in the SUBSCRIBE request, 
> and the NOTIFY response.

This was how the earlier gena protocol worked. However, I have tried to
avoid any explicit renewal activity in the subscription model. Renewal
exists for two reasons: for the client to ensure the subscription is
still operating and for the server to ensure its resources are not being
tied up at the behest of a client that has forgotten about it. GENA
would require client and server to negotiate a time interval, then all
subscriptions would have to be renewed. This creates a periodic flood of
requests at possibily inopportune times, especially when a few thousand
subscriptions are active between a particular client and server pair.

My solution is to move responsibility to the server. The client doesn't
need to sample the state of the subscription because under all normal
circumstances the server is required to maintain it. Rather than the
client trying to remotely ensure its survival across server-side failure
events at significant bandwith cost, the server is responsible. The
server's need to sample the state can be in the form of a simple
keepalive request that will be treated as spam or time out if the client
is not there. I have reworded and reorganised the Subscription Lifetime
section slightly to reflect this.

As it is only the server's needs that are being fulfilled by the
selection of the keep-alive interval, there is no negotiation between
client and server as to what the interval should be.

> Fourthly, the examples need to properly identify the conversation flow; 
> ie, did the client say that, or did the server?

Clarified.

> Fifthly, the DELETE command has already been used.  See RFC2518, Webdav.

I'm not sure I follow. DELETE is part of RFC2616, HTTP/1.1. I believe
I'm using it as per the specification.

> Sixthly, I do not think it is a good idea for the NOTIFY requests to 
> contain the full notification.  For example, just say I use the dyndns 
> service to set up a subscription of a large dataset to a particular name 
> to my IP, eg, the call-back goes to http://evil.dyndns.example.org/notify 
> (1.2.3.4).  I then point that name to another IP address, 4.3.2.1 .  Your 
> server has just participated in a DoS against someone at 4.3.2.1 .
> 
> Rather, the NOTIFY should simply indicate that the resource has been 
> updated, and the client can then request it at its lesiure;  it may be 
> something done under user direction.

I had thought about this approach in the past and dismissed, but I'll
revisit it. My current scratchpad includes:
Pros:
* Deals with content negotiation much better than current approach
* As you say, a large resource is less likely to be spammed out to
someone on dialup or a slow radio link
Cons:
* Extra network latency: NOTIFY, GET, GET Response vs just NOTIFY
* Inability to perform patch updates, eg 10000 line alarm list that just
had a single alarm acknowledged

What you are suggesting would essentially reduce the proposal down to a
cache invalidation protocol, which has interesting implications. One
that I would be concerned about is how the Internet would migrate from
the current expiry models to also supporting this expiry model. And
end-to-end approach wouldn't work without the client requesting a cache
bypass of intermediaties between it and the origin server. However, once
the intermediataries along the way become aware of the protocol you
don't want a simple cache bypass. You want the second client of a
particular intermediatary to get the cached entry that the first client
got. Maybe proxies could ignore cache bypass instructions when they have
a subscription to the origin resource and know it hasn't changed.

I'll do some more thinking.

> > non-standard forms written several times. JEP-0060 is trying to
> > standardise a subscription mechanism over XMPP, but is based on what I
> > think are unworkable foundations when it comes to high volume
> > internet-scale traffic.
> I'd re-read JEP-0060 and associated discussion, and see what they've 
> covered regarding client identity and denial of service.

Hrrm.. It seems to have gone offline for the moment. I'll have a look at
it again when I get the chance. What JEP-0060 doesn't provide as far as
my earlier reading indicated is self-descriptive messages. It doesn't
appear to be possible for anyone other than the publisher to fold the
notifications. I believe this means any intermediatary needs an infinite
buffer in order to deliver messages to clients, or it must boot clients
off the notification list when it hits the end of its buffer. This is
the core problem I'm interested in solving.

Benjamin.