Re: TSV-Dir Last Call review of draft-ietf-avt-rtp-cnames-02
rent versions of UUID that RFC 4122 covers: > > + Version 1: generated from clock + MAC, or + MAC-format random number > + Version 3: generated from namespace:name > + Version 4: generated from "truly random or pseudo-random number" > + Version 5: generated from hash of namespace:name > > There needs to be some guidance because the use of the UUID Versions 3/5, > derived from namespace:name, has the same problem with non-uniqueness of > FQDNs as the RFC 3550 FQDN-based CNAMEs. Perhaps this document should advise > against using 3/5. In addition, right now the draft is silent on mitigating > identity exposure, but it could offer some guidance towards using the variant > of Version 1 that does not expose the MAC or towards using Version 4. This guidance seems appropriate, thanks. > 2) Short-term persistent CNAMEs are allowed to use a pseudo-randomly > generated RFC 4941 IPv6 privacy address if the device is IPv6-capable, but > are required to exposetheir MACs if the device is IPv4-only. Why not allow > IPv4-only endpoints to to generate pseudo-random MACs using the specification > of doing so provided for the Version 1 variant in RFC 4122? That seems like a reasonable addition. > 3) Per-session CNAMEs are generated using SHA1-HMAC over the concatenation of > the initially-used SSRC, the source and destination addresses and ports, and > "a randomly generated value". RFC 4086 is given as a reference for the > randomly generated value. I think an implementer would like to know how many > bytes of randomly generated value should be used; this doesn't come out > clearly from reading RFC 4086. Further, what are the requirements for the key > for HMAC here? In reading RFC 2104, the reference for HMAC, I end up with > some ideas about the key length, but not about how long/where I can use the > same key or whether there are problematic keys - to mention two questions > that come to mind. Keying would not normally be easy to under-specify this > way because a security application would call for some keying details, but in > this application there is no security use for the keys. Either it would be > good to add some guidance or perhaps SHA1-HMAC could be replaced with an "inse cure hash." We'll add some guidance in -03. Thanks, Colin -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-zimmermann-avt-zrtp-20.txt
On 11 May 2010, at 22:15, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : ZRTP: Media Path Key Agreement for Unicast Secure RTP Author(s) : P. Zimmermann, et al. Filename: draft-zimmermann-avt-zrtp-20.txt Pages : 111 Date: 2010-05-11 This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP profiles. ZRTP secures media sessions which include a voice media stream, and can also secure media sessions which do not include voice by using an optional digital signature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zimmermann-avt-zrtp-20.txt This addresses some, but not all, of my comments on -17: - “In terms of the RTP topologies defined in [RFC5117], ZRTP is designed for Point to Point topologies only” - if only Topo-Point-to- Point is supported, explicitly state that by shortcut name, otherwise also list the other topologies that are supported by shortcut name. - “Other [RTP] profiles MAY also be used” - which ones? Need to be explicit, since not all conceivable RTP profiles would work with ZRTP. - This version states that “SSRC collisions would be disruptive to ZRTP. This may be avoided via the mechanisms in RFC 3550, Section 8.2 [RFC3550]”. The mechanisms in section 8.2 of RFC 3550 explain how to resolve SSRC collisions, not how to avoid them, and say nothing about how to avoid disruption to ZRTP. Further clarification is needed - I’d guess that the right thing to do is to accept that SRRC collisions are disruptive, and force a re-negotiation of the secure session. If so, the draft needs to state this explicitly. - A ZRTP Error code of 0x91 “SSRC collision” is defined, but the text doesn’t mention how it’s used. - The new discussion of timers for non-UDP transports in section 6 is much improved, but could still do with giving explicit recommendations for the lengthened timer intervals. - The new text regarding the ZRTP header extension is better, but could still do with explicitly stating that not only does ZRTP not use the RFC 5285 mechanisms, it conflicts with them. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [AVT] Last Call: draft-zimmermann-avt-zrtp (ZRTP: Media Path Key Agreement for Secure RTP) to Informational RFC
Alan, Thanks for your response - some comments inline. Colin On 23 Apr 2010, at 18:15, Alan Johnston wrote: Colin, Thank you for your detailed review of the draft. See my comments below. - Alan - On 4/13/10 12:19 PM, Colin Perkins wrote: On 17 Mar 2010, at 22:26, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'ZRTP: Media Path Key Agreement for Secure RTP ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-04-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I've reviewed this draft, and have a number of comments. The main issue is the scope of the protocol: it claims to be "Media Path Key Agreement for Secure RTP", but may be better titled "Media Path Key Agreement for Unicast Voice Telephony Using Secure RTP". The majority of RTP sessions cannot be secured using ZRTP, but this draft is virtually silent on its limitations. The draft does point out that it is for securing unicast RTP only. For example, in Section 1: "ZRTP is designed for unicast media sessions in which there is a voice media stream." Including unicast in the title does seem to be a reasonable thing to do and we will do that. However, scoping it to voice telephony is not accurate. While the Short Authentication String is the preferred security mechanism, the protocol also works with digital signatures and can be authenticated using an integrity protected signaling channel. Neither of these methods require a voice channel. Some details follow: - RTP is explicitly a group communication protocol, that supports a wide range of topologies [RFC 5117], and a wide range of media types. ZRTP is defined for point-to-point audio calls or group audio conferences with a centralised conference bridge, and doesn't support the full range of RTP topologies or media formats. This is probably an acceptable limitation, but needs to be much more clearly documented than in the present draft. We propose adding unicast to the title and having this as the first sentence of the Abstract: " This document defines ZRTP, a protocol for media path Diffie- Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for VoIP applications." That's fine, but I do think the draft should explicitly refer to RFC 5117 and state which of the RTP topologies described therein are supported. ... - Section 5 uses the SSRC to associate ZRTP messages with an RTP stream, but doesn't appear to consider the possibility of an SSRC collision [RFC 3550 section 8.2]. Sure - we should mention that if a VoIP call is forked to two endpoints, and media sessions are established with both, and they both choose the same 32 bit SSRC, then ZRTP will not be able to distinguish between them. An SSRC collision is possible, if unlikely, for unicast sessions in the absence of forking. I believe the draft needs to explicitly address what should be done in the event of an SSRC collision (presumably you should re-negotiate the security, which should be acceptable since collisions are rare). - RTP can run over non-UDP transports, such as TCP and DCCP. Section 6 of the draft defines retransmission timers for ZRTP that are reasonable for RTP/UDP/IP sessions, but not for RTP/TCP/IP or RTP/DCCP/IP sessions. The draft needs to discuss use of ZRTP over non-UDP transports. If the media is transported end-to-end using a reliable transport, then clearly ZRTP retransmissions are not needed. However, there can be cases involving relays where ZRTP could be sent over a reliable transport part of the way, and an unreliable transport the rest of the way. We will add text recommending that if reliable transport is used, then the retransmit timers should be lengthened. It's not clear how such scenarios can be distinguished, but okay. Some guidance on the appropriate values for the lengthened timers would be helpful. - Section 7.3 discusses relaying ZRTP through a PBX. There appears to be an assumption that the PBX is configured to provide point to multipoint service as an RTCP-Terminating MCU (Topo-RTCP- terminating-MCU in the terminology of RFC 5117). None of the other topologies defined in RFC 5117 are considered. I couldn't find where you got this idea from. A PBX is not going to act as an RTCP-Terminating MCU. It will most likely act as a B2B for both the signaling and media, but it will still be 1:1. We can clarify this. ZRTP does not apply to all the topologies of RFC 5117.
Re: Last Call: draft-zimmermann-avt-zrtp (ZRTP: Media Path Key Agreement for Secure RTP) to Informational RFC
On 17 Mar 2010, at 22:26, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'ZRTP: Media Path Key Agreement for Secure RTP ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-04-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I've reviewed this draft, and have a number of comments. The main issue is the scope of the protocol: it claims to be "Media Path Key Agreement for Secure RTP", but may be better titled "Media Path Key Agreement for Unicast Voice Telephony Using Secure RTP". The majority of RTP sessions cannot be secured using ZRTP, but this draft is virtually silent on its limitations. Some details follow: - RTP is explicitly a group communication protocol, that supports a wide range of topologies [RFC 5117], and a wide range of media types. ZRTP is defined for point-to-point audio calls or group audio conferences with a centralised conference bridge, and doesn't support the full range of RTP topologies or media formats. This is probably an acceptable limitation, but needs to be much more clearly documented than in the present draft. - The draft claims it works with the RTP/AVP profile (although this is misspelt AVP/RTP in section 3). This is only one of several RTP profiles that can be used, but nothing is said about the other RTP profiles, such as RTP/AVPF. To avoid confusion, the draft should explicitly state which of the other RTP profiles are supported and which are not. - Section 5 uses the SSRC to associate ZRTP messages with an RTP stream, but doesn't appear to consider the possibility of an SSRC collision [RFC 3550 section 8.2]. - RTP can run over non-UDP transports, such as TCP and DCCP. Section 6 of the draft defines retransmission timers for ZRTP that are reasonable for RTP/UDP/IP sessions, but not for RTP/TCP/IP or RTP/DCCP/ IP sessions. The draft needs to discuss use of ZRTP over non-UDP transports. - Section 7.3 discusses relaying ZRTP through a PBX. There appears to be an assumption that the PBX is configured to provide point to multipoint service as an RTCP-Terminating MCU (Topo-RTCP-terminating- MCU in the terminology of RFC 5117). None of the other topologies defined in RFC 5117 are considered. - The draft does not specify how traffic RTCP is secured. This might be done using the key negotiated on the media path, or it might require a separate ZRTP negotiation using multistream mode, but the draft doesn't specify. - SDES is a commonly used abbreviation in the RTP community for RTCP Source Description packets, yet this draft uses it for other purposes. To avoid confusion, please expand the acronym (e.g., in Section 8.2). - The recommendations in Section 8.3 to avoid VBR traffic with secure calls are at odds with the recent discussion in the AVT working group (IETF 76). - Section 10 assumes that the presence of an RTP mixer can be determined from the signalling. This assumption is false in general, although it's true for some SIP-initiated calls. - The RTP header extension for ZRTP (Section 12) conflicts with the mechanism defined in RFC 5285. At minimum, this conflict should be documented, and it might make sense to update this draft to use the RFC 5285 mechanism. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
TSV review of draft-ietf-sipping-rtcp-summary-08
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This document defines a SIP event package to enable reporting some RTCP XR metrics, in particular those deemed relevant to some classes of VoIP application. The metrics reported are a subset of those defined in RFC 3611, plus some extensions. This is a potentially useful specification, but I believe there are a number of problems with the way it interacts with RTP which I recommend be addressed before publication. The applicability statement (section 1.1) references the list of RTP topologies in RFC 5117, and states that only the first (point-to- point) sessions is relevant to this document. The Usage Scenarios (section 1.2) and the rest of the document contradict this, discussing point-to-point sessions, conference calls using a central conferencing server, and multicast VoIP calls using SSM. RTP is inherently a group communication protocol, and this document needs to properly consider the full range of topologies defined in RFC 5117. A large number of parameters are defined in Section 4.6: The PayloadType parameter states that "IANA registered values SHOULD be used where possible", but the IANA registry only applies to the RTP/ AVP profile, and has been closed to new registrations for several years now. The implication of this document is that the payload type is sufficient to identify the codec, but this is not the case, and for this reason RFC 3551 recommends the use of media subtype names instead. The PayloadDesc parameter is defined to provide a text description for the codec. It is stated that "The abbreviated standard name for the codec SHOULD be used (for example "G.729A")". The IETF has a standard namespace for codecs, in the form of media subtypes, registered according to RFC 4855. I believe it would be a mistake to introduce another, ill-defined, namespace in this document, rather than using the standard media type names as used for all other RTP-related documents. Several parameters are defined relating to frame-based codecs (e.g. FrameDuration, FrameOctets, and FramesPerPacket). However, not all RTP audio payload types are frame based (see RFC 3551, section 4.3). It is not clear how sample based codecs are handled. The FmtpOptions parameter is defined to convey "FMTP options from SDP". These options are parameters of media subtypes, and don't make sense unless the PayloadDesc is specified as a media subtype (and don't make any sense if just PayloadType is specified, since they're related to a media subtype name, not a payload type). The MetricType parameter is ill-defined. What do the values specified refer to, and how are new values to be registered? The LocalAddr and RemoteAddr parameters assume that STUN is used as a NAT traversal mechanism, if one is needed. While I agree with the principle of reporting the address on the "outside" of the NAT, STUN is not always available. Section 4.6.2.9.5 expresses interarrival jitter as defined in RFC 3550 in milliseconds, but RFC 3550 specifies it in RTP timestamp units. Nit: In the last sentence of the introduction, "Real-Time Control Protocol" should be "RTP Control Protocol". -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fecframe] Last Call: draft-ietf-fecframe-dvb-al-fec (DVB-IPTVApplication-Layer Hybrid FEC Protection) to Informational RFC
Thanks. The updated draft looks good. Colin On 14 Dec 2009, at 20:55, Ali C. Begen (abegen) wrote: Sounds like a good suggestion. We will make the text change after the LC ends. Thanks. -acbegen -Original Message- From: fecframe-boun...@ietf.org [mailto:fecframe-boun...@ietf.org] On Behalf Of Colin Perkins Sent: Monday, December 14, 2009 11:48 AM To: fecfr...@ietf.org Cc: IETF Discussion Mailing List Subject: Re: [Fecframe] Last Call: draft-ietf-fecframe-dvb-al-fec (DVB-IPTVApplication- Layer Hybrid FEC Protection) to Informational RFC On 30 Nov 2009, at 15:35, The IESG wrote: The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'DVB-IPTV Application-Layer Hybrid FEC Protection ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fecframe-dvb-al-fec-03.txt I understand, from previous conversations with the author, that the aim of this draft is "to explain how one can use IETF specs to implement AL-FEC protocol". That's a fine goal, and this draft does a reasonable job in providing such an explanation. However, I believe - as I previously stated in the working group - that the relationship between this draft and the DVB AL-FEC specification is not clearly defined. While the abstract is reasonably clear on the relationship, the title and introduction suggest that this draft is the DVB AL-FEC protocol, rather than being implementation guidelines for the DVB AL-FEC protocol. One way to address this might be to change the title of the draft to "Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection", and to add a few clarifying sentences to the introduction. I have no problems with the technical content of the draft. -- Colin Perkins http://csperkins.org/ ___ Fecframe mailing list fecfr...@ietf.org https://www.ietf.org/mailman/listinfo/fecframe ___ Fecframe mailing list fecfr...@ietf.org https://www.ietf.org/mailman/listinfo/fecframe -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Fecframe] Last Call: draft-ietf-fecframe-dvb-al-fec (DVB-IPTV Application-Layer Hybrid FEC Protection) to Informational RFC
On 30 Nov 2009, at 15:35, The IESG wrote: The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'DVB-IPTV Application-Layer Hybrid FEC Protection ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-12-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-fecframe-dvb-al-fec-03.txt I understand, from previous conversations with the author, that the aim of this draft is "to explain how one can use IETF specs to implement AL-FEC protocol". That's a fine goal, and this draft does a reasonable job in providing such an explanation. However, I believe - as I previously stated in the working group - that the relationship between this draft and the DVB AL-FEC specification is not clearly defined. While the abstract is reasonably clear on the relationship, the title and introduction suggest that this draft is the DVB AL-FEC protocol, rather than being implementation guidelines for the DVB AL-FEC protocol. One way to address this might be to change the title of the draft to "Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection", and to add a few clarifying sentences to the introduction. I have no problems with the technical content of the draft. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 5 Jul 2009, at 20:52, James M. Polk wrote: At 09:38 AM 7/5/2009, Colin Perkins wrote: On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. I also appreciate the added consistency in Internet-Draft formatting that has resulted since xml2rfc has been widely adopted. This makes it a lot easier to print drafts, since they have consistent page sizes and form-feed characters. huh? the current boilerplate has the first page being 54 lines long, and subsequent pages being 57 lines long, but with the "footer" on the 56th line, and not the 57th. The "footer" on the first page isn't on the last line of the page either. This isn't very uniform... perhaps unless you use some special viewer to recreate this non-uniform display consistently. It doesn't greatly offend me that the first page is three lines shorter than the other pages. Nor does it confuse enscript, on those occasions when I want to print an internet-draft or RFC. This is very much unlike the situation pre-xml2rfc, when the page length and width varied considerably for some drafts, and where form- feeds were often inconsistently applied. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. I also appreciate the added consistency in Internet-Draft formatting that has resulted since xml2rfc has been widely adopted. This makes it a lot easier to print drafts, since they have consistent page sizes and form-feed characters. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-ietf-sip-outbound-17
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. Overall, this draft is basically ready for publication, but has some minor nits that should be fixed before publication. The initial paragraph of section 3.5 can be interpreted as implying that a single lost ping is sufficient to declare a UDP flow dead. Section 4.4.2 is clear that this is not the case, but to avoid confusion, it might be appropriate to add a caveat or forward reference to section 3.5. Section 4.4 defines a keep-alive mechanism using CRLF sequences multiplexed with the SIP messages if connection-oriented transports are used, and using STUN requests sent on the same port when connectionless transports are used. This makes sense for the examples of TCP, SCTP, and UDP transports. There's no mention of DCCP, though, which has somewhat different properties to the other connection oriented transports, and doesn't obviously work using a CRLF keep alive (e.g. RFC 3261 section 7.1 requires implementations that use stream-oriented transports to ignore an extra CRLF, but not those using unreliable datagram protocols). Some clarification would be useful, even if just to state that operation over DCCP is for future study. Section 4.4.1 specifies keep-alive timer intervals for connection- oriented sessions for both battery operated and mains powered devices, while section 4.4.2 only provides a single time out value for connectionless sessions. It would be useful to explicitly mention the impact on battery powered devices in section 4.4.2, to be clear that the suggestion of only a single interval was intentional. Section 4.4.1 requires a response to a keep alive to be received within 10 seconds of the request being sent. It's not clear why this value was chosen, especially since multi-second RTTs are not unheard of in some cases (c.f. the motivation for LEDBAT). While I don't think this is an inappropriate choice, some motivation and rationale would make it easier to judge why this value is sensible, and when it might be appropriate to use a different time out. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
On 2 Dec 2008, at 19:51, Jari Arkko wrote: Thanks for your review, Colin. I agree that fixes or better explanations of the background should be given for the points that you raised. It seems that you and Hesham are making progress on what needs to be added to the document, great! The only item that I too am somewhat worried about in your list is the address replacement by broken NATs and the tricks used to prevent that. I feel that the best way to deal with that is to document this as a potential problem -- the protocol already has tools to provide a far better obfuscation technique than XOR -- just turn on encryption if this turns out to be a problem and the device in question cannot be ripped out of the network. Agreed. Do we have any information about how widespread such NATs might be? RFC 5389 just says "some NATs". Not really, but something that broken can't be common: it'd cause too many obvious problems. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [tsv-dir] tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
On 1 Dec 2008, at 11:06, Magnus Westerlund wrote: Hesham Soliman skrev: Thanks Colin, I agree with your rationale but I wonder if we need to support every broken device out there. In any case, if we have to, I prefer to require encryption than to add the XORED address option. I'd like to hear what people in MEXT think about this, comments from MEXT? I don't think we should go to far to correct this bug in implementations. My understanding is that this have been observed but is not a common behavior as these generic ALGs do break things randomly and horribly. I would only do something about if it has no minimal impact on the specification and any deployed implementations. Otherwise the fix is likely to cause more grief than the few devices that are broken. Right - the issue should be documented, and if there is a trivial fix it should be recommended, but this isn't a big issue. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
On 1 Dec 2008, at 09:00, Hesham Soliman wrote: => Well, I'm not sure how a NAT can do that. You mean the NAT will parse the binding update message deep inside the IPv6 extension header in the inner IP packet? This is where the original address is preserved. To do that, a NAT would have to understand the various MIPv6 options, and if it did, it would know not to do that :) The inner header is IPv6, so a NAT should not touch that. My understanding from the STUN work is that NATs have been observed which rewrite any sequence of four aligned bytes matching the source IP address, irrespective of its location within the packet (section 15.2 of RFC 5389). => Sounds freightning! May be we need to mandate encryption and hope that no 4-byte sequence matched the IP address? What do they do with encrypted packets? How do they know they're encrypted? One would assume these broken devices will potentially corrupt encrypted packets, the same as they will potentially corrupt any other packet. Hiding the source address when it appears in the payload (either by encryption, or using some trivial obfuscation as does STUN) simply reduces the probability of such corruption so it's no longer 100% guaranteed that the payload will be mangled. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
Hesham, Thanks - one minor follow-up inline. Colin On 1 Dec 2008, at 08:29, Hesham Soliman wrote: Colin, Thank you for the review. Please see some comments inline. In summary, this draft seems to be on the right track but has some open issues, as discussed below. The NAT keep-alive interval (Section 5.3 and 7) is set to 110 seconds by default, unless configured by the home agent in a binding acknowledgement. While the default interval seems a safe choice, it's not clear why it was chosen, or when it's appropriate for a home agent to signal an alternative interval. The draft would benefit from an explanation of this choice, and further discussion of the issues inherent in choosing an appropriate keep-alive interval (Section 3.5 of RFC 5405 considers this point, and might be appropriate to reference). => Thanks for the reference. I'll include that in the new rev. The interval was chosen based on recommendations from people with experience in NAT deployments and the WG agreed with it. But the reference will certainly help the reader. The NAT detection mechanism specified in Section 5.2 relies on the NAT rewriting the source address of the outer IPv4 header, but not the IPv4 address carried in the binding update payload. I'm not familiar with the way in which mobile IPv6 uses IPsec ESP, but if it's used in a way that provides integrity protection but not confidentiality, issues may arise with NAT devices that rewrite IPv4 addresses in the UDP payload, causing the integrity check to fail (this is why STUN [RFC5389] provides an XOR-MAPPED-ADDRESS attribute to obfuscate the IP address). => Well, I'm not sure how a NAT can do that. You mean the NAT will parse the binding update message deep inside the IPv6 extension header in the inner IP packet? This is where the original address is preserved. To do that, a NAT would have to understand the various MIPv6 options, and if it did, it would know not to do that :) The inner header is IPv6, so a NAT should not touch that. My understanding from the STUN work is that NATs have been observed which rewrite any sequence of four aligned bytes matching the source IP address, irrespective of its location within the packet (section 15.2 of RFC 5389). It's not clear that the use with ECN is fully specified. Section 5.1.1 notes that it's "RECOMMENDED that the ECN information is copied between the inner and outer header as defined in [RFC3168]" - is the intent that the full-functionality option defined in RFC 3168 is recommended? If so, it would be useful to state that explicitly. => Yes. I think we can explicitly mention that. This was done to follow the same rules which are done for IP in IP encapsulation, as per RFC 4213. It also seems that UDP encapsulation will prevent the use of ECN over the tunnel, since the UDP API doesn't allow access to the ECN bits, and cause different ECN (and hence congestion) behaviour depending on the encapsulation method used. This should be called out in the draft. => Ok, although I think this might not be an issue with many implementations as UDP encapsulation may be done in the kernel with the rest of the MIPv6 implementations (typically anyway). I'll add your comment to the draft. Processing of other IP header fields (e.g. the diffserv field and TTL) when encapsulated in UDP tunnels also seems poorly defined. The intent, presumably, is for the choice of tunnelling mechanism to be hidden from higher-levels, but the exact en-/de-capsulation steps needed to achieve this must be specified for the UDP encapsulation. For example, when is the TTL of the encapsulated packet decremented? => It is decremented in the same way that it's done for IP in IP tunnelling. I can add that. Finally, the use of multiple UDP tunnelling schemes (vanilla or with TLV-header) seems undesirable, and it would be useful to document why this is necessary, for those not familiar with the working group history. => Well, I personally agree with you. However, there was a concensus call in the WG about this particular issue and it was decided (narrowly) that we should include support for this. Based on my understanding, some people wanted to be able to efficiently use GRE tunnelling. While this is not useful for MIPv6 mobile nodes (typically GRE tunnelling is done in the network), people wanted to be able to use this specification for PMIPv6, which uses MIPv6 without the mobile node's involvement. Hence, the supposed need for GRE tunnelling. If you ask me why GRE tunnelling is needed at all in IPv6 then I'm not the right person to represent that opinion because I'm completely against it :) I hope this helps. Hesham ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [EMAIL PROTECTED] if you reply to or forward this review. In summary, this draft seems to be on the right track but has some open issues, as discussed below. The NAT keep-alive interval (Section 5.3 and 7) is set to 110 seconds by default, unless configured by the home agent in a binding acknowledgement. While the default interval seems a safe choice, it's not clear why it was chosen, or when it's appropriate for a home agent to signal an alternative interval. The draft would benefit from an explanation of this choice, and further discussion of the issues inherent in choosing an appropriate keep-alive interval (Section 3.5 of RFC 5405 considers this point, and might be appropriate to reference). The NAT detection mechanism specified in Section 5.2 relies on the NAT rewriting the source address of the outer IPv4 header, but not the IPv4 address carried in the binding update payload. I'm not familiar with the way in which mobile IPv6 uses IPsec ESP, but if it's used in a way that provides integrity protection but not confidentiality, issues may arise with NAT devices that rewrite IPv4 addresses in the UDP payload, causing the integrity check to fail (this is why STUN [RFC5389] provides an XOR-MAPPED-ADDRESS attribute to obfuscate the IP address). It's not clear that the use with ECN is fully specified. Section 5.1.1 notes that it's "RECOMMENDED that the ECN information is copied between the inner and outer header as defined in [RFC3168]" - is the intent that the full-functionality option defined in RFC 3168 is recommended? If so, it would be useful to state that explicitly. It also seems that UDP encapsulation will prevent the use of ECN over the tunnel, since the UDP API doesn't allow access to the ECN bits, and cause different ECN (and hence congestion) behaviour depending on the encapsulation method used. This should be called out in the draft. Processing of other IP header fields (e.g. the diffserv field and TTL) when encapsulated in UDP tunnels also seems poorly defined. The intent, presumably, is for the choice of tunnelling mechanism to be hidden from higher-levels, but the exact en-/de-capsulation steps needed to achieve this must be specified for the UDP encapsulation. For example, when is the TTL of the encapsulated packet decremented? Finally, the use of multiple UDP tunnelling schemes (vanilla or with TLV-header) seems undesirable, and it would be useful to document why this is necessary, for those not familiar with the working group history. Regards, -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [P2PSIP] P2PSIP diagnostics: PING discussion
On 13 Nov 2008, at 09:24, Roni Even wrote: I am not sure what you mean NTP refresh, if the test was using the system clock than you would expect in XP that it will be updated every tick which is 10 or 15 msec which can account for the error. NTP is used in RTP (RFC 3550) for synchronization and the RTP time is using the system clock which may add skew but it is not because of NTP. One minor clarification: RTP uses an NTP format timestamp, but it doesn't require the use of NTP. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: SAFE BoF in Vancouver
On 21 Nov 2007, at 00:46, Ted Hardie wrote: At 6:38 PM -0600 11/20/07, James M. Polk wrote: But Ted, you're going to Geopriv? So how does this work? I'm trying to focus on the general problem (particularly the apps open conflict), rather than my own ability to be there. I'm conflicted either way, but lots of other APPs people would be free on Friday. Similar for MEDIACTRL; some might still be conflicted, but a larger number would be free. I understand from Mary Barnes that she would have a conflict with the Friday slot, so it may be unsolvable, but I hope there may still be a way. There's also a desire to avoid BoFs late in the week, to give time for hallway discussions on the outcome (as Pete Resnick has just mentioned on the WG chairs list). -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SAFE BoF in Vancouver
On 20 Nov 2007, at 19:07, Ted Hardie wrote: At 1:59 PM + 11/16/07, Colin Perkins wrote: The following BoF has been proposed for the Vancouver IETF. There is a mailing list <[EMAIL PROTECTED]> for discussion. This seems to be scheduled against both the Applications area open meeting and a RAI group focused on media servers. Both groups would have an interest in following this work and discussing where future IETF work in this area will happen. Is there still a possibility of adjusting this timing? I understand, of course, that not every conflict can be resolved, but it would be useful to know whether this is still something that might be addressed. We're aware of the conflicts, but this is the least bad scheduling we've been able to find. If you have suggestions for a better slot, we're open to ideas. Regards, Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
SAFE BoF in Vancouver
The following BoF has been proposed for the Vancouver IETF. There is a mailing list <[EMAIL PROTECTED]> for discussion. Colin SAFE - Self-Address Fixing Evolution BoF Chairs: Colin Perkins ([EMAIL PROTECTED]) Markus Isomaki ([EMAIL PROTECTED]) Mailing list: https://www1.ietf.org/mailman/listinfo/safe Various NAT hole-punching techniques such as IPsec NAT traversal, Teredo, and STUN/ICE send periodic UDP keep-alive messages to keep their NAT binding alive. However, a drawback of these techniques is their chattiness which is a result of the host application not knowing the NAT's binding lifetime (IPsec NAT traversal, STUN/ICE) or because the application is unable to extend the lifetime of the NAT's binding (Teredo). The endpoint has to send periodic packets which consume power on battery powered devices, consume network bandwidth, and place an unnecessary load on servers. There are two approaches to resolve the problem of chattiness. The first is to interact directly with the NAT using a NAT control protocol. Several of these protocols exist which unfortunately have different drawbacks: * incremental deployment is not possible with MIDCOM, NSIS-NSLP, UPnP IGD, or NAT-PMP. With all of these protocols, both the NAT and the endpoint have to support the same protocol * nested NATs are not possible with UPnP IGD or NAT-PMP * topology awareness is required of MIDCOM * security must be established between the controlling entity and the NAT for MIDCOM and NSIS-NSLP * UPnP IGD uses broadcasts packets and NAT-PMP expects the NAT to be the default gateway; neither work well on routed networks The second approach is to empirically test the NAT's binding lifetime, as done by Teredo. This can optimise the keep-alive traffic based on the NAT's binding lifetime, but cannot extend the duration of the binding lifetime. Also, empirical testing does not always give reliable results due to varying behaviour of NAT and firewall implementations. This BoF is intended to discuss a newly-proposed technique for using STUN to discover, query and control firewalls and NATs, that can eliminate UDP keep-alive traffic. The BoF will review the problem space and existing work, and decide if there is a need for new work in the area, and if the IETF is an appropriate home for that work. The intent is not to form a new working group at this time, but to gauge interest in work in this area, and consider an appropriate future home for that work. Agenda: Introduction .. (Chairs, 10) Problem statement and scope . (Wing, 15) Survey of existing work ... (Barnes, 30) draft-eggert-middlebox-control-survey-01.txt NAT/Firewall control with STUN .. (Wing, 15) draft-wing-behave-nat-control-stun-usage-05.txt Discussion (20) Future directions . (Chairs, 30) -- version: 1.5, 16-Nov-2007 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt
are updated as follows. When assigning RTP RTCP > Control Packet types, IANA is requested to assign unused values from > the range 200-223 where possible. If that range is fully occupied, > values from the range 194-199 may be used, and then values from the > ranges 1-191 and 224-254. This improves header validity checking of > RTCP packets compared to RTP packets or other unrelated packets. The > values 0 and 255 are avoided for improved validity checking relative to > random packets since all-zeros and all-ones are common values. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt
On 17 Jul 2007, at 16:33, [EMAIL PROTECTED] wrote: idnits 2.04.12 found a couple of reference nits: Checking references for intended status: Proposed Standard -- -- (See RFC 3967 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2032 (ref. '3') (Obsoleted by RFC 4587) This is intentional, and noted in the PROTO write-up in the tracker, since the aim is to reference the FIR and NACK packets defined in RFC 2032, then removed when the H.261 payload format was updated. -- Possible downref: Normative reference to a draft: ref. '6' (No intended status found in state file of draft-ietf-avt-rtcpssm) The draft-ietf-avt-rtcpssm-13.txt draft is intended for standards track, so this is not an issue. == Outdated reference: A later version (-17) exists of draft-ietf-mmusic-ice-15 ICE -16 and -17 were both submitted after this draft. The reference was current on submission. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-avt-rtp-and-rtcp-mux-05.txt
David, Thanks for the review - some comments inline. On 16 Jul 2007, at 22:35, [EMAIL PROTECTED] wrote: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avt-rtp-and-rtcp-mux-05.txt Reviewer: David Black Review Date: 16 July 2007 IETF LC End Date: 17 July 2007 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The draft is generally in good shape, although one needs to be an RTP expert to understand all the details. The only "open issue" is the missing instructions to IANA for RTCP packet type registration - from a technical standpoint, this is a nit, but getting it right is of sufficient importance to avoidance of future restrictions RTP/RTCP multiplexing that I've flagged it as an open issue. Everything else in this review is an editorial comment, although the absence of the explanation of the mechanics of the RTP/RTCP conflicts makes that section of the draft difficult to read. Section 1 talks about NAT (Network Address Translation) as a motivation, but the real motivation appears to be NAPT (Network Address Port Translation). This ought to be discussed, and I strongly suggest an Informative reference to RFC 3022. The term "NAT pinhole" also needs to be explained here to connect the problems caused by two UDP ports to NAPT usage, and it may be useful to mention firewall pinholes as a related issue. We can change "Network Address Translation (NAT)" to "Network Address Port Translation (NAPT)" in the Introduction, and add a reference to RFC 3022, sure. Sloppy terminology on my part. Would changing "since opening multiple NAT pinholes can be costly" to "since maintaining multiple NAT bindings can be costly" address your other concern? Section 4 should explain the mechanics of the RTP/RTCP conflict: - The RTCP PT is bits 8-15. - The RTP PT is bits 9-15. - RTP uses bit 8 in that word for a M (Marker) bit that may be on or off. The latter item is the cause for needing to check for whether the RTCP PT conflicts with either the RTP PT or the RTP PT + 128. The draft hints at this already in section 4: This demultiplexing method works because the RTP payload type and RTCP packet type occupy the same position within the packet. If you think more is needed, please suggest wording, and I'll add it. The last 2 paragraphs in Section 4 before the final Note in that section need attention: - The paragraph on registration of new RTCP packet types needs to instruct IANA on what rules to enforce. The use of "SHOULD" in the current text is not sufficient, instead this needs to be restated as instructions to IANA on how to assign RTCP packet types and noted in the IANA considerations section. Makes sense. I suggest adding something like the following to the IANA considerations: The rules for assignment of RTP RTCP Control Packet Types in the RTP Parameters registry are updated as follows. When assigning RTP RTCP Control Packet types, IANA is requested to assign unused values from the range 200-254 where possible. If that range is fully occupied, values from the range 194-199 may be used, and then values from the range 1-191. This improves header validity checking of RTCP packets compared to RTP packets or other unrelated packets. The values 0 and 255 are avoided for improved validity checking relative to random packets since all-zeros and all-ones are common values. - In this text in the second paragraph: Given these constraints, it is RECOMMENDED to follow the guidelines in the RTP/AVP profile [7] for the choice of RTP payload type values, Insert the word "dynamic" between "the choice of" and "RTP payload type values" for clarity. The guidelines in the RTP/AVP profile apply to both static and dynamic RTP payload types, so inserting "dynamic" here would be incorrect. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dccp-rtp (RTP and the DatagramCongestion Control Protocol (DCCP)) to Proposed Standard
Dan, On 8 Jun 2007, at 18:38, Dan Wing wrote: The draft is easy to read and understand. 1. Section 5.2, "Service Codes", refers to DCCP service codes. Several are defined in this specification (SC:RTPA, SC:RTPV, SC:RTPT, and SC:RTPO). The draft needs to say something about the relationship between the SDP media type field (the "audio" and "video" of m=audio and m=video) and the DCCP service code -- I expect they SHOULD match. Yes - I'll clarify. 2. I wonder if an optimization would be useful, where "a=dccp-service-code:SC:RTPV" is assumed if the associated media type is "video" (m=video); a similar optimization seems reasonable for audio (RTPA is assumed when the media type is audio (m=audio)). I tend to prefer explicit to implicit, so while this would reduce the size of the SDP slightly, I'm not sure it's worthwhile. 3. I believe the draft needs to define a value for its IANA- registered DCCP service codes, as service codes appear to be sent in the DCCP packets themselves according to RFC4340. The service codes sent in the DCCP packets are the 4-character ASCII strings listed (e.g. RTPV). 4. I'm surprised a=rtcp (RFC3605) lacked normative language in section 5.1. I know for UDP this is widely considered best practice. I'm not confident that we should expect DCCP will be able to avoid that quagmire. I suggest adding something like: If RTCP is to be sent on a separate DCCP connection to RTP, the RTCP connection SHOULD use the next higher destination port number, unless an alternative DCCP port is signalled using the "a=rtcp:" attribute [13]. For improved interoperability, "a=rtcp" ^^^ SHOULD be used whenever an alternative DCCP port is used. ^^^^^^^^^ Makes sense - I'll add this. Cheers, -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
tsv-dir review of draft-shacham-sipping-session-mobility-03.txt
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The purpose of the mechanisms described is to transfer media streams, likely based on RTP, between devices. This is done using SLP to discover devices, followed by a SIP exchange to negotiate new (RTP) media streams. The use of SLP and SIP does not appear to offer concern from a transport perspective (I have not reviewed it for correctness from an SLP or SIP perspective). The main transport concern with this draft is with how to ensure retargeted RTP streams don't congest the new network path. The draft touches on this issue in Section 6, hinting that application-level measures may be used to adjust, but it's not clear that is sufficient. An ideal response to ensure congestion safety would be to slow-start on the new path, but that's also problematic since it would unnecessarily disrupt the media on paths that can sustain the required rate. Given these conflicting constraints, the best solution we have available might be to signal the new link capacity in the SIP exchange if the bottleneck bandwidth is known, and be prepared to react to congestion within a small number of round-trip times (e.g. perhaps using early RTCP, or transport-level feedback to signal the need to adapt). The draft should include more discussion of these issues, and the potential solutions. Section 5.2.1.2 implies that the connections for real-time media do not need to be established before use. This is not the case if comedia (RFC 4145) is used, e.g. for RTP streams running over TCP, TLS, or DCCP. The order of connection setup should be addressed. The draft seems to ignore the presence of NAT boxes which might disrupt media connectivity. An ICE exchange will likely be needed to work around this during handover. At what point in the call flows should this be done? Similarly, the RTPSEC work is considering media- path keying for SRTP (e.g. DTLS or ZRTP), which also needs to be done during the handover, but is not mentioned. None of these are not insurmountable problems, but they should be addressed before the draft is ready for publication. -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RFC 4612 - historic status
John, Without wishing to comment on the specifics of RFC 4612... On 14 Aug 2006, at 09:13, John C Klensin wrote: --On Monday, 14 August, 2006 03:41 -0400 "Paul E. Jones" <[EMAIL PROTECTED]> wrote: Brian, The problem with using "image" is that it would mean that a gateway would have to do one of: 1) Close the audio session and open an image session 2) Open a second "image" session during mid-call 3) Open both an audio session and image session at the outset For a lot of reasons, none of those options are preferred. In the latter case, gateways just waste memory and CPU resources servicing sockets that are never used. In the first two cases, there is a lot of extra signaling on the wire. (For SIP networks, and especially IMS-based SIP networks, this is horrible due to the widespread use of UDP, slow timer ... Paul, I think there may be a fundamental misunderstanding, or at least difference in understanding, about top-level media types implied in the above. From a process standpoint, if you are just finding out about it now, something has, IMO, failed (see my other note). But, putting that aside... The "text/" top-level type, and only the "text/" top-level type has the property that one can reasonably expect to be able to display the contents to the user without understanding the subtype. Whether that is realistic or not, and how narrowly that requirement should (or must) be interpreted to make something "text/" has been widely debated in the past. But, for all other media types, one cannot interpret them without both the top-level type and the subtype. As far as transmission issues are concerned, the type-subtype distinction is largely irrelevant: there is not, meaningfully, an "audio session" or an "image session" as far as the media type is concerned. This is not correct when it comes to RTP sessions signalled using media types in SIP/SDP. In those cases, Paul is correct that the session is negotiated to convey only one top level media type (e.g. only audio), and switching to an image format would require a separate session. Discussion of why this is the case should probably happen on the AVT mailing list, since that is the working group responsible for RTP, or on rai-discuss. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Vancouver schedule
Fully agreed - the new schedule fits much better with my jet lag. Also, I really liked the way some of the rooms had tables and power for the front two rows... Colin On 10 Nov 2005, at 06:13, Romascanu, Dan ((Dan)) wrote: Actually I prefer this schedule because it does not call me for a night session after dinner, and I suspect that many people coming from European time zones may feel the same. As Ole points out, availability of coffee during the afternoon sessions would help us make it easier through the long afternoon meeting period. Regards, Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Falk Sent: Thursday, November 10, 2005 9:40 AM To: ietf@ietf.org Subject: Vancouver schedule Am I the only one dissatisfied with the meeting schedule? I find that the run of meetings from 1300 to 1930 is just too long, especially the four hour period from 1300 - 1710. I would strongly prefer our 'traditional' schedule over the current one. Even if I can't know which continent I'll be meeting in, it would be nice to know that the daily schedule is one I can live with. ;) --aaron ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Colin Perkins http://csperkins.org/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RTP vs. MIME
On 22 Jul 2005, at 16:25, Bruce Lilly wrote: ... To the extent that transport protocol overhead has been erroneously included in what is purported to be a media format specification, that is a problem with the registration and/or specification. There is nothing in the MIME rules which requires an RFC to include only a MIME registration template. Despite your attempts to claim otherwise, it is entirely legitimate and appropriate for an RFC to include both a media type registration and some other specification. And I would add that that causes problems for MIME reviewers and implementers, and said problems would be alleviated by a separate registry with separate rules, where RTP-specific registrations can conflate transport bits with format bits or not without causing problems for MIME reviewers and implementers. The documents clearly separate "transport bits" from "format bits", so this is not an issue. This separation has been repeatedly explained to you, and is documented in these particular specifications, and the RTP specification (RFC 3550 -- STD 64). You are confusing the applicability statement which describes RTP-specific processing with the description of the media type. I see nothing in 3267 labeled "applicability statement"; I do see multiple "format" descriptions. There is no requirement in RFC 2026 for the explicit label "applicability statement" to appear anywhere, so this cannot be your complaint. You will find several format descriptions in the RFC: two RTP payload formats, and two media types. The two RTP payload format definitions (section 4 of RFC 3267) describe how the two media types are conveyed within RTP, but don't define the media types. The two media types are described in section 5 of RFC 3267, with reference to the 3GPP specifications which define the bit patterns and semantics of the speech frames. The media type registrations are in section 8 of RFC 3267. You are, as I previously stated, confusing the RTP specific processing (an "RTP Payload Format") with the description of the media type. The formats are specified in the following: [1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP). [3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding functions", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). 26.090, according to http://www.3gpp.org/ftp/Specs/html-info/26090.htm is "AMR speech Codec; Transcoding Functions". Transcoding functions and media formats are separate types of specifications. "Frame structure" specifications *might* be applicable, *if* the media format is identical to said "frame structure", but I see nothing in the registration form that says so, and several parts of section 5 imply otherwise; sections 5, 5.1, and 5.2 make no reference to what precisely comprises "speech frames" or "speech bits" or indeed why two different terms are used. The 3GPP documents are, without any doubt, both applicable and appropriate specifications for these formats. There are several dozen independent and interoperable implementations based on the specifications, using the media formats both with RTP and in more traditional MIME contexts such as file downloads. These implementations are in daily use by tens of millions of users. By any measure, this meets the necessary standards of specification clarity for the community which is implementing the standard. That is a very good reason for a separate registry. There is no question that the proposed media type did not meet the requirements for registration in the text top-level MIME registry; it should never have been proposed to register it there. With a separate RTP registry, those interested in RTP can establish whatever rules or lack of rules for things to be considered as RTP "text". You seem to be complaining because we asked the advice of the MIME community on whether the 3GPP timed text format should be registered under text or video, and then took that advice. Quite how this can be construed as a failure of the process, or as a statement that RTP is not appropriate for use with MIME types is beyond me. One might as well ask whether or not an elephant is eligible for a dog license. The question shouldn't even be asked. And it wasn't a simple matter of "took that advice", there was argument that even though the media clearly was incompatible with text, that it should be registered under text anyway, presumably merely because some RTPers would like it that way wi
Re: RTP vs. MIME
On 20 Jul 2005, at 18:26, Bruce Lilly wrote: Date: 2005-07-12 15:58 From: Colin Perkins <[EMAIL PROTECTED]> On 12 Jul 2005, at 13:43, Bruce Lilly wrote: Re: Ietf Digest, Vol 15, Issue 19 Date: 2005-07-11 19:13 From: Colin Perkins <[EMAIL PROTECTED]> [...] As will I, since your message includes many misstatements of facts relating to the RTP transport protocol and the way in which it conveys media data. I recall making no statements about RTP or the way it conveys data save for the fact that that is as irrelevant to defining a media type as are details of TCP or UDP etc. You have made, and continue to make, numerous statements about RTP payload formats and their associated media type registrations which are factually incorrect. The most obvious of these is your insistence on treating the RTP transport protocol headers as part of the media data, as you repeatedly do in the message to which I am replying. The audio/amr format contains identical media data, but the RTP transport is defined to strip the initial magic number, which is redundant with fields in the RTP protocol headers. The wide band version of AMR, and the related EVRC formats are similar. Audio/amr explicitly specifies two separate media formats; if it were merely a matter of some RTP processing, such processing could have been specified separately from the format. The processing is specified separately from the format, so I don't understand this comment. Audio/amr is defined in RFC 3267. The registration forms state: This type is defined for transfer via both RTP (RFC 1889) and stored-file methods as described in Sections 4 and 5, respectively, of RFC 3267. RFC 3267 sections 4 and 5 indeed define separate formats; the section headings both refer to "Format" (plural in the case of section 4). Since RFC 3267 registers both audio/amr and audio/amr-wb and defines their use with RTP and as file formats, section 4 correctly refers to "Formats" in the plural. For each of the two media types, section 4 of RFC 3267 describes the RTP-specific process by which that format is transported in RTP, and section 5 describes the file format (a sequence of concatenated frames of the media format preceded by a magic number). You are confusing the applicability statement which describes RTP-specific processing with the description of the media type. The registration form data for "Public [sic; should be 'Published'] specification" says only Please refer to Section 11 of RFC 3267. RFC 3267 section 11 provides no format specification at all; it is the RFC section listing references. The formats are specified in the following: [1] 3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech transcoding", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [2] 3GPP TS 26.101, "AMR Speech Codec Frame Structure", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP). [3] 3GPP TS 26.190 "AMR Wideband speech codec; Transcoding functions", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [4] 3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). There are references 1-4 from section 11 of RFC 3267. This is made clear in sections 3.1 and 3.2 of RFC 3267, but you are correct in noting that the registration template doesn't clearly reference the formats. We'll add this to the errata list for the RFC. 2) As has been mentioned previously, the text/t140 format, which started this discussion, No, the discussion started with an IESG I-D requesting discussion, and that followed a failed attempt to register "text/3gpp-tt" in the MIME registry despite many incompatibilities of the proposed format with the requirements for registration under the "text" top-level type. As mentioned previously, that format is now being registered under video. I believe this is an example of the MIME review working well: in the initial request for MIME review for the 3GPP-TT format, I said: "I'm not sure we have the experience to decide this in the AVT working group. The question is about draft-ietf-avt-rtp-3gpp-timed- text-04.txt: is it appropriate to register the format under the video or text top-level type?" [1]. There was considerable discussion, and as a result of that discussion, the format was registered under the video top-level type. That is a very good reason for a separate registry. There is no question that the proposed media type did not meet the requirements for registration in the text top-level MIME registry; it should never have been proposed to register it there. With a separate RTP re
Re: RTP vs. MIME (Was Re: Ietf Digest, Vol 15, Issue 35)
On 12 Jul 2005, at 13:43, Bruce Lilly wrote: Re: Ietf Digest, Vol 15, Issue 19 Date: 2005-07-11 19:13 From: Colin Perkins <[EMAIL PROTECTED]> To: iesg@ietf.org CC: ietf@ietf.org, Stephen Casner <[EMAIL PROTECTED]> Now the initial internet-draft deadline has passed I want to respond to the main points of this message. I don't believe that a point-by- point rebuttal is useful, due to the length of the message and repetition of arguments. Indeed repetition is not helpful, particularly when it is a repetition of a misstatement of position or of facts. I'll limit my remarks to those cases. As will I, since your message includes many misstatements of facts relating to the RTP transport protocol and the way in which it conveys media data. The audio/amr format contains identical media data, but the RTP transport is defined to strip the initial magic number, which is redundant with fields in the RTP protocol headers. The wide band version of AMR, and the related EVRC formats are similar. Audio/amr explicitly specifies two separate media formats; if it were merely a matter of some RTP processing, such processing could have been specified separately from the format. The processing is specified separately from the format, so I don't understand this comment. The thrust of most of the rest of this message seems to be that the use of MIME type to identify RTP audio and video formats is uncontroversial, Not completely uncontroversial, just less damaging than incompatible text registrations. but you have a serious concern over use of text formats with RTP, since you believe these will disrupt MIME operations due to "leakage". This concern difficult to justify for several reasons: It's not about "leakage", it hasn't been about "leakage"; that is a minor issue that has been turned into a strawman in order to demonstrate how easily it can be knocked down. 1) These types have been in widespread use for several years now; there have been no reports of actual operational problems, opposed to the theoretical arguments being made here. No, the proposed text/3gpp-tt hasn't been in use as a MIME type. Of course there are no operational problems; they have been nipped in the bud. To the extent that text/t140 hasn't caused operational problems, that is because it has been largely ignored (not without cost) because it is in fact not a valid MIME type. There is no such thing as text/3gpp-tt; that format is being registered under the video top level type, as a result of comments during MIME review. More on this, and on text/t140, below. The arguments are not "theoretical"; mixing disparate types of registrations in the single MIME registry, some of which do not use MIME mechanisms at all, makes extra work for implementers -- work which yields no benefits, only wastes effort and creates confusion. If our specifications and procedures do not benefit implementers -- indeed when they cause confusion and busy-work -- there is a problem which needs to be addressed. In this case, separate registries for MIME and non-MIME content is an appropriate solution. 2) As has been mentioned previously, the text/t140 format, which started this discussion, No, the discussion started with an IESG I-D requesting discussion, and that followed a failed attempt to register "text/3gpp-tt" in the MIME registry despite many incompatibilities of the proposed format with the requirements for registration under the "text" top-level type. As mentioned previously, that format is now being registered under video. I believe this is an example of the MIME review working well: in the initial request for MIME review for the 3GPP-TT format, I said: "I'm not sure we have the experience to decide this in the AVT working group. The question is about draft-ietf-avt-rtp-3gpp-timed- text-04.txt: is it appropriate to register the format under the video or text top-level type?" [1]. There was considerable discussion, and as a result of that discussion, the format was registered under the video top-level type. does comply with the MIME registration rules for the text media type. The format is plain UTF-8 text with implicit timing data, there are no embedded control characters, the CRLF sequence is only used to identify line breaks, and a language tag is available. RFC 2793 (the AVT 2793bis draft is unavailable) specifies: The 2793bis draft was published as RFC 4103. This is an example of a T140 RTP packet without redundancy. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=0 |M| T140 PT | sequence number
Re: Ietf Digest, Vol 15, Issue 19
Now the initial internet-draft deadline has passed I want to respond to the main points of this message. I don't believe that a point-by- point rebuttal is useful, due to the length of the message and repetition of arguments. Comments follow inline. On 6 Jul 2005, at 18:01, Bruce Lilly wrote: Date: 2005-07-06 04:06 From: Stephen Casner <[EMAIL PROTECTED]> Stephen, you wrote: That's not it. Of course all the existing registrations would be copied. However, all of the many RTP-related RFCs that refer to MIME registrations would become obsolete and need to be revised. A fair number of those RFCs are referenced by other SDO's documents. Are any of those RFCs on the Standards Track? Are they all at full Standard? Those which are Standards Track but not yet full Standard need to be followed up on to advance on the Standards Track, and that would be a good time to do a global replace of MIME with RTP and add an IANA considerations section directing IANA to mark the type in the MIME registry as obsolete. Should take about 30 seconds to do that. The MIME registrations will never go away (unfortunately for MIME), so if a particular implementer goes ferreting through the MIME registrations because he has an old copy of a document that says MIME, he'll still find the type. Some of the motivations for moving the RTP namespace into the MIME namespace were: - To avoid different names for the same media format, such as MIME's audio/basic and RTP's PCMU. More on this below. To date, I know of no "same media format" for MIME and RTP; Magnus specifically mentioned audio/amr, which has different formats, and alluded to a tiny number of others but was not specific. The simplest is audio/L16. For historical reasons, audio/basic and audio/pcmu are identical but have different names: eliminating duplicate names for such formats was one of the initial reasons for using the MIME namespace for RTP. The audio/amr format contains identical media data, but the RTP transport is defined to strip the initial magic number, which is redundant with fields in the RTP protocol headers. The wide band version of AMR, and the related EVRC formats are similar. ... The AVT working group did a lot of work between then and now to specify the mechanism for the registrations and to create registrations with what I believe was careful attention to detail. This process has imposed very little load on the "MIME folks"; in fact, it has received little notice until the recent consideration of two subtypes under the text major type. That is because of the way MIME works and has always worked; the text type is for media containing human-readable (w/o software) text. The fallback is to text/plain, which is what the Internet Message Format carries in the absence of MIME. There are relatively few interoperability considerations for audio and video media subtypes, so the attitude is largely "ho hum, another subtype; who cares". Not for text. More below. ... There is no proposal to change the way email, html, and fax use MIME types. On the contrary, any registration of a format which requires software for interpretation, contains binary content, etc. under the MIME text type would require massive backwards compatibiliy- and interoperability- breaking changes. Given the mission-critical use of the affected applications (e.g. IETF business such as this and other mailing lists) that is simply unacceptable. The thrust of most of the rest of this message seems to be that the use of MIME type to identify RTP audio and video formats is uncontroversial, but you have a serious concern over use of text formats with RTP, since you believe these will disrupt MIME operations due to "leakage". This concern difficult to justify for several reasons: 1) These types have been in widespread use for several years now; there have been no reports of actual operational problems, opposed to the theoretical arguments being made here. 2) As has been mentioned previously, the text/t140 format, which started this discussion, does comply with the MIME registration rules for the text media type. The format is plain UTF-8 text with implicit timing data, there are no embedded control characters, the CRLF sequence is only used to identify line breaks, and a language tag is available. The claimed "massive backwards compatibility- and interoperability- breaking" changes you suggest would occur have not been needed in the five years since this format was registered; or as a result of the 8 years worth of deployment of other RTP formats signalled using a range of MIME media types within SDP. ... The simple rule -- necessary to ensure interoperability -- is "MIME registry, MIME rules". If the RTP specification writers were to conform to the MIME rules -- which are in plain view in RFCs 2046 & 2049 -- there wouldn't be an issue; mind you, the types might be of little interest o
Re: I-D ACTION:draft-iesg-media-type-00.txt
Considering the text/t140 media type (RFC 4103) which caused this controversy: On 1 Jul 2005, at 22:49, Bruce Lilly wrote: ... While the proposed RTP "text" types would present a small but non-zero security risk, the essential properties of MIME text types of having the characteristics above are not shared by the RTP types: o clearly software which understands the format is required. The format includes embedded binary formatting information No, it does not. The format contains only plain UTF-8 text. You may be confused because the RFC describing the media type also explains how that type is to be transported within RTP, since several features of RTP are configured according to the media type parameters, and repeats the definition of the RTP headers. o not readable without software; indeed as pointed out, the RTP types cannot even be save in a file format without conversion software The contents of the RTP packets are plain UTF-8 text. It can trivially be saved as a text/plain file, but doing so will lose the timing information provided by the RTP headers (it is the presence of the additional timing parameters that require this to be a separate media type to text/plain for use with RTP). There are other media types, under audio/* and video/* where this is a more complex process, but that does not affect this case. o it would be most unreasonable to try to present the RTP types without appropriate interpretation software One clearly needs an implementation of a transport protocol to receive data sent in that protocol. Once the data has been received from the transport protocol, the contents are plain UTF-8 text with implicit timing information. o CRLF octets may appear in the RTP types (as binary data 0x0D0A) where they do not represent a line ending. Note the BCP 14 "MUST" keyword in the approved RFC 2046 text, indicating interoperability issues of a serious nature (refer to BCP 14 section 6). [BCP14] The text/t140 format contains UTF-8 text. The CRLF octets are only used to represent a line ending, not in any other case, in conformance with these rules. o the proposed RTP registrations provide no charset parameter, defaulting to US-ASCII as far as MIME implementations are concerned The charset is always UTF-8 for text/t140. When signalled in SDP, there is also provision for a language tag. o fallback treatment as text plain is a problem for the RTP type because of the incompatibilities above. The content is plain UTF-8 text. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iesg-media-type-00.txt
On 1 Jul 2005, at 14:02, Robert Elz wrote: Date:Fri, 1 Jul 2005 12:57:15 +0100 From:Colin Perkins <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | I do not find this argument persuasive, since the media types in | question have been deliberately specified as framed types to avoid | this issue. I believe that you're both seeing, and missing the point, at the same time there. I'd expect that much of the problem is that media types should depend upon the data that is carried, and how that is to be represented, and should not depend in any way upon the mechanism used to carry them. Some of the objections may have been from people who simply assumed that, and could not believe that a parameter that is intended to specify the format of data was instead (or additionally) being used to specify a format for the transport protocol used to carry the data, or being linked to such a thing. You're misunderstanding what is being done. The media type does specify the format of the data, not of the transport protocol. In addition to this, the specification defines how to populate the RTP framing based on the implicit properties of the media (e.g. timing). For example, if I receive an RTP stream carrying a text/whatever, and store the content (unchanged, but removed from its RTP transport) into a file, what media type do I use to identify the file? If it remains text/whatever (same value) then it will appear as that when I send it via e-mail, or a web browser fetches it. If it isn't to be text/ whatever then what on earth is it? Something random and unidentified? If there is a media type for it, that is what should be being used by RTP. The media type registrations explain what is to be done. There are three possibilities: 1) In some cases, you use the exact same media type for the file format as for the RTP payload format, since they contain the same data formatted in the same way. I don't believe this is in the least controversial. 2) In some cases, the media type registration says "defined only for transfer via RTP". This usually means no-one saw the need for a file format at the time the registration was done, and didn't spend the effort to decide how the media should be stored. This should probably be rectified at some point. 3) In some cases, there was a pre-existing file format defined in such a way that makes it impossible to use within RTP. This is usually the case when the file format requires reliable delivery. Since the media format differs in the two cases, they use different media types. This case is the controversial case, since it is where types may leak outside their domain of applicability. The question becomes: will the leakage go away if we separate the registries? I do not believe it will. People will continue to ignore the specifications, and will continue to use names in the wrong context. The split will remove one problem (people use the wrong media type when converting between RTP and a stored file) and cause another (people use the RTP name instead of the MIME media type when converting between RTP and a stored file). It's a lot of work, for no benefit. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iesg-media-type-00.txt
On 31 May 2005, at 20:50, [EMAIL PROTECTED] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Engineering Steering
Group Working Group of the IETF.
Title: A question on Media Type Registrations
Author(s): T. Hardie
Filename: draft-iesg-media-type-00.txt
Pages: 9
Date: 2005-5-31
This document poses a question to the community on the future of the
IANA Media Type Registry. It presents three potential future
courses
of development and asks that feedback on these be provided to the
IESG.
The idea of using the MIME media types registry to identify types
that are carried predominantly by RTP was suggested at a meeting of
the AVT working group, with participation from the applications area
directors, in December 1997 [1]. The subject was discussed at several
following meetings, with an initial internet-draft being submitted in
February 1999 [2]. A later draft was reviewed on the [EMAIL PROTECTED]> mailing list [3], and eventually published as RFC
3555. At present, there are 71 media types registered for use
predominantly with RTP. These media types are widely used in the
voice over IP and media streaming communities, signalled within SIP
and RTSP.
There has recently been concern expressed in some quarters about the
use of media under the "text" top level media type within RTP. In
particular, the update to RFC 2793 for Draft Standard RFC status was
contentious, although it used the same text media type within RTP
framing as the original RFC. Much of the concern seems to stem from
the use of framed text media types, where the plain text media data
is embedded within some binary wrapper for transport, since there is
a belief that such data might "leak" into areas which don't
understand the transport protocol in which the data is framed.
I do not find this argument persuasive, since the media types in
question have been deliberately specified as framed types to avoid
this issue. The types are defined only in terms of transport within
RTP, and rely heavily on RTP framing and knowledge of the transport
protocol. An implementation that does not understand RTP will be
unable to receive the data: the type is simply not defined in a
manner that allows implementation independent of the RTP transport
protocol. Such framed text media types have been in use for over 5
years now, with no history of problems.
This does not, of course, preclude an incorrect implementation
producing data in some unspecified format which it labels with the
media type of one of these framed formats, and transmits within some
other transport protocol. The receiver of such data would clearly
have to be robust in the face of the malformed content, but that
robustness is needed whether or not framed media types exist. Indeed,
reliance on the property that unknown text formats can be treated as
"text/plain" and displayed directly to the user would seem to be a
security risk, unless those formats are carefully validated as
actually containing plain text of an appropriate character set,
without malicious control characters. The use of framed media types
does not change this property.
With this in mind, I turn to the three possible registry futures
presented in draft-iesg-media-type-00.txt. The second and third
proposals in section 2 of the draft ("MIME handling is the model for
other using protocols" and "Registry split") are both large and
backwards incompatible changes. Either change would register the 71
existing media types defined primarily for use with RTP framing
obsolete. These changes would require significant amounts of new
standards work, and would cause enormous confusion for users of RTP
payload formats and SDP. It would also affect the extremely large
deployed base of implementations. I see no benefit from either of
these changes, and many disadvantages.
The other option, "All media type protocols may specify handling", is
the status quo. I believe this is the appropriate direction for the
registry, although clarifications should be made to the registration
rules, perhaps updating RFC 3555, to better explain how framed types
are used. There are well defined and tested procedures for
registering media types, an extremely large deployed base, and no
history of problems with this approach.
The media types registry works well as currently specified. We have a
large installed base, and well developed procedures. I do not believe
it would be appropriate to make fundamental changes to these
procedures or the registry at this late stage.
Colin
[1] Minutes of AVT working group at the 40th IETF
[2] P. Hoschka, "MIME Type Registration of RTP Payload Types",
February 1999, draft-hoschka-rtp-mime-00.txt.
[3] Steve Casner, "Registration of RTP payload format names", message
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 23:04, Robert Elz wrote: Date:Tue, 12 Apr 2005 21:20:28 +0100 From:Colin Perkins <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | RFC 3555 allows media types to be defined for transport only via RTP. | The majority of these registrations are under the audio and video | top-level types, with a small number being under text. Is your | objection to any media type being defined only for transport via RTP, | or to text media types being defined only for transport via RTP? Not to either of those being attempted, but to the expectation that the "only via RTP" will, or can, ever be enforced. That is, to your earlier statement ... Sure, but if the display agent is unaware of the restrictions, it won't ever be able to receive the media data. You'd need to be able to show me how that can possibly be true, when I can trivially easily send e-mail with text/t140 in the Content-Type header. You can put anything you like in a Content-Type header, but that doesn't make the data meaningful without a specification for the content. The restriction for "only via RTP" is made by only specifying the framing rules for RTP transport; the necessary information to convey the type via non-RTP transports is simply not specified. There are many (more than 50) such media types registered, and they are widely implemented without the problems at which you are hinting. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 20:51, Robert Elz wrote: Date:Tue, 12 Apr 2005 19:03:03 +0100 From:Colin Perkins <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> | Sure, but if the display agent is unaware of the restrictions, it won't | ever be able to receive the media data. The example I have in mind in | "text/t140" which is UTF-8 text framed within RTP packets [RFC 2793]. | The media type is defined only for use with RTP, I'm not sure I believe that works. What prevents this message from containing an alternative to the text/plain that is (currently) its only body type, with a Content-Type: text/t140 field (and correctly formatted for that, as much as it can be in a e-mailbody) ? Or what prevents a HTTP response with Content-Type: text/t140? Sure, the rules for use of that content-type may have been violated, but what is your MUA (or browser) supposed to do when it receives the message? All it is likely to know is that it has received yet another odd text/unknown content type. And if it is to be displayed, treating it just like all other text/weird types as the fallback (better than nothing) option ? I think Ned's point (though he can certainly speak for himself) is that if rfc3555 is allowing registrations like that, then rfc3555 needs to be fixed, and any bogus registrations that have been made, need to be corrected. RFC 3555 allows media types to be defined for transport only via RTP. The majority of these registrations are under the audio and video top-level types, with a small number being under text. Is your objection to any media type being defined only for transport via RTP, or to text media types being defined only for transport via RTP? Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 19:45, Bruce Lilly wrote: Date: 2005-04-12 11:58 From: Colin Perkins <[EMAIL PROTECTED]> I have reviewed draft-freed-media-type-reg-03.txt, and have a number of comments intended to align the registration procedures with the current practice defined RFC 3555. These primarily arise due to the widespread use of media subtype names to identify formats that can be conveyed within RTP. The rules for display of text media types assume that such types are, to some extent, readable without special purpose viewing software. This is certainly true for most types, but some existing types have restrictions on their use which are incompatible with this rule (e.g. the "text/t140" type specified in RFC 2793 is a framed encoding defined only for transfer via RTP and cannot be directly displayed). RFC 2793 states "COMMON" usage, not restricted, and makes no mention of any sort of restrictions under Interoperability considerations! RFC 2793 also says: Applications which use this media type: Text communication terminals and text conferencing tools. The encoding considerations section of the registration limits this to RTP. The lack of clarity on where to specify restricted domains of applicability is one of the things I hope this update to the media type registration guidelines will fix. Surely when some content is reassembled from the individual packets, it can be presented without special purpose software (other than that required for charset issues and local presentation conditions). If it cannot be presented, it's difficult to imagine how the media type would be used in the stated intended applications. If a substantial amount (more than one MTU) of text/plain is transmitted via some application-level protocol over TCP (rather than RTP), one of course has to reassemble the content for the application layer for presentation. In what way does use of RTP instead of TCP (UDP, etc.) at a transport protocol layer change that? One might even ask in what sense -- at the application layer -- text/t140 is meant to be different from text/plain. Perhaps the issue is not so much with the registration procedure draft as with the text/t140 registration... or maybe RFC 2793 isn't a good example of the issue you have in mind. An alternative example would be draft-ietf-avt-text-red-05.txt which, due to the way SDP/SIP signalling works, needs to use the same top level media type as text/t140. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 17:57, [EMAIL PROTECTED] wrote:
...
The rules for display of text media types assume that such types are,
to
some extent, readable without special purpose viewing software. This
is
certainly true for most types, but some existing types have
restrictions
on their use which are incompatible with this rule (e.g. the
"text/t140"
type specified in RFC 2793 is a framed encoding defined only for
transfer
via RTP and cannot be directly displayed). The following edit to
Section
4.2.1 ("Text Media Types"), third paragraph, is one way to resolve
this
inconsistency, by noting that subtypes which are defined with
restricted
usage cannot necessarily be directly displayed:
...
NEW:
Beyond plain text, there are many formats for representing what
might
be known as "rich text". An interesting characteristic of many
such
representations is that they are to some extent readable even
without
the software that interprets them. It is useful, then, to
distinguish them, at the highest level, from such unreadable data
as
images, audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, and provided the
subtype
is not defined for restricted usage, it is reasonable to show
subtypes
of "text" to the user, while it is not reasonable to do so with
most
non
textual data. Such formatted textual data should be represented
using
subtypes of "text".
I'm quite sympathetc to the underlying problem, but IMO this change is
unacceptable, in that in order to make it work the fact that a given
subtype is intended for restricted usage would have to be known to the
display agent. The whole idea of having top-level types is predicated
on not needing this sort of exception information.
Sure, but if the display agent is unaware of the restrictions, it won't
ever be able to receive the media data. The example I have in mind in
"text/t140" which is UTF-8 text framed within RTP packets [RFC 2793].
The media type is defined only for use with RTP, and an agent that
doesn't know how to decode RTP framing (i.e. a sequence of UDP packets
with explicit time and ordering data) will never see the data.
Colin
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 12 Apr 2005, at 18:30, [EMAIL PROTECTED] wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 12, 2005 12:57 PM To: Colin Perkins Cc: iesg@ietf.org; ietf@ietf.org Subject: Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP [snip] I'm quite sympathetc to the underlying problem, but IMO this change is unacceptable, in that in order to make it work the fact that a given subtype is intended for restricted usage would have to be known to the display agent. The whole idea of having top-level types is predicated on not needing this sort of exception information. Ned, how would you reconcile the current text in your document with the practice specified in RFC 3555? It's been alleged that the documents are not in alignment. Assuming they really are out of alignment, I'd reconcile them by making whatever changes are appropriate in a revision to RFC 3555. Changing fundamental aspects of how media types are supposed to work and which vast tracts of code depend on is just not an option. The other changes I suggested were to align the draft with RFC 3555. This is a related change, primarily introduced because of the "text/t140 type" which is clearly textual data, but requires software to decode (and was registered under the RFC 3555 rules). Apologies if that wasn't clear. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP
On 15 Mar 2005, at 21:25, The IESG wrote:
The IESG has received a request from an individual submitter to
consider the following document:
- 'Media Type Specifications and Registration Procedures '
as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
iesg@ietf.org or ietf@ietf.org mailing lists by 2005-04-12.
I have reviewed draft-freed-media-type-reg-03.txt, and have a number of
comments intended to align the registration procedures with the current
practice defined RFC 3555. These primarily arise due to the widespread
use
of media subtype names to identify formats that can be conveyed within
RTP.
The rules for display of text media types assume that such types are, to
some extent, readable without special purpose viewing software. This is
certainly true for most types, but some existing types have restrictions
on their use which are incompatible with this rule (e.g. the "text/t140"
type specified in RFC 2793 is a framed encoding defined only for
transfer
via RTP and cannot be directly displayed). The following edit to Section
4.2.1 ("Text Media Types"), third paragraph, is one way to resolve this
inconsistency, by noting that subtypes which are defined with restricted
usage cannot necessarily be directly displayed:
OLD:
Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without
the software that interprets them. It is useful, then, to
distinguish them, at the highest level, from such unreadable data as
images, audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, it is reasonable to
show subtypes of "text" to the user, while it is not reasonable to do
so with most non textual data. Such formatted textual data should be
represented using subtypes of "text".
NEW:
Beyond plain text, there are many formats for representing what might
be known as "rich text". An interesting characteristic of many such
representations is that they are to some extent readable even without
the software that interprets them. It is useful, then, to
distinguish them, at the highest level, from such unreadable data as
images, audio, or text represented in an unreadable form. In the
absence of appropriate interpretation software, and provided the
subtype
is not defined for restricted usage, it is reasonable to show
subtypes
of "text" to the user, while it is not reasonable to do so with most
non
textual data. Such formatted textual data should be represented
using
subtypes of "text".
The addition of the "framed" encoding defined in section 4.8 is valuable
now that media types are being widely used outside the traditional email
environment. Since there are many media types defined to use RTP
framing,
and since RFC 3555 imposes additional registration requirements on these
formats, it would be useful to reference it from within this draft. The
following change to section 4.8 is one possible such edit:
OLD:
framed The content consists of a series of frames or packets without
internal framing or alignment indicators. Additional out of band
information is needed to interpret the data properly, including
but not necessarily limited to knowledge of the boundaries between
successive frames. Note that media types of this sort cannot
simply be stored in a file or transported as a simple stream of
octets, and therefore such media types are unsuitable for use in
many traditional protocols.
Additional restrictions on 7bit and 8bit are given in [RFC2046].
NEW:
framed The content consists of a series of frames or packets without
internal framing or alignment indicators. Additional out of band
information is needed to interpret the data properly, including
but not necessarily limited to knowledge of the boundaries between
successive frames and knowledge of the transport mechanism. Note
^
that media types of this sort cannot simply be stored in a file or
transported as a simple stream of octets, and therefore such media
types are unsuitable for use in many traditional protocols.
Additional restrictions on 7bit and 8bit are given in [RFC2046].
A commonly used transport with framed encoding is the Real-time
^^^
Transport Protocol, RTP. Additional rules for framed encodings
^^^
defined for transport using RTP are given in [RFC3555].
^^
Re: What problems does the draft cut-off solve? (was: Re: MARID back from the grave?)
On 2 Mar 2005, at 12:39, Margaret Wasserman wrote: I'd like to add-on to Spencer's point... At 6:14 AM -0600 3/2/05, Spencer Dawkins wrote: - Most important - we expect people to read the drafts before discussing them at face-to-face meetings, and thought that considering drafts submitted this morning didn't give working groups enough time to do necessary homework before having really confused and confusing discussions Having the draft available two weeks in advance does very little good if the WGs don't have agendas posted that tell you what drafts to read in preparation for the meeting. At this point, less than one week before the meeting, only 14 WGs (not counting BOFs) have agendas posted. I'm at a loss for a suitable adjective. You might start by asking the secretariat why all the agendas which have been submitted haven't been posted... I know of two working groups which have sent in their agenda that don't appear on the website, and I suspect they're not the only ones. Colin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet-Draft cutoffs and getting work done
On 20 Oct 2004, at 09:45, Harald Tveit Alvestrand wrote: --On onsdag, oktober 20, 2004 09:31:06 +0100 Colin Perkins <[EMAIL PROTECTED]> wrote: that was what the procedure used to be - and someone had to keep track of the pile of I-D submissions for which there was no response (yet) from the WG chair. That extra load is what the secretariat has been trying to avoid during the rush. Can't we just require the working group chairs to send approvals before the submission deadline? Much of the problem before was that there was no definite cut-off date for approvals. when was "before"? there's been definite cut-off dates for approvals for at least 3 years (see the deadline announcement messages). (I think the secretariat has accepted some late approvals, though...) Checking back, I see you're right about the approval deadlines, although if I remember correctly the deadlines were a lot less firm in the past. The main issue, though, is that having the approval deadline a week before the submission deadline causes problems, as John enumerated in his "rant". In an ideal world, authors would know the drafts they were planning to submit in plenty of time, and they'd tell the working group chairs so approval can be given. In practice, and despite several reminders sent to the working group lists, I've seen several cases where the early approval deadline caused drafts to be rejected. That doesn't help the IETF process. Colin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet-Draft cutoffs and getting work done
On 19 Oct 2004, at 06:13, Harald Tveit Alvestrand wrote: --On 18. oktober 2004 12:43 -0400 Michael Richardson <[EMAIL PROTECTED]> wrote: I wonder if it wouldn't just be simpler to have the WG chair submit the -00 document themselves, I've discussed this option with the secretariat, and they think this (having the WG chair submit or forward the document on behalf of the author was the thing suggested) is a very reasonable thing to do - for the spring IETF meeting. Provided the criteria the secretariat use to check drafts for acceptability are clearly published, so chairs can check that drafts meet those criteria before accepting them for submission (and by this I mean something explicit like "run idnits v1.44 with no nits found and submit by , and we'll guarantee to post the draft"). As a chair, I don't want to be caught in the middle of an argument between an author and the secretariat about what constitutes correct boilerplate. Colin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet-Draft cutoffs and getting work done
On 20 Oct 2004, at 06:13, Harald Tveit Alvestrand wrote: --On tirsdag, oktober 19, 2004 18:39:49 -0700 Vijay Devarapalli <[EMAIL PROTECTED]> wrote: this sometimes doesnt work. for example, I submitted a 00 version working group draft on Oct 18 draft at 2 am (PST). I dont think the WG chair could have stayed up that late to send out the draft for me before the submissin deadline (6 am PST). :) I prefer just cc'ing the WG chairs when I submit the draft, and the WG chairs, as soon as possible, sending a mail confirming that the document should be processed as a working group document. can you ask the secretariat if they are okay with this? :) that was what the procedure used to be - and someone had to keep track of the pile of I-D submissions for which there was no response (yet) from the WG chair. That extra load is what the secretariat has been trying to avoid during the rush. Can't we just require the working group chairs to send approvals before the submission deadline? Much of the problem before was that there was no definite cut-off date for approvals. Colin ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Spammers using IETF meeting attendance lists
On Tuesday, Sep 9, 2003, at 17:48 Europe/London, Doug Royer wrote: It means that at least one person that processed the registrations was using a windows system that is now infected. That stupid blaster virus then sent email with a forged From line as if it was sent from you, then the spammers picked up that never released email address and added it to their spam list. Makes me wonder if the virus was build by someone wanting to find a lot of valid email addresses that were not otherwise available. A simpler explanation is that the proceedings on the IETF website include a list of attendees, with email addresses... Colin
Re: Last Call: SDP attribute for qualifying Media Formats withGeneric Parameters to a Proposed Standard
--> [EMAIL PROTECTED] writes: > > The IESG has received a request from Individual Submissions WG to > > consider the following Internet-Draft(s) as a Proposed Standard. This > > has been reviewed in the IETF but is not the product of an IETF Working > > Group. o Individual Submissions (NONE): SDP attribute for qualifying > > Media > > Formats with Generic Parameters > > > > Proposed Standard > > This looks to me like a substantive duplication of the media features > facility defined in RFC 2533 and elaborated on in RFCs 2506, 2530, 2534, > 2738, 2912, 2913, 2938, and 2987. Not only does this set of documents > provide a full-featured media feature tagging and content negotiation > facility, the relationship to MIME media types and parameters has also > been worked out. This draft adds a new namespace within the existing feature description syntax (RFC 2327) and parameter negotiation (RFC 3264) model of SDP. It is intentionally independent of MIME types, and their parameters, which are mapped onto SDP in other ways (typically through RTP Payload Type registrations). > Although the media features facility defined in these various RFCs is > perhaps too elaborate for SDP's needs, it should at least be possible to > reuse the basic descriptive elements of media features and the > corresponding media features registry. > > At a minimum this draft needs to explain why the existing media features > facility is unsuitable for SDP's use and another, similar facility needs > to be defined. That's an issue for SDP in general, which has a feature description and negotiation mechanism incompatible with - and to large extent predating - the RFCs you mention, but is out of scope of this draft. The SDPng work in MMUSIC references the RFCs you mention, and is looking to reuse as much as possible from them. I think it's too late for SDP to adopt them, because of the need to maintain backwards compatibility with a large installed base. Colin
Re: participation in IETF meetings
--> Aaron Falk writes: >On Tue, Oct 23, 2001 at 11:23:06AM -0700, Paul Hoffman / IMC wrote: >> >> The advantage of multicast vs. tape-and-archive is the real-time >> aspect for the viewer. However, this is rarely, rarely used. If it >> turns out that switching from multicast to tape-and-archive can get >> more camera operators in more rooms, that would be a win for more WGs. > >This is a great idea! I think I've attended about fifteen IETF's now >and at each one I've been to many multicast sessions but I've never, >NEVER heard a live question from a multicast viewer. Now, perhaps >viewers have been posting questions to their repective mail lists >(I've never seen that, either). But, it seems to me that history >indicates the record is much more valuable than the live interaction. It's not common, but I have seen questions passed from remote participants to the meeting floor by the Mbone session operators, and I have had people email me questions to be asked whilst I've been chairing a session (which brings us back to the utility of wireless access in meeting rooms...) But, I agree that having a recording of the session is often more useful than the live multicast. Cheers, Colin
Re: presentation-prep as safety hazard
--> "Marshall T. Rose" writes: >> Let me guess, I have the time to do research for you, that you are >unwilling >> or unable to do. You say >> that something is entirely anecdotal, I say that it isn't. Do the >research. > >you say the studies exist. i say i've never seen them. i'm not asking you to >do any research. i'm asking you to prove what you say: that you've already >seen them. there's quite a difference there. > >or perhaps when you say that the studies exist, you're saying you've heard >the studies exist. i'd call that anecdotal. > >all i'm asking for is a url or a report number or something that can be >researched. if someone can provide one, i'm happy to admit that i'm >mistaken. in the interim, i think it reasonable for me to say that the >"evidence" is all anecdotal... Mobile phones rather than computers, but it's a starting point... http://www.srg.caa.co.uk/news/Gsm_intf.PDF Colin
Re: An alternative to TCP (part 1)
--> stanislav shalunov writes: >Larry Foore <[EMAIL PROTECTED]> writes: > >> How often would a single TCP session have allocated to itself an >> entire gigabit link? > >At SC2000 there was an application (non-interlaced HDTV) using >1.5Gbps. Sure, but it wasn't using TCP... Colin
Lost a secure ID card?
I found one after the CEOT BOF, contact me if you want it back. Colin
Re: pay for using MPEG-4 standard
--> "Goel, Jiten" writes: >Is this royalty applicable only to Audio/Video(multimedia) related >standards or for any other standard under IETF working groups? As I noted previously, there has been no IPR disclosed on the proposed RTP payload formats for MPEG-4. Other parts of the MPEG-4 system are covered by IPR for which you may need a license. I suggest you contact the MPEG committee for details, this has nothing to do with the IETF. Colin
Re: pay for using MPEG-4 standard
--> Jitendra Goel writes: >Hi All, > >I came to know from one of my colleague that if >companies follows MPEG-4 standards during >implementations then they have to pay royalty to >*MPEG-4 Standardizing Committee* just because >they are following the MPEG-4 standards. > >e.g. Supposing a company "A Corp" comes up with >MPEG-4 solutions ( player/authoring tool/server ...) >that are fully compliant with MPEG-4 standards. >Does it mean, it needs to pay anything to MPEG-4 >committee just because its products are MPEG-4 >standard compilant. > >your comments are most welcome. The MPEG-4 standard - like most other audio/video coding standards - includes a number of features which are covered by patents and other IPR. It is likely that you will have to obtain a license to use that IPR before using (certain features of) the standard, and this might involve payment of royalties. You can find more information at: http://www.cselt.it/mpeg/ MPEG home page http://www.m4if.org/MPEG-4 industry forum To make this discussion relevent to the IETF, I note that the audio/video transport working group has not been notified of any IPR on the proposed RTP payload formats for MPEG-4 media. Since this discussion includes the joint MPEG/IETF mailing list developing such formats, I remind people that section 10 of RFC 2026 discusses the requirements for IPR disclosure when working on IETF standards. Colin Perkins IETF AVT co-chair
