Subject: Re: [P2PSIP] transport/ICE issues in -07

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Mar 2010 18:07:52 -0700

fixed in next version - thanks for the careful read. 

On Feb 18, 2010, at 6:12 AM, neil.young wrote:

> 5.3.1.1
> 
> <quote>
>  
> Thus, the 3-byte value
>    "Foo" would be encoded as:  03 46 4f 4f.
> 
> </quote>
> 
> In fact it should be "encoded" as "03 46 6f 6f", or it should be named "FOO" :) (BTW: Those kind of errors in your draft is on the level I'm able to discover... :))
> 
> Question behind: May I assume, that every "opaque" value, as far as no explicitly determined in length, is preceded by a length byte (or more bits) on the wire?
> 
> Regards
> 
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Mar 2010 18:22:50 -0700

Fixed the < on the turn-density - no idea how that got there thanks.

The XML needs to be extensible in certain ways and we use namespaces for that. The ext: namespace is just a bogus extension to test extensibility. Code should allow that to be there in a config file even thought it is not a "real" extension. The chord namespace is a real extension and defines the parameters that are specific to the chord DHT plug in. 

I've been validating these in Oxygen and they seem to be working fine but it's really easy to make a mistake with them. Can you point out what is wrong with the relaxNG or xml? 

And thanks for all the testing on this. 

Cullen

On Feb 18, 2010, at 9:23 AM, neil.young wrote:

> Additional information:
> If I remove all elements, tagged with "chord:" and "ext:" from the XML everything is fine. But I believe this is not the intention.
> Regards
> 
> 
> neil.young schrieb:
>> 10.1:
>> 
>> I'm unable to generate a proxy class from the XML. Normaly I'm using xsd.exe to convert plain xml to an xsd, if the xsd isn't provided. The schema then is converted to proxy class, which might easily be used in C# code. This works with several XML based information contents in 3GPP projects, but not with RELOAD.
>> 
>> Furthermore the XML is syntactically incorrect in the line containing
>> "<turn-density> 10 </turn-density><"
>> 
>> The final "<" has to be removed.
>> 
>> I was taking this xml and fed it to xsd.xml
>> 
>> c:\xsd reload.xml
>> 
>> The resulting 3 xsd files (reload.xsd, reload_app1.xsd, reload_app2.xsd) could not be converted to a wrapper class by
>> 
>> c:\xsd reload.xsd /language:cs /classes
>> 
>> The error is:
>> Schema validation warning: urn:ietf:params:xml:ns:p2p:config-ext1:example-extention-Element not declared. Line 18, position 16.
>> Schema validation warning: urn:ietf:params:xml:ns:p2p:config-chord:chord-ping-interval-Element not declared. Line 19, position 16.
>> Schema validation warning: urn:ietf:params:xml:ns:p2p:config-chord:chord-update-interval-Element not declared Line 20, position 16.
>> Schema validation warning: Das urn:ietf:params:xml:ns:p2p:config-ext1:example-kind-extention-Element not declared. Line 56, position 34.
>> 
>> Although this is just warnings, the code generation fails too in the first step:
>> Error: Error generating classes for schema 'reload'.
>>  - 'urn:ietf:params:xml:ns:p2p:config-ext1:example-extention' missing.
>> 
>> Regards
>> 
>> 
>> neil.young schrieb:
>>> 5.3.1.1
>>> 
>>> <quote>
>>> Thus, the 3-byte value

Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Mar 2010 18:24:25 -0700

On Feb 19, 2010, at 1:32 PM, neil.young wrote:

> the node MUST do a DNS SRV query using a Service name of
>    "p2psip_enroll" and a protocol of tcp to find an enrollment server
>    and form the URL by appending a path of 
> "/p2psip/ enroll"
>  to the
>    overlay name.
> 
> 
> I guess, the space after "/p2psip/ " is a typo (?)

Yes, typo. Fixed. Thanks. 

Cullen Jennings

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 9 Mar 2010 11:10:02 -0500

File this under very, very minor nit that I don't really care too much
about, but should we call this thing something other than chord?
Technically, it really isn't Chord anymore, but sort of an enhancement
to it, and someone might want to use/implement a version that really
is regular chord for some reason. Chord-P2PSIP or something?

David (as individual)

---

From: jc <[email-masked]>
Date: Tue, 9 Mar 2010 12:39:07 -0500

I recall  that it was once named "Chord-Reload". I may be wrong.

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Mar 2010 12:44:40 -0700

Yah, I think most people now treat Chord as more a family of algorithms with various settings, extensions etc.  When I do a search on IEEE, I get 100s of journal articles that refer to the algorithm as Chord but are variations on the original paper. I obviously agree with you that the algorithm in the draft is not the original Chord algorithm. I note that some of the papers use the term "Chord Based". I'm happy to see the name changed if anyone has good ideas and I can equally well live with it as is.

Cullen

Cullen Jennings