On Jan 23, 2012, at 6:38 , Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 01/22/2012 08:44 PM, Cullen Jennings wrote: >> >> >> On Jan 20, 2012, at 14:32 , Marc Petit-Huguenin wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> On 01/17/2012 06:43 PM, Cullen Jennings wrote: >>>> >>>> We believe this revision addresses the following DISCUSS comments: >>>> >>>> Jari Arkko Adrian Farrel Robert Sparks Peter Saint-Andre Dan Romascanu >>>> Russ Housley >>>> >>>> Note: we did not address non-DISCUSS comments. We are planning to do >>>> that on a subsequent pass. >>>> >>>> Most of the changes are editorial/clarifying, however, a number were >>>> substantive (though generally not breaking). Here's a summary of what >>>> we believe the major ones are: >>>> >>>> * Changed the certificate enrollment protocol to remove the password >>>> from the URL. Note that this is a breaking change. >>>> >>>> * Globally renamed "private id" and "compressed id" to "opaque id" >>>> >>>> * Specified the details of the overlay name (S 5.3.2) >>>> >>>> * Nailed down the fragment semantics, harmonizing between the fragment >>>> field defn. and the rules for generating fragments. The high bit must >>>> always be set and unfragmented packets are represented as the last >>>> fragment with an offset of 0. >>>> >>>> * Specified new requirements for malicious loop prevention: >>>> >>>> - Configuration servers are supposed to set TTL based on overlay size. >>>> - Peers must check that TTL never exceeds the configured maximum. - >>>> Peers should check for duplicates in the destination list. >>>> >>>> * Added a new Error_Invalid_Message generic error code. >>>> >>>> In terms of schedule, we plan to spin a new draft before the draft >>>> deadline that addresses all the DISCUSS comments and as many of the >>>> comments as possible. >>>> >>> >>> I hate to be the one complaining again, but because the "final" draft >>> will be released around March 11th, there will be only 2 weeks to >>> review, implement, and try to fix it before the P2PSIP meeting itself and >>> we all know how busy these few weeks before a meeting are. My prediction >>> is that the meeting will be simply a list of issues or fixes that people >>> will have no time to analyze and understand and that this meeting will >>> be, like the one in Taipei, a waste of time. Won't it be more efficient >>> to finish this now, which would give two months to be sure that >>> everything is OK, and declare victory in Paris? >>> >> >> >> If anyone wants to help, we'd love some help. The problem is several of us >> are wrapped up in the W3C WebRTC and IETF RTCWeb interim meetings from now >> till Feb 1 so I suspect that there will not be time put into it for the >> next 10 days unless someone else does something. My fear is it would take >> too long for most people to get up to speed on it. We did try to order the >> discusses such that we fixed one that might impact implementations first. >> > > Just after the meeting in Taipei, I was trying to convince someone to come to > the RELOAD interop event in Paris. The response was that the implementation > will not be ready in time, because they will not start until RELOAD is > finished. I understand - when I saw -20 I was ready to do a complete review > and to update my code, but after seen your email, I stopped bothering, I'll > just wait for -21. Or -22. Or -23, it's a prime number and I like prime > numbers. >
The draft will be done when it is an RFC. Obviously implementation of intermedia drafts is good. > Also I have unpublished drafts that I am holding because it is not possible to > present anything new at a WG meeting - what's the point anyway if the response > is invariably "we need to finish RELOAD first"? People were objecting to new work until the draft had been send to IESG. That has happened. I don't see any objections to new work in the WG. > People are now presenting > their drafts in samrg, I'll probably do that too, and skip the p2psip meeting. I'd present them anywhere you thought you had the right people to review them and build consensus around them. For some drafts, samrg may be a great place - for others - likely a bad place. > > On the other hand I completely understand the pressure of other works and that > nobody can sustain the same interest and enthusiasm on a specific subject for > the many years that are required to standardize anything. My first draft on this was published in 2005. Work on pre socialization of Reload/Vipr/Location Anonymization started well before them. I imagine that it will be somewhere around 2015 when all the key drafts for Reload / Vipr will be done and if we go forward with Location Anonymization that will like be after 2020 before it is an RFC. Given that is the type of time frame it takes, Cisco prefers for me to on several things in parallel. Thought this sometimes causes something thing to slow down, it's more efficient overall. When we decide to have an interim meeting of one WG at IETF, it slows down work in others WGs. The ADs do their best to strike some sort of reasonable balance across the area. > > What I do not understand is why the chairs did not step in and named > additional editors to this draft. It would not have helped. If anyone has time or energy to help here - glad to get them synchronized into doing something that helps get things done faster. > > - -- > Marc Petit-Huguenin > Personal email: [email protected] > Professional email: [email protected] > Blog: http://blog.marc.petit-huguenin.org > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
