-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 01/23/2012 09:16 AM, Cullen Jennings wrote: > > 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. >
Well, thanks for putting things in perspective. - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPHZ4mAAoJECnERZXWan7EYL0QALMhuurY9GEIrc+4Qry/grkA BjDt4Y0RzGVe6ofV62YQiQDCIOg9mRj0+GJzSaI1O0b+iTqGxiAmMpPHq8IvvOjs s6PsdXhotiyD8peHQWncpJRO6hpYqQxV1B+M7g2VH9KDmav7fcvhua846CQ4T6FC hIGWl3tQJSwB0AVZLqUDJSbt4Kuzy2ObM7CMxy2Q2Wjw+UnaVWnCGpM1/i+r4eHx hnRp8ozE3z3fV9+uTwFdXnQzvwxojQ/ZK/X6sJCZw6/J0S9HDPTOSqjGYkfMrK4C hNABYWvdEgBTgtGNPdrOErbJdVP+jcMgNZqOv3EPFxr/QAoudztYutjbdHxxpKTr wspS/0TbXdjHoSQAURop4a+ICRCte4QoYvbBiDYFTXF7TB893FFPlPLcr4xyaPoU bU3kn3P7bqiHdWjpCaxVuJ7uGv4wMgzY4WuTdB0Xjzh6M5BMraLAJTQapDespygz 9TvJw1KVWtw3ewPYSEyu8BVf/D30tbdT/GiBaRarJi2zkjxXHm09tCXUT++qOkji Of35w7HaWsa6vjHLpttK/twjp1l4QLWaqAPV2NmBeiRxhgl407r6FXMhKx3EEG4U RLBVdmeX2d0WzMO3ypTAC21f/iV/HqZFjyP64XZTHAdEiDAJ0xqVUjMDstH2Av7Q S9ZqDjv5kZuuPvZ5SsYS =iEBU -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
