Subject: [P2PSIP] Update of reload base draft

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Jan 2012 19:43:34 -0700

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.

Ekr, Bruce, & Cullen

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 20 Jan 2012 14:32:48 -0800

On 01/17/2012 06:43 PM, Cullen Jennings wrote:
> 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.
> 
> always be set and unfragmented packets are represented as the last fragment
> with an offset of 0.
> 
> - 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.
> 
> 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?

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 23 Jan 2012 06:38:22 -0800

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
>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> - 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.
>>> 
>>> 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.

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 are now presenting
their drafts in samrg, I'll probably do that too, and skip the p2psip meeting.

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.

What I do not understand is why the chairs did not step in and named
additional editors to this draft.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 23 Jan 2012 09:51:37 -0800

On 01/23/2012 09:16 AM, Cullen Jennings wrote:
> 
> On Jan 23, 2012, at 6:38 , Marc Petit-Huguenin wrote:
> 
>>>>> Jari Arkko Adrian Farrel Robert Sparks Peter Saint-Andre Dan
>>>>> Romascanu Russ Housley
>>>>> 
>>>>> * 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.
>>>>> 
>>>>> - 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.
>>>>> 
>>>>>  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
>>> 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.
> 
>> 
> 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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 23 Jan 2012 09:16:47 -0800

> 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. 

> 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

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.

> 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.  

> 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.