Re: [sidr] Soliciting agenda ideas for Vancouver

Hi Rob,

Sorry for the belated reply.

In short I support pursuing this work and prefer separating the publication protocol parts from the config protocol.

It may indeed be helpful if you did a short presentation on this to refresh the WG memory.

More details inline.

On Oct 20, 2013, at 10:03 AM, Rob Austein <sra@hactrn.net> wrote:

> Sam and I think we probably should say something about
> draft-ietf-sidr-publication, if only we knew what.
> 
> I just submitted -04, partly to get the expired draft back in front of
> people's eyes, partly to address formatting issues that made the
> schema and examples unnecessarily hard to read.  An rfcdiff of the
> changes is available at:
> 
> http://subvert-ietf.hactrn.net/sidr-publication/draft-ietf-sidr-publication-04-from-3.diff.html
> 
> The question for the WG, though, is where we want to go with this
> draft.  It's not dead: my implementation uses an old version of it,
> Tim based parts of draft-tbruijnzeels-sidr-delta-protocol on it, and
> at one point the WG agreed that it was a useful tool to have in the
> box, which is why it's a WG document.  But it has not gotten a lot of
> traction recently.  We suspect this is because interoperable
> publication service is not currently on anybody's critical path.

Indeed, setting up or using a publication service is not on our critical path.

> Tim suggested to me at one point that perhaps we should drop the
> entire control sub-protocol from this draft, leaving just the
> publication sub-protocol.  This seems worth discussing.

The delta protocol document is based on the publication parts of the document only. The idea being that, if a standard publication protocol exists, it would be good to minimise the additional work that a publication server would have to do produce deltas. Re-using the existing publish/withdraw messages one to one is one way to achieve this. It means less work for the server, and less work trying to re-define this in standards.

This approach does mean that some delta concerns may want to be addressed in this document. I already raised a few ideas in person with Rob. I can raise them again, but I would prefer to do that in a separate thread and when the document is split (if indeed the authors and wg agree with that idea).

> We included the control protocol in the original draft because the only existing
> implementation (mine) uses it, but one could make a reasonable case
> that it's only the publication sub-protocol which brings any real
> value as an open public standard.

I found the control sub-protocol a bit confusing, and I just don't understand it well enough to judge whether it's re-usable and should be standard, or if you're only documenting your implementation. In either case I am in favour of smaller documents addressing only a specific problem, and therefore separating this work, in standards track if it's re-usable, or informational (but up to you of course if you want to do the work) in the other case.

> 
> For the record, this agenda request and the -04 version come from two
> of the draft's three authors.  We have a query out to our third
> co-author, but have not yet heard back, so please blame anything to do
> with this draft since -03 on me and Sam.
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr