60 likes | 154 Views
IANA Service Name and Port Number Procedures. draft-ietf-tsvwg-iana-ports-08 M. Cotton (ICANN), L. Eggert (Nokia), J. Touch (USC/ISI), M. Westerlund (Ericsson), S. Cheshire (Apple). Document Goals. Update registration procedures Unify registries “Updates” RFCs for above
E N D
IANA Service Name and Port Number Procedures draft-ietf-tsvwg-iana-ports-08 M. Cotton (ICANN), L. Eggert (Nokia), J. Touch (USC/ISI), M. Westerlund (Ericsson), S. Cheshire (Apple)
Document Goals • Update registration procedures • Unify registries • “Updates” RFCs for above • What this doc is not: • Guidance to registrants/app designers • Specification of port/name spaces
Doc Summary • Unify registries • TCP/UDP, DCCP, SCTP ports, SRV names • Unify syntax • 15 chars alphanum with hyphens; 1 alpha required • New allocation procedures • Deregister, reuse, revoke, transfer
Changes since IETF 78 • Wording/clarification • Service name focus; port nums as secondary • Revise how transports are indicated (from IETF 78) • Replace ‘alias’ with ‘overloading’ (Sec 5) • Revised contact names (Sec 8) • Added contact resolution policy (Sec 8.7) • Syntax • Require a letter (Sec 5.1) • Remove coupling to srv-clarify doc • This doc unifies registries; does not change use or depend on changes to use (as in srv-clarify)
Current Status • Document is currently in WG last call • Ends 26th of November • Cross posted to Apps-Discuss, DNSEXT WG • Please provide input
WG Last Call Comments (so far) • Allocation, Assignment, Register mix (Tom Petch) • Allocation appears being the correct term • Need to update the document use terms consistently • Secondary Port for TLS/SSL (Paul Hoffman) • Experience from STARTTLS for SMTP (RFC 3207) is that it was complex and has security issues • A secondary port for TLS has been easier to implement and more successful • The concern is the port consumption doubles for TLS using services • Need to determine how serious these security concerns are • Have engaged the TLS group into this issue