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

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Mar 2010 17:34:15 -0700

Thanks ... inline ...

On Feb 17, 2010, at 11:00 PM, Michael Chen wrote:

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

4-15 were previously used by diagnostic stuff so the certificate got a code that did not conflict with theses so there was no issues during transition. Just as FYI they were 

              | ROUTING_TABLE_SIZE |          4 | RFC-AAAA |
              | SOFTWARE_VERSION   |          5 | RFC-AAAA |
              | MACHINE_UPTIME     |          6 | RFC-AAAA |
              | APP_UPTIME         |          7 | RFC-AAAA |
              | MEMORY_FOOTPRINT   |          8 | RFC-AAAA |
              | DATASIZE_StoreD    |          9 | RFC-AAAA |
              | INSTANCES_StoreD   |         10 | RFC-AAAA |
              | MESSAGES_SENT_RCVD |         11 | RFC-AAAA |
              | EWMA_BYTES_SENT    |         12 | RFC-AAAA |
              | EWMA_BYTES_RCVD    |         13 | RFC-AAAA |
              | LAST_CONTACT       |         14 | RFC-AAAA |
              | RTT                |         15 | RFC-AAAA |

> 
> 2. The IANA Message Code 30 should be for "app_attach_ans" and not "attach_ans"

fixed

> 
> 3. The IANA values for the 4 AttachLite message code should be marked "unused".

fixed

> 
> Thanks
> 
> --Michael
> 
> -------- Original Message --------
> Subject: [P2PSIP] transport/ICE issues in -07
> From: Bruce Lowekamp <[email-masked]>
> Date: Wed, February 17, 2010 8:55 am
> To: [email-masked]
> 
> 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-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