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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
