Bruce,
I spotted some problems in the IANA values of base-07 draft that just came out:
1. Why is the IANA value for CERTIFICATE_BY_NAME 16 instead of 4?
2. The IANA Message Code 30 should be for "app_attach_ans" and not "attach_ans"
3. The IANA values for the 4 AttachLite message code should be marked "unused".
Thanks
--Michael
-------- Original Message --------
Subject: [P2PSIP] transport/ICE issues in -07
From: Bruce Lowekamp <[email protected]>
Date: Wed, February 17, 2010 8:55 am
To: [email protected]
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).
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
