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

From: Bruce Lowekamp <[email-masked]>
Date: Wed, 17 Feb 2010 08:55:43 -0800

We have a variety of outstanding issues regarding transport and ICE.
This email tries to summarize the approach adopted in -07 for these
issues.

* ICE-TCP is currently MTI and thus a normative dependency.  However,
  it's unclear when ICE-TCP will be finished.
* The draft needs to specify framing and a timeout for TCP or other
  stream-oriented protocols that do not provide such notifications
  themselves.
* We have the AIMD proposal in an appendix,
* The authors promised to merge [App]Attach and [App]AttachLite into
  [App]Attach, but have not done so.
* Feedback about various related issues from WGLC.

To reconcile these issues, the following changes have been made.

* New text has been inserted to clarify that new ICE transport
  protocols and extensions (such as ICE-TCP) can be used within RELOAD
  by defining new codepoints.

* References to ICE-TCP have been removed from the specification.

* "Reliability for Unreliable Links" is renamed "Simple Reliability
  (SR)".

* The header from SR is now used for TCP as well.  It wastes a few
  bytes, but allows the sender to receive ACKs from the receiver,
  required to time RTT and determine when the link should be regarded
  as dead.

* ICE Transports are now labeled Overlay Link protocols, as they
  specify not only transport but also framing, etc., eg  DTLS/UDP with SR

* *AttachLite are removed.  In their place, new overlay link protocols
  are defined.  DTLS/UDP with SR no ICE and TLS/TCP with FS no ICE.
  Text is added that defines how lite and full ICE implementations
  interoperate. (text below)

* The AIMD proposal is deleted in its entirety.  In its place is a
  reference to future definitions of semi-reliable datagram-oriented
  protocols over UDP such as SCTP and DCCP currently under discussion
  in TSV.  Preference is recommended for these, as any would be
  superior to all current transport options (high-performance without
  head-of-line blocking).

---

From: "neil.young" <[email-masked]>
Date: Thu, 18 Feb 2010 12:18:03 +0100

Hi Bruce,
this is really a lot of changes. What do early implementors say about 
this (e.g. no AttachLite anymore?)
Regards

Bruce Lowekamp schrieb:
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>

---

From: "neil.young" <[email-masked]>
Date: Thu, 18 Feb 2010 12:21:06 +0100

What document do I have to read in parallel in order to resolve some 
missing type definitions, e.g.

 struct  {
        SignatureAndHashAlgorithm     algorithm;
        SignerIdentity                identity;
        opaque                        signature_value<0..2^16-1>;
     } Signature;

What is SignatureAndHashAlgorithm etc.?
Regards

neil.young schrieb:
> ------------------------------------------------------------------------
>

---

From: "neil.young" <[email-masked]>
Date: Thu, 18 Feb 2010 12:22:57 +0100

Sorry, seems I found it.

"The algorithm definitions are
      found in the IANA TLS SignatureAlgorithm Registry."

---

From: "neil.young" <[email-masked]>
Date: Thu, 18 Feb 2010 14:12:19 +0100

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

---

From: "neil.young" <[email-masked]>
Date: Thu, 18 Feb 2010 17:16:23 +0100

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

---

From: "Neil.Young" <[email-masked]>
Date: Thu, 18 Feb 2010 17:23:36 +0100

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:
> C# code. This works with several XML based information contents in 
> 3GPP projects, but not with RELOAD.
>
> The resulting 3 xsd files (reload.xsd, reload_app1.xsd, 
> reload_app2.xsd) could not be converted to a wrapper class by
>
> urn:ietf:params:xml:ns:p2p:config-chord:chord-ping-interval-Element 
> not declared. Line 19, position 16.
>> 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
>>
>

---

From: "neil.young" <[email-masked]>
Date: Thu, 18 Feb 2010 20:39:21 +0100

The XML does also not validate correctly against 
http://www.hitsw.com/xml_utilites/

Just one question: Is this the right place to discuss those kind of 
problems or is there another group, more focused on implementations?

Kind regards

Neil.Young schrieb:
>> 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.
>>

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 19 Feb 2010 09:56:20 -0500

Definitely the right place. We don't currently have an implementation
specific list (something like the sip-implementors list), but even if
we did, what you are noticing is a bug in the spec proposal, and the
right place for that is always the working group. Thanks for all the
comments.

David (as chair)

On Thu, Feb 18, 2010 at 2:39 PM, neil.young <[email-masked]> wrote:
> Just one question: Is this the right place to discuss those kind of problems
> or is there another group, more focused on implementations?
>
> Kind regards
>
>
> Neil.Young schrieb:
>
> Additional information:
> 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.
>
> urn:ietf:params:xml:ns:p2p:config-chord:chord-update-interval-Element not
> declared Line 20, position 16.
> 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:
> 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... :))
>
> explicitly determined in length, is preceded by a length byte (or more bits)
> on the wire?
>
> Regards
>
>
>
>

---

From: "neil.young" <[email-masked]>
Date: Fri, 19 Feb 2010 17:23:53 +0100

> right place for that is always the working group. Thanks for all the
Thanks for encouraging me. While reading the draft I found some more 
minor issues. I'll post it, if I can recall or stumble again :)

Regards

---

From: "neil.young" <[email-masked]>
Date: Fri, 19 Feb 2010 21:32:47 +0100

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 (?)

Regards

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2010 12:43:30 -0800

> explicitly determined in length, is preceded by a length byte (or more bits)

There should never be a simple opaque that isn't either a fixed-length
string (opaque foo[9]) or a veariable length vector (opaque foo<0..255>).

-Ekr

---

From: "neil.young" <[email-masked]>
Date: Fri, 19 Feb 2010 21:52:51 +0100

Hmm. Try to ask on another way: There are several variable length 
opaques throughout the draft, but - as far as I can see - the statement 
"there is an extra length byte on the wire" (what seems logical to me, 
btw) is provided only in conjunction with the RessourceID description. 
Does this statement implicitly apply to all other variable length 
opaques too?

Sorry, if I wasn't specific enough with my question. I hope, it is clear 
now.

Regards

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 19 Feb 2010 13:09:25 -0800

On Fri, Feb 19, 2010 at 12:52 PM, neil.young <[email-masked]> wrote:
> Hmm. Try to ask on another way: There are several variable length opaques
> throughout the draft, but - as far as I can see - the statement "there is an
> extra length byte on the wire" (what seems logical to me, btw) is provided
> only in conjunction with the RessourceID description. Does this statement
> implicitly apply to all other variable length opaques too?

This notation is derived from that of TLS (RFC 5246). Thus, you need to
look there to see how to encode these:

 Variable-length vectors are defined by specifying a subrange of legal
   lengths, inclusively, using the notation <floor..ceiling>.  When
   these are encoded, the actual length precedes the vector's contents
   in the byte stream.  The length will be in the form of a number
   consuming as many bytes as required to hold the vector's specified
   maximum (ceiling) length.  A variable-length vector with an actual
   length field of zero is referred to as an empty vector.

      T T'<floor..ceiling>;

   In the following example, mandatory is a vector that must contain
   between 300 and 400 bytes of type opaque.  It can never be empty.
   The actual length field consumes two bytes, a uint16, which is
   sufficient to represent the value 400 (see Section 4.4).  On the
   other hand, longer can represent up to 800 bytes of data, or 400
   uint16 elements, and it may be empty.  Its encoding will include a
   two-byte actual length field prepended to the vector.  The length of
   an encoded vector must be an even multiple of the length of a single
   element (for example, a 17-byte vector of uint16 would be illegal).

      opaque mandatory<300..400>;
            /* length field is 2 bytes, cannot be empty */
      uint16 longer<0..800>;
            /* zero to 400 16-bit unsigned integers */

-Ekr

---

From: "neil.young" <[email-masked]>
Date: Wed, 24 Feb 2010 19:27:37 +0100

Just so you know: I tried to convert your 10.1.1 Relax NG Grammar into 
an XSD to no avail too. There is something wrong with it...

Conversion attempt was done using TRANG 
(http://www.thaiopensource.com/relaxng/trang.html) following the 
instructions given here: 
http://etutorials.org/XML/xml+hacks/Chapter+5.+Defining+XML+Vocabularies+with+Schema+Languages/Hack+76+Convert+a+RELAX+NG+Schema+to+XML+Schema/

Comments welcome.
Regards

neil.young schrieb:
>> 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:
>>>
>>>> no explicitly determined in length, is preceded by a length byte 
>>>> (or more bits) on the wire?
>>>>
>>>> Regards
>>>>
>>>
>>