Re: Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34
the x00 of that class (e.g. 400 for an unknown 4xx). However, you do not define what a response code of 300 means. How is a client supposed to handle an unknown 3xx response? Sorry, I don't quite get this comment. Section 17.3 says: If a 3rr response is received for a request in relation to an established session, the client SHOULD send a TEARDOWN request for the session, and MAY reestablish the session using the resource indicated by the Location. If the Location header is used in a response it MUST contain an absolute URI pointing out the media resource the client is redirected to, the URI MUST NOT only contain the host name. As explained above unknown 3XX codes will be 3rr codes, as 304 isn't unknown. If you don't believe this is sufficient can you please be more explicit about the issue? As written, a client and server can use HTTP Basic authentication over TCP that is not protected with TLS. Consider restricting it's use to TLS only. Are you sure you don't need to say anything RTSP specific about DIGEST computations (I don't think you need to go as far as SIP did talking about DIGEST, but I'm surprised you haven't run into issues relying only on 2617 literally. Are you referring to Section 19.1 here? Yes, I would not have any issue with requiring Basic to be combined with TLS. I think that is appropriate. When it comes to DIGEST, are you referring to section 22.4 in RFC 3261? That section indicates that some clarifications are likely needed. How does 411 Length Required for this protocol make sense? Given that you've restricted the protocol to TCP and require the Content-Length header to be present if there is a body, in what circumstance would a server need to send a 411? It really should occur for malformed messages, which we could use 400 as response. So yes, 411 could be removed. Section 18.19 requires senders to increment CSeq by 1. We have a reliable transport with no request retransmission, so there should never be gaps at the receiver. Should the receiver check and react some way if there are gaps? I think you should explicitly tell them not to even look. If you agree, why is incrementing by one important as long as you are always strictly increasing? I agree that for TCP or other reliable transports the receiver SHOULD/SHALL ignore gaps. For any future specification of an unreliable transport of RTSP messages this would be needed. As noted in Appendix G, CSeq is retained for future support of unreliable transport. You call out several places where RTCP is essential to allow RTSP using RTP to work correctly, yet section C.1.2 sets up conditions where RTCP MUST NOT be sent. Why are you allowing those instead of treating the conditions you describe as errors? Good question. I think it is a case we must ensure that you can negotiate and configure your desired way, without really considering if it should be allowed at all. I think mandating usage of RTCP with RTP for RTSP 2.0 would be good. But, I think that needs to be verified with the WG. cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
On 2013-06-07 17:40, Elwyn Davies wrote: On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote: Appendix F: I missed that the text/parameter format appeared in the examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the definitions of these methods what encodings are acceptable for the message bodies that may go with these methods and their responses. Exactly, that is intentional. These methods can use anything that has a MIME type. Also it has HTTP's mechanisms for determining what formats one supports. Clearly the new text/parameter MIME format is one. Is it the only one? It is the only one defined by IETF for this purpose. That is why it is in the appendix so that RTSP users shall have something to define the parameters they want in. However, they have to accept the limitations of a basic text format. I guess you could use a application/json or an XML format but I guess these would also either have to be called out explicitly in the method descriptions or put in as feature extensions. This needs to be clarified in the method descriptions (s13). The upshot of all this is that I think Appendix F needs to be pulled back into Section 20 as currently it is the only way to encode the message bodies. I can agree that the format negotiation for the bodies of GET/SET_PARAMETER is not clear. I will look at proposing some improvements of the text related to the handling of method bodies and their format negotiation. Good. I don't see where the server tells what formats it accepts for either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say anything about SET_PARAMETER. AFAICS the client could tell the server what formats it accepts as a side-effect of DESCRIBE but that's a bit arcane - and it is not clear how you would separate the formats for DESCRIBE from those for GET_PARAM and SET_PARAM. Yes, I think this negotiation should happen on per methods basis. However, I am not pulling in Appendix F. It is an optional to use format for parameter value pairs that can be used in these methods, it is not required. Nor, does the specification define any parameters that are transferred using this interface. The things that are in the appendix are not core protocol, they represent either informational things, like the examples and the state machine. The other appendices are normative definitions of particular choices for things that can be combined or used with RTSP, like RTP as media transport. OK, it is possible to use GET_PARAM for basic requirements without using message bodies, so you can get away without defining a lowest common denominator format. However, the use of message bodies for SET_PARAM is RECOMMENDED so it seems a little odd not to ensure that server and client will have at least one format in common. (And its not as if we are dealing with a hugely complicated bit of spec for text/parameters! :-) ). Then, given the example in GET_PARAMETER it seems sensible to advise implementing text/parameters as the default for GET_PARAM also. Sure, I personally don't have any issue with making it at least SHOULD implement text/parameters. But from my horizon a forward pointer with the normative requirements is sufficient to accomplish that. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Re: Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
that all requests were executed as expected. A common example will be two SETUP requests and a PLAY request. In case one of the SETUP fails unexpectedly, the PLAY request can still be successfully executed. However, the resulting presentation will not be as expected by the requesting client, as only a single media instead of two will be played. In this case the client can send a PAUSE request, correct the failing SETUP request and then request it to be played. I think I agree with your assessment, that it would have been nice. However, we should have thought of that when we introduced this type of pipelining 7 years ago. Making any changes to this at this stage is counter productive. The reality is that all the nice features and necessary clarifications has been retrofitted into RTSP 1.0 by the ones that have been using RTSP 1.0. So changing anything will separate the RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't remember any substantial complaints about this issue. I hope this resolves your comments. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
Hi Elwyn, On 2013-06-07 14:26, Elwyn Davies wrote: On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote: Hi Elwyn, Many thanks for the detailed review. We will address the nits you have raised, but I cut them out of this reply to focus on the more substantial issues you have brought up. .. and thanks for the quick response. See inline below. OK. I think the responses clear those issues. I have done a little bit more on the Appendices and liaised a bit with Robert Sparks. 'Highlights': Appendix F: I missed that the text/parameter format appeared in the examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the definitions of these methods what encodings are acceptable for the message bodies that may go with these methods and their responses. Exactly, that is intentional. These methods can use anything that has a MIME type. Also it has HTTP's mechanisms for determining what formats one supports. Clearly the new text/parameter MIME format is one. Is it the only one? It is the only one defined by IETF for this purpose. That is why it is in the appendix so that RTSP users shall have something to define the parameters they want in. However, they have to accept the limitations of a basic text format. I guess you could use a application/json or an XML format but I guess these would also either have to be called out explicitly in the method descriptions or put in as feature extensions. This needs to be clarified in the method descriptions (s13). The upshot of all this is that I think Appendix F needs to be pulled back into Section 20 as currently it is the only way to encode the message bodies. I can agree that the format negotiation for the bodies of GET/SET_PARAMETER is not clear. I will look at proposing some improvements of the text related to the handling of method bodies and their format negotiation. However, I am not pulling in Appendix F. It is an optional to use format for parameter value pairs that can be used in these methods, it is not required. Nor, does the specification define any parameters that are transferred using this interface. The things that are in the appendix are not core protocol, they represent either informational things, like the examples and the state machine. The other appendices are normative definitions of particular choices for things that can be combined or used with RTSP, like RTP as media transport. Appendix B: I appreciate that the state machine is illustrative and to an extent 'abstract'. However, the tables are really written to describe the state machine in the server: the action column mostly describes the events that come into the server (apart from the notify actions) - sending these 'events' are actions in the client. The 'real' state machine in the both the server and the client has a somewhat more complex form: I'd think that there was a STOPPED state in the server when the media has reached an end point and not been explictly paused and STARTING/PAUSING states in the client while the client waits for response to PLAY/PAUSE respectively. I think a little bit more explanation about the dual nature of the columns would solve the problem. There shouldn't be an issue to clarify this nature. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Re: Last Call: draft-ietf-tcpm-initcwnd-06.txt (Increasing TCP's Initial Window) to Experimental RFC
in conjunction with content distributed across multiple domains is explicitly encouraged to perform measurement experiments to detect such problems, and to consider reducing the number of concurrent connections used to retrieve their content. As this was really a guess for the future which was difficult to act on I think the above is as well as I can see you do anything about my issues. From my perspective I think this can be published as an experimental with the proposed updates. Cheers Magnus Other planned change to the draft as requested by IESG feedback: Drop Updates RFC 3390 and 5681 from the metadata. This change answers the DISCUSSes posted by Brian Haberman and Ralph Droms. I believe that together these chanes should address all of the IESG DISCUSS items. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Thu, Dec 6, 2012 at 2:01 AM, Magnus Westerlund magnus.westerl...@ericsson.com wrote: Hi, I have reviewed draft-ietf-tcpm-initcwnd-06 and have some questions and comments. 1) First of all the experiments done appear to cover the impact on other applications, like measuring the RTT variations when using IW10 compared to IW3. If one is interested in the impact this proposal have on real-time traffic flows over a shared bottle-neck the variations in queue time at the bottleneck combined with that flows seen loss rates are the most important factors. As a sudden delay spike of sufficient magnitude will most likely result in a real-time media packet being late, i.e. late loss rather than being lost in the network there might be significant impact on such traffic from these IW10 packet bursts. Have I missed any material discussing this aspect? All the latency figures in the parts I was looking at was discussing cases when the object transfer takes longer time. But it appear obvious that even with a 100 ms increased one-way transfer time for a packet is the end of the initial window the total transfer goes faster compared to the delay caused by growing the window. 2) If I assume that most users are behind buffer-bloated links the introduction of IW10 on wide scale will additionally disrupt interactive applications and cause increased delay and possible late loss depending on application. Especially in combination with domain sharding. For example a Swedish newspaper's website front page results in that more than 40 TCP connections are opened in a current browser. If these all was using IW10, the amount of packets being sent initially will grow roughly from 40*3 = 120 to 40*10 = 400. There are some distribution over time but still this likely results in a larger delay spike. I don't quite know how I should consider this case. One stand point is that the interactive application is anyway buggered and IW10 effects are not making it significantly worse. The only remedy is queue separation so that what ever happens with the web-downloads doesn't affect the interactive traffic. Another is that it will make the existing situation worse and we should try to avoid making it worse. I think I am more in the first camp, but still the second one is worrying to me. But I dare to guess that the performance gains might be worth the issues, but without real progress on mitigation of the buffer bloat issues for interactive real-time traffic this will add significantly to the issues real-time has to face. 3) The documents talks in quite loose terms about what can be done to avoid to continue cause issues for destinations which has issues with IW10. However I think it is a bit unspecific here. I can see that a content deliverer can have lists for destination address blocks that they see issues with which configures the sending server side with a lower IW value. It also talks about the clients can configure to keep the window low initially to prevent an IW10 sender to clobber ones link if that is known. My question here is if the recommendation for auto detection and configuration can be made more explicit. Fortunately the issues with misconfiguration in this cases is not that serious. But otherwise there is commonly need to be quite careful with such auto configs that affects the behavior. 4) I am also worried that the document is a bit to positive in regards to that IW10 will reduce the domain sharding practice. I think the only thing that can do is likely a new HTTP transport strata that shows that significantly improved performance for multiple objects from the same domain over fewer transport flows. Maybe SPDY + IW10 can provide such incentive, but I don't think IW10 alone will do much. Cheers Magnus On 2012-11-26 22:29, The IESG wrote: The IESG has received a request from
Re: Gen-ART review of draft-ietf-6man-udpchecksums-06
Hi Peter, Thanks for your detailed review. An updated version has just been submitted the includes fixes to your comments. Thanks Magnus On 2012-12-26 12:05, Peter Yee wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-6man-udpchecksums-06 Reviewer: Peter Yee Review Date: Dec-25-2012 IETF LC End Date: Dec-25-2012 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. [Ready with nits.] This document provides an update to 2460 to allow the use of zero checksum UDP packets over IPv6 in certain cases involving protocols tunneled inside of UDP packets. Nits: General: a comma after i.e. is preferred in American English. General: it is not necessary to hyphenate misdelivered or misdelivery. General: put quotes around Applicability Statement for the use of IPv6 UDP Datagrams with Zero Checksums Abstract, first sentence: when - where Abstract, second sentence: protocol - protocols Section 1, second paragraph, first sentence: delete the comma after packet. Section 1, fourth paragraph, first sentence: move the comma in AMT, to after the reference. Section 1, fourth paragraph, last sentence: insert the after applicable in. Section 3, second sentence: delete the first occurrence of where. Consider revising the sentence for clarity. Section 4, second sentence: Section - Sections Section 4.1, it would be nice, but not necessary to have an enumeration of the corruption modes. Section 4.1, third bullet item, first sentence: a verb is missing here making the sentence difficult to parse. Section 4.1, third bullet item, first sentence: packets - packet Section 4.1, third bullet item, third sub-bullet: put commas around for example. Section 4.2, first bullet item, last sentence: this sentence is hard to understand; consider revising. (See next comment) Section 4.2, first bullet item, last sentence: an - a and are - is; also not general comment about misdelivered. Section 4.2, third bullet item, third sentence: effect - affect Section 4.2, first paragraph after bullet items, first sentence: delete this. Section 4.2, first paragraph after bullet items, third sentence: mis-delievery - misdelivery. Section 4.2, first paragraph after bullet items, third sentence: delete that. Section 4.3, first sentence: middlebox devices - middleboxes unless this a specific usage from I-D.ietf-6man-udpzero. Section 4.3, second sentence: needs - need Section 5, first paragraph, second sentence: insert in after node requirements. Section 5, first paragraph of replacement text, second sentence: delete usage for, replace some with certain, and replace second protocols with those. Section 5, last paragraph: delete first instance of the. Section 6, first bullet item, first sentence: corruptions - corruption Section 6, second bullet item, last sentence: change This to UDP-Lite. Section 8, first sentence: delete redundant required. -- Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Last Call: draft-ietf-mboned-auto-multicast-14.txt (Automatic Multicast Tunneling) to Proposed Standard
Hi, Sorry for being late with this IETF last call comments. I will partly blame the ADs requesting this Transport Directorate review a bit late, the other part is all mine and the holidays. Anyway, I do hope you will consider these issues and comments as I believe I found some serious ones in addition to a number of clarifications that should be made. Significant Issues: 1. Congestion Control This is clearly a tunnel establishment protocol of something that is IP traffic. Thus normally the responsibility for congestion control is with the tunnelled traffic. However, I would like argue that this does not apply in this case due to the nature of the tunnelled traffic, i.e. multicast traffic and secondary due to limitations in the tunnel protocol. Lets start with the second part. This protocol claims to support ASM still don't provide a upstream delivery mechanism, i.e. an ASM receiver is not capable of sending as it should. This prevents several existing mechanism for congestion control that exist in protocols supporting multicast. The first is using RTCP for congestion control in ASM [RFC3550], the second is TCP-Friendly Multicast Congestion Control [RFC4654] that can be used in the RMT suite of protocols, and I know has been implemented in some NORM implementation. Thus only strictly receiver based mechanisms, such as Wave and Equation Based Rate Control [RFC3738] are available in this context. Secondly, many multicast usages are in fact deployed without any congestion control. This based on that the deploying entity controls the scope and authorization for requesting multicast delivery. However, does restrictions does not apply to AMT delivery of multicast. If the gateway can reach using unicast the relay it can be delivered the multicast group from the domain the relay is attached to. Thus, this protocol changes the deployment restrictions of multicast which many non-congestion controlled delivery is based on. Instead the non-congestion controlled traffic can now sent over an IP/UDP tunnel over Internet where neither relay nor gateway may have any knowledge about the path the traffic may take. Based on this I would like to see two changes to this protocol specification. First a section discussing the issue of congestion control. Secondly, I think this protocol should have an applicability statement limiting its deployment to restricted environments where the relay and gateway deployers can provide certain resource provisions between the entities to avoid the multicast traffic affecting other traffic sharing the same bottlenecks in ways not allowed by the network provider. 2. Security This protocols is frank with it having limited security features and says this is similar to the IGMP and MLD protocols being used. However, I think this is a failure to propoerly consider the threat model. If one uses AMT over general Internet it will run in a network where the one deploying the multicast and the relays no longer control requirements on source address verification or possibilities for traffic separation as they can do within the domains where multicast currently are deployed. The security vulnerabilities in IGMP and MLD are much more contained and controllable in a LAN environment where one has chosen to deploy multicast compared to an Relay exposing this to the whole Internet. Once more I think there is only two choices here. A) Beef up the security to general Internet threat model, i.e. at a minimal provide a real model for gateway authentication using identities, not only return routability based verifications. B) Limit the applicability of AMT to managed environments and make it clear that the relay will need to limit which gateways are allowed to access the relay based on addressing. Based on the first significant issue with congestion control I expect that there is little meaning to do A) unless also one is willing to beef up AMT to provide congestion control. Which I think is not according to the design wishes for the protocol designers. 3. Use of Zero Checksum The AMT specification enables the use of Zero UDP checksum with IPv6, i.e. draft-ietf-6man-udpchecksums-06http://datatracker.ietf.org/doc/draft-ietf-6man-udpchecksums/ and draft-ietf-6man-udpzero-08http://datatracker.ietf.org/doc/draft-ietf-6man-udpzero/. Nothing against this in principal. However, I have noticed that AMT fails to properly address the failure modes of using a zero-checksum. AMT is a typical example of a protocol that actually need active verification of each tunnel that zero-checksum functions. This as AMT is clearly intended to be deployed with its Gateway part in end-hosts and residential network devices or routers. This means the tunnel will pass through both firewalls and NATs on its path between the relay and the gateway. Unless these devices are not upgraded to support zero-checksum in UDP for IPv6 the traffic may actually become black holed. The
Re: Last Call: draft-ietf-6man-udpchecksums-06.txt (IPv6 and UDP Checksums for Tunneled Packets) to Proposed Standard
Thanks John The editorial nits we will take care of in an update. Many of these are new due to the significant changes, and this is in fact the first chance to comment on them. Thus, do not feel bad for it being IETF last call. On 2012-12-18 00:56, John William Atwood wrote: Comments on draft-ietf-6man-udpchecksums-06 Bullet 3, sub-bullet 1. What does it mean, the 5-tuple with a zero checksum enabled? I _believe_ that you are trying to indicate that the delivery mechanism has a data structure with the 5-tuple and an indication that this context has enabled zero checksums and that the incoming packet has a zero checksum and that the 5-tuple matches the one in the data structure. I am not sure what to suggest, but the potential for erroneous coding seems high to me. A packet matching an existing context which has zero checksum enables receives a packet not intended for this context, but due to some corruption event of the address information it arrives in this context. You are correct that there is basically nothing you can do against this unless you actually have a checksum to detect the corruption. In the case of a tunneling protocol is is also likely that the tunneling protocol is so thin, i.e. no or few headers that using them to detect that this packet is not intended for this context is difficult. Correctly I think this is something you have to accept when using non-checksum protected receivers. It can occur but more than 1 times as common when using Internet checksums. Bullet 3, sub-bullet 1. If a payload is matched to the wrong context, why is it delivered as if it were correct? Is there something that I am missing here? The receiving context interprets the packet according to the rules of the existing context. If nothing in this processing is tripped then what was in that packet will be used as a valid packet in that context. To be clear here, we are describing the cases using full knowledge of what occurs, but the receiving node can't see the difference between a corrupted zero-checksummed packet and a correct one. That is what it requires the checksum to do. Page 9, replacement text, para 1, lines 6-9. This sentence has no subject. I suggest the following text: As an alternative usage for some protocols, such as protocols that use UDP as a tunnel encapsulation, the zero-checksum mode MAY be enabled for specific sets of ports. I note, however, that the phrase zero-checksum mode is probably not defined anywhere in RFC2460, so it may be necessary to be more specific here: a packet with a zero checksum MAY be allowed for specific sets of ports. The zero-checksum mode is intended to be defined by this text, where the zero-checksum mode is defined by the rules in draft-ietf-6man-udpzero. I have some difficulties determining what changes would improve this. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Re: Last Call: draft-ietf-tcpm-initcwnd-06.txt (Increasing TCP's Initial Window) to Experimental RFC
by the IETF TCP Maintenance and Minor Extensions (TCPM) working group. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tcpm-initcwnd/ballot/ No IPR declarations have been submitted directly on this I-D. -- Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com --
Re: Last Call: draft-ietf-mmusic-ice-options-registry-01.txt (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard
Hi, When the last call has ended I will update the draft with the changes identified. Mykyta Yevstifeyev skrev 2011-04-29 18:04: Magnus, 29.04.2011 11:47, Magnus Westerlund wrote: Hi Mykyta, Thanks for the review. See inline for response. Mykyta Yevstifeyev skrev 2011-04-28 19:22: Hello, Some comments on this document, currently in Last Call. Network Working Group M. Westerlund Internet-Draft Ericsson Updates: 5245 (if approved) C. Perkins Intended status: Standards Track University of Glasgow Expires: September 29, 2011 March 28, 2011 I don't see why the intended status for this document is Standards Track. Wouldn't Informational be enough? Could you please justify why have you chosen it? I don't think we have put much thought into it. But one reason I can think of is to have it on the same maturity level as the ICE specification itself. Thus enabling a merge of this registry into an update of RFC 5245 without forcing it to be recycled as proposed. This is a good reason, so I'll agree with it. Ok Your registry description does not mention what is the precise name of the registry. While everybody understands that is sands for ICE options, it would be useful to give IANA distinctive guidelines on its name (this is also required in RFC5226, Section 4.2, 1) in the list; http://tools.ietf.org/html/rfc5226#section-4.2). Yes, I agree that it should be included in Section 3.1 of our document rather than only in the title which says Interactive Connectivity Establishment (ICE) Options Agreed on this. Such name is fine, IMO. Ok From RFC 5226, also Section 4.2: 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for Private Use, Reserved, Unassigned, etc. should be clearly indicated. Are there any initial assignments? Your document mentions one option; shouldn't it be registered? No, because when draft-ietf-avtcore-rtp-ecn gets published that will actually do the registration. As that document isn't approved yet and in fact still not WG last called this registry will first be created empty and then populated. So you should have mentioned this in the draft as well. Ok, will clarify. A registration request MUST include the following information: [ . . . ] Shall this be mentioned as a registration template? It isn't written as one. It is a list of what needs to be present in the registration. And I think a template would be more focused on what needs to the general categories rather than the information. Thus I don't want this as registration template. OK, this matter is not very important. o Email and Address of the Contact person I think you should add the name of the contact person to the name of this field as well. As the two first bullets are: o Name of contact person for the registration o Email and Address of the Contact person I don't quite understand your comment. Do you want us to merge the two entries? This as the contact persons will need to provide name, email and address. I am fine with merging them and this is likely a slight improvement. No, I didn't propose to merge it. I just proposed to rename this field as Name, Email and Addresses of the Contact Person. I think it is logical to have only one entry saying: Name, Email and Addresses of the Contact Person for the registration Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mmusic-ice-options-registry-01.txt (IANA Registry for Interactive Connectivity Establishment (ICE) Options) to Proposed Standard
Hi Mykyta, Thanks for the review. See inline for response. Mykyta Yevstifeyev skrev 2011-04-28 19:22: Hello, Some comments on this document, currently in Last Call. Network Working Group M. Westerlund Internet-Draft Ericsson Updates: 5245 http://tools.ietf.org/html/rfc5245 (if approved) C. Perkins Intended status: Standards Track University of Glasgow Expires: September 29, 2011 March 28, 2011 I don't see why the intended status for this document is Standards Track. Wouldn't Informational be enough? Could you please justify why have you chosen it? I don't think we have put much thought into it. But one reason I can think of is to have it on the same maturity level as the ICE specification itself. Thus enabling a merge of this registry into an update of RFC 5245 without forcing it to be recycled as proposed. Your registry description does not mention what is the precise name of the registry. While everybody understands that is sands for ICE options, it would be useful to give IANA distinctive guidelines on its name (this is also required in RFC5226, Section 4.2, 1) in the list; http://tools.ietf.org/html/rfc5226#section-4.2). Yes, I agree that it should be included in Section 3.1 of our document rather than only in the title which says Interactive Connectivity Establishment (ICE) Options From RFC 5226, also Section 4.2: 5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for Private Use, Reserved, Unassigned, etc. should be clearly indicated. Are there any initial assignments? Your document mentions one option; shouldn't it be registered? No, because when draft-ietf-avtcore-rtp-ecn gets published that will actually do the registration. As that document isn't approved yet and in fact still not WG last called this registry will first be created empty and then populated. A registration request MUST include the following information: [ . . . ] Shall this be mentioned as a registration template? It isn't written as one. It is a list of what needs to be present in the registration. And I think a template would be more focused on what needs to the general categories rather than the information. Thus I don't want this as registration template. o Email and Address of the Contact person I think you should add the name of the contact person to the name of this field as well. As the two first bullets are: o Name of contact person for the registration o Email and Address of the Contact person I don't quite understand your comment. Do you want us to merge the two entries? This as the contact persons will need to provide name, email and address. I am fine with merging them and this is likely a slight improvement. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Joe Touch skrev 2011-03-28 15:33: As one of the authors, I'm fine with this change too. Me too, Magnus Westerlund ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen Jennings skrev 2011-02-01 18:19: So to summarize what you are saying, ports are allocated based on an arbitrary view of the expert review. When this person will say yes or no too can't be described and will change over time. If that's how it works, there is not even any grounds for appeal of any given decision. You can't even use precedence as an argument. My view was the IESG has been trying to move to having much more concrete advice for registries that required expert review. If you agree that is about the right summary, then I'm pretty sure I can find plenty of other people that would agree with me that this is not OK. I'm not a fan of the WG could not get consensus on if we should allow A or not so we are just going to let the expert review do whatever they want. If the IETF could not come to consensus on if X or Y were reasons to deny a registration, then I don't think the expert review should be able to deny a registration due to X or Y. Cullen, Apparently you like to twist what I am saying in most negative way and without considering the checks that are in place. - I think general guidelines can and should be developed. But other than high level goals this isn't the document. Here Joe has the start of a document. But I do think that in long term this guidance may change. - There is an appeal process where the IESG and then IAB gets to sanity check the arguments that the reviewer + IANA has given towards the appealing requestor. - One can take a assignment request through the IETF process I hope that we can get consensus on the guidelines, because I think that would give the reviewers a lot of comfort being able to rely on that consensus. Cullen, what are your suggestion for how to improve the document? Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen Jennings skrev 2011-01-31 18:44: Magnus, I agree with what you are saying here but you are avoiding the issue I am concerned with. Is allocating a second port for the secure version of a document a frivolous use case or not? I read this draft as saying it is. Others read the draft as saying it is not and that type of allocation is fine. This seems fairly easy to deal with - first lets agree if particular 2nd port for secure version is a reason to reject requests or not then see if any text needs to be adjusted in the draft to reflect that. Well, frankly I don't know. I think it is something that can be avoided going forward in many use cases, but not all. Simply by thinking of this issue in the design phase. In addition there is clearly other solutions there other considerations, like NAT traversal has said, yes multiplexing is a must, thus live with even higher complexity costs. The issue I have a problem with is that is we say on general basis that due to negotiation of security protocols we are allowed to use different ports for negotiation or simply usage of it. Then why is that different from different versions of the protocol, or feature support. What is the difference for a security protocol compared to these other issues? What I am worried here is that we will see an increased port consumption rather than a decreased one. At the current run rate I think the estimate is 50 years+ before run out. That is something that I am reasonably comfortable, but if the consumption rate increases four times, then I am suddenly not comfortable. So I am pretty certain that we need to aim at lowering the consumption rather than raising it. As I see it there are only one way of doing it. - State clearly that you really need to do everything reasonable so that your application is only for one port. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. And from that perspective I don't think security is special in anyway. It is only one of several things that could potentially require additional registered ports. Yes security is important, but as previously discussed it doesn't appear that the actual level of security provided is different if you are forced to use one port or two. It might affect the ease of implementation and deployment of security, which is another aspect of impact. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen Jennings skrev 2011-01-30 05:56: I read the draft to say that there would only be one port allocated - I took strive to mean that Joe would deny my port requests for two ports. If the intention is actually for the draft to say that it strives for one port but allows assignment of two where the that is what the protocol design desire, then I have no problem. Perhaps we just need to clarify what strive means. This definition of strive leads into exactly my other complain that this draft provides no guidance on what the expert will or will not approve. We probably need to adjust text like o IANA strives to encourage the deployment of secure protocols, and so strives to avoid separate assignments for non-secure variants and The use of separate service name or port number assignments for secure and insecure variants of the same service is to be avoided in order to discourage the deployment of insecure services. and Services are expected to include support for security, either as default or dynamically negotiated in-band. In band negotiation of security is applicable for some cases, but it adds latency, bandwidth, and complicated multiplexing in non session based transports. I think this is a bad idea in many cases. I also view separation even for stream based protocols as something that helps management and debugging as well as policy. Well, the high level goal is to preserve a limited resource. We can't do that without making the preference clear. But I think you have forgotten to consider those statements trying to make clear that this is up to review. The review criterias can be expected to change overtime. They are also hard to codify. Especially for this case, how do we measure architectural uncleanness, implementation issues, and performance impact to make a rule that judges if one or more port is allowed? We clearly can't, this will be up to human judgment. I also think it is important that we separate the basic registry rules from the review guidelines, as they will change. Thus this is a separate document. One that we should make clear is going to exist. And as pointed out in other parts of this discussion there are several ways of challenging the reviewers recommendation resulting in an IANA decision. First of all is the appeal process. Secondly, is to take it through the IETF approval process where IETF makes the decision, not IANA. As I see it, we either leave these high level goals in this document, or we remove the completely and put everything in a separate document. I rather leave them in, because I don't seem them changing. Only be acted up in varying ways over the coming years. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen Jennings skrev 2011-01-31 17:13: Well lets say the request was coming from 3GPP for a protocol they designed - why should IANA be able to tell them no but IETF yes. I am not certain I understand what your issue is here. Is it that they can come to different conclusions, and that IETF can decided to override the expert review team? I think that is the logical conclusion, as the IETF's decision will have gone through a consensus process. One which the expert can provide their view into this. I think the policy issue here is fairly clear. We do not have consensus that in all cases that one should not have a second port for security (I'm basing this assertion on Magnus read of WG consensus and my read of IETF LC consensus). Therefore that should not be a ground for the expert reviewer (or IANA) to reject the registration. The document needs to be updated to make that clear or it does not reflect consensus. If the authors of the draft want to propose text for conditions when it would be ok to reject a second port for security purposes and see if they can get consensus for that text, that seems perfectly reasonable. My reading of the WG last call consensus is that nobody is disagreeing with the goal of trying minimize the port consumption. My interpretation is that we do need to state that goal in the document. And the only way of achieving this is to try to minimize the consumption by each protocol that requires a registration. That includes trying to get all multiplexing into that single socket, or at least use it for agreeing on dynamic range port for this protocol. I'm sure that some people believe the draft, by using the word strives, actually means that this is not a grounds for rejection but given the push back from Lars and Joe, I believe that strives means that the decision is up to Joe. Given things could be read either ways, I think it's fair to ask for the draft to clarify this. It is a high level goal to minimize the port space consumption. I do believe there is strong consensus for this. And I believe that the only way of ensuring that this goal is meet is to take a pretty hard stance against frivolous use of ports. Thus, I still think there is clear grounds for rejecting requests for multiple ports based on not sufficiently motivating why it is impossible to not use one port. I do agree that these guidelines should be documented, and that is the plans as far as I know. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-cheshire-dnsext-special-names-01.txt (Special-Use Domain Names) to Proposed Standard
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. My comments on the document are: 1. Section 3. I wonder if Standards Action is the most appropriate rule here. My concern with this is that any other body must perform the work in the IETF and give IETF full change control over this proposal. This might intended, but I wonder if it is the most appropriate policy. My suggestion would be to allow IESG approval as a policy also to give some freedom in the strange cases. I do think an IETF standards RFC is the preferred way for doing this, but it might be overly restrictive. 2. Section 6. Why doesn't this document populate this registry with some initial values. The document it self already lists some of these. So why not include the ones and a note that they are legacy and does not come with the new required consideration section? Best Regards Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
Cullen Jennings skrev 2011-01-27 01:12: I'm really glad to see this draft in LC at long last and it is a great improvement to the current situation - thank you to all the people that put work into this. I have two significant problems with it that I think should be resolved before being published Big Issues 1: I don't like mandating one port for secure and not secure versions of a protocol I don't think this reflects IETF consensus given the number of protocols that deliberately choses to use two ports. I also don't think that it is a good idea in all cases. I believe the decision should be left to the people designing the protocol if they want one port or two. Let me give some examples We have extensive discussion on this in the WG last call. There was no consensus for having two ports. At the same time we did also have no consensus on mandating one port for any future protocol. Thus we adjusted the text to say in Section 7.2: IANA strives to assign only one assigned port number per service or application To my knowledge strive is not a binding RFC2119 term. I also think it is a good trade-off with the intention of preserving the space as well as possible with only assigning one port, and still allow for more than one if it really is needed. Is it the above text that triggered your comment or some other text? Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP
t.petch skrev 2011-01-21 12:43: I would like to see more clarity in 8.1 For assignments done through IETF-published RFCs, the Contact will be the IESG. in that I am unclear what IETF-published RFCs are; presumably that is Standards Track, BCP and Individual Submissions, but not Independent Submissions or IRTF RFC. I think that the terminology here should follow that of RFC4844 with a reference thereto. I guess we should use the IETF Stream, and I do agree that a reference for the definition of that should be included. Cheers Magnus Tom Petch - Original Message - From: Magnus Westerlund magnus.westerl...@ericsson.com To: apps-disc...@ietf.org; Internet Area int-a...@ietf.org; rai-disc...@ietf.org; ops-a...@ietf.org; SAAG s...@ieft.org Sent: Wednesday, January 19, 2011 9:30 AM Subject: [apps-discuss] Fwd: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Hi, I just want to make people aware of this IETF last call for an update of the IANA procedures for registration of Service Name and Transport protocol port numbers. Best Regards Magnus Westerlund Ursprungligt meddelande Ämne: Last Call: draft-ietf-tsvwg-iana-ports-09.txt (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP Datum: Tue, 18 Jan 2011 22:26:03 +0100 Från: The IESG iesg-secret...@ietf.org Till: IETF-Announce ietf-annou...@ietf.org Kopia: ts...@ietf.org ts...@ietf.org The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry' draft-ietf-tsvwg-iana-ports-09.txt as a BCP 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 2011-02-01. 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://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-ports/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ apps-discuss mailing list apps-disc...@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss -- Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-avt-rapid-acquisition-for-rtp-15.txt (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard
stuff (or the cookie stuff) will avoid request messages from being sent by others (it will do at least a reverse path check). Beyond that is not SRTCP a good solution to avoid this? SRTCP is if keyed correctly a good solution yes. My point is that one normally document the vulnerability and then ensure that one has a remedy for it. When it comes to the token stuff I am not certain that it helps against a replay attack. Unless the token has expired on the server you still will get traffic to the target. That is why I think a reverse path check when you start delivering should happen. Because first in that case if there is no listener at the indicated address and port will you find out that you are attempting a delivery not intended. Token provides RPF check. But, let's work on this Sec. section together. I could use some help. Ok -- Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-avt-rapid-acquisition-for-rtp-15.txt (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard
. Otherwise, congestion and packet loss may occur. The last sentence I would formulate as: Otherwise, congestion and packet loss are much likelier to occur How about more likely to occur? Sure. Even if one stays within this value congestion and packet loss may occur. This is not the only case, but when I actually decided this seems to be an issue, I hadn't taken note of all examples I seen. 6. Section 7: Each feedback message has a fixed-length field for version, padding, feedback message type (FMT), payload type (PT), length, SSRC of packet sender, SSRC of media sender as well as a variable-length field for feedback control information (FCI). What is called Payload type is actually Packet Type in RTCP packet headers. We followed the definition from 4585 but packet type makes more sense to me as well. Well, section 6.1 of RFC 4585 is wrong. 7. Section 7.3: The MSN value SHALL be set to zero only when a new RAMS request is received. How is that actually known? And why reset it at all? Why not increase if for each new RAMS-I message with new content, independently if it is an update or a new request. If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same. I fully agree with the need for separating retransmissions from updates. However, I wonder over the reset of the field for each new RAMS-R. It appears to me to be more robust to simply increment it rather than reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = 0. Then a RAMS-R(2) that is intended to be an update but becomes an new request results in an RAMS-I with MSN = 0. The client will not know if this is an retransmission of RAMS-R(1) info. The updated should result in MSN=1. So without comparing the RAMS-I you can't determine if there is new information. Going my way (no reset) does not allow a client to determine if an RAMS-R was treated as update or new request, but it will correctly know that it is new RAMS-I information. 8. Section 7.3: When the RTP_Rx receives a RAMS-I message with a response code that it does not understand, the RTP_Rx MUST send a RAMS-T message immediately to the BRS. Which media sender SSRC should the client direct this request to if it hasn't been signalled in SDP nor any RTP/RTCP packets received? The rules in the RAMS-T section applies. You received a RAMS-I so you know the SSRC. Yes, you are correct. My mistake. 9. Section 7.3, Media Sender SSRC TLV: While this information is already available in the message header, it can be useful to repeat it in an explicit field. This sentence seems out of place compared to the rest of the text. If I recall correctly, this was something you asked for. I am not sure whether there is a better place to put it. Maybe in parentheses? I think we can remove that sentence. I think you now have text making clear when it needs to be included and when it shouldn't. 10. Section 7.3, RTP Seqnum of the First Packet TLV: How is this TLV bound to the SSRC number if is for? This is not explicitly explained. What do you mean? The SSRC comes from the RAMS-I's SSRC. There is one (not multiple) stream per RAMS-I. Yes, something that I apparently have forgotten. 11. Section 7.4: Each of these RAMS-T messages has the appropriate media sender SSRC populated in its message header. Instead of writing appropriate cant you simply write Each of these RAMS-T message's media sender SSRC SHALL BE populated with the SSRC of the Media Stream to be terminated. Good suggestion. 12. Section 8.3: This section provides a declarative SDP [RFC4566] example for enabling rapid acquisition of multicast RTP sessions. Can you make clear that this an example of an SDP to be provided to a client? OK. 13. Section 9, bullet b: Be configured to forward certain ports (e.g., using HTML configuration and UPnP IGD [UPnP-IGD]). Shouldn't the and be an or? Yes, good catch. 14. Section 10: Shouldn't the security consideration make it clear that RAMS-R are especially suspectible to Replay attacks as there is no information in the packet that one can use to detect that it is out of sequence. There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS-specific replay attack here? Yes, I am considering that it is easy to target RAMS-R specifically for an replay attack. Especially when sent in a reduced size RTCP packet only containing RAMS-R and SDES CNAME. That has no time specific information and all replay detection must happen in the security protocol. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM
Re: Last Call: draft-ietf-avt-rapid-acquisition-for-rtp-15.txt (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard
request results in an RAMS-I with MSN = 0. The client will not know if this is an retransmission of RAMS-R(1) info. The updated should result in MSN=1. So without comparing the RAMS-I you can't determine if there The client checks the RAMS-I seqnum to see whether it is a repeat or new info. If RAMS-I MSN is zero, that is the first RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R actually generated it since that is the info from the server until an updated RAMS-I is received. This is how the protocol works. As I try to explain there is a case where you can get two RAMS-I with MSN=0 in a row with different information. Thus not providing any relieve for the client in the need to compare the whole request with the previous one. is new information. Going my way (no reset) does not allow a client to determine if an RAMS-R was treated as update or new request, but it will correctly know that it is new RAMS-I information. The server cannot keep state information (i.e. tracking RAMS-R numbers) across different sessions. Furthermore, requests for different streams can go to different servers. No, I am not talking about RAMS-R number here. I am talking about RAMS-I MSN numbers, that they shouldn't be kept. But I see your point in that you don't want to keep CNAME,SSRC = MSN counter mappings. But in that case, I think we should make it clear that a client that has sent a RAMS-R (update) must check if the RAMS-I information is same or different to determine if the server interpreted the update as a new request. 14. Section 10: Shouldn't the security consideration make it clear that RAMS-R are especially suspectible to Replay attacks as there is no information in the packet that one can use to detect that it is out of sequence. There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS-specific replay attack here? Yes, I am considering that it is easy to target RAMS-R specifically for an replay attack. Especially when sent in a reduced size RTCP packet only containing RAMS-R and SDES CNAME. That has no time specific information and all replay detection must happen in the security protocol. The Token stuff (or the cookie stuff) will avoid request messages from being sent by others (it will do at least a reverse path check). Beyond that is not SRTCP a good solution to avoid this? SRTCP is if keyed correctly a good solution yes. My point is that one normally document the vulnerability and then ensure that one has a remedy for it. When it comes to the token stuff I am not certain that it helps against a replay attack. Unless the token has expired on the server you still will get traffic to the target. That is why I think a reverse path check when you start delivering should happen. Because first in that case if there is no listener at the indicated address and port will you find out that you are attempting a delivery not intended. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-avt-rapid-acquisition-for-rtp-15.txt (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard
Hi, I have the following comments on this document, I think version 7 or 8 was the last version I read before my parental leave. 1. Applicability statement: I think this document should have an applicability statement making clear that this is only for engineered environments due to the traffic bursts. 2. Section 6.2, bullet 5: I don't think the document is clear on that the BRS is expected to determine if a RAMS-R is a retransmission or an update based on if any content of the message has been changed. 3. I worried that what is intended to be an RAMS-R update from the client will be interpreted as new RAMS-R request. The reason is the only that separates these two cases are timing, does it arrive before the burst ends or not. Relying on this heuristics is quite weak and error prone. I still wished that an sequence number had been added to RAMS-R. 4. Section 6.2, bullet 5: Thus, the RTP_Rx MUST choose a globally unique CNAME identifier. I don't think this is a statement that can either be fulfilled nor tested. You can mandate a method for selecting CNAMEs that has low risk of producing CNAME collisions, but nothing can guarantee it unless a entity is coordinating the CNAME space for all clients. Can you mandate the method instead? If I understand the impact of a CNAME collision is that the collision clients request will be mixed up, for example terminating each others request, or update the values in the RAMS-R. 5. Section 6.4 and others: The draft has a tendency of formulating itself as everything is guaranteed to work as long as one keep within given limits for bandwidth etc. An example from Section 7.2 Max Receive Bitrate TLV: If specified, the total bitrate of the unicast burst(s) plus any payload-specific information MUST NOT be larger than this value. Otherwise, congestion and packet loss may occur. The last sentence I would formulate as: Otherwise, congestion and packet loss are much likelier to occur Even if one stays within this value congestion and packet loss may occur. This is not the only case, but when I actually decided this seems to be an issue, I hadn't taken note of all examples I seen. 6. Section 7: Each feedback message has a fixed-length field for version, padding, feedback message type (FMT), payload type (PT), length, SSRC of packet sender, SSRC of media sender as well as a variable-length field for feedback control information (FCI). What is called Payload type is actually Packet Type in RTCP packet headers. 7. Section 7.3: The MSN value SHALL be set to zero only when a new RAMS request is received. How is that actually known? And why reset it at all? Why not increase if for each new RAMS-I message with new content, independently if it is an update or a new request. 8. Section 7.3: When the RTP_Rx receives a RAMS-I message with a response code that it does not understand, the RTP_Rx MUST send a RAMS-T message immediately to the BRS. Which media sender SSRC should the client direct this request to if it hasn't been signalled in SDP nor any RTP/RTCP packets received? 9. Section 7.3, Media Sender SSRC TLV: While this information is already available in the message header, it can be useful to repeat it in an explicit field. This sentence seems out of place compared to the rest of the text. 10. Section 7.3, RTP Seqnum of the First Packet TLV: How is this TLV bound to the SSRC number if is for? This is not explicitly explained. 11. Section 7.4: Each of these RAMS-T messages has the appropriate media sender SSRC populated in its message header. Instead of writing appropriate cant you simply write Each of these RAMS-T message's media sender SSRC SHALL BE populated with the SSRC of the Media Stream to be terminated. 12. Section 8.3: This section provides a declarative SDP [RFC4566] example for enabling rapid acquisition of multicast RTP sessions. Can you make clear that this an example of an SDP to be provided to a client? 13. Section 9, bullet b: Be configured to forward certain ports (e.g., using HTML configuration and UPnP IGD [UPnP-IGD]). Shouldn't the and be an or? 14. Section 10: Shouldn't the security consideration make it clear that RAMS-R are especially suspectible to Replay attacks as there is no information in the packet that one can use to detect that it is out of sequence. Cheers Magnus Westerlund -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Draft-ietf-nsis-ntlp: Late change of IANA consideration section
I like to inform everyone that we intended to make a post approval change to the IANA rules for GIST: General Internet Signalling Transport (draft-ietf-nsis-ntlp-20). This document is approved for publication as experimental. In the change of intended status during IESG processing, we failed to adjust the policies on the IANA registries this document creates. Thus there are registries that has the policy of Specification Required, which are almost impossible to fulfill when the normative reference is going to be experimental. Thus we intend to address this by changing all Standards Action policies to IETF Review as specified by RFC 5226. I intended to instruct the RFC-editor in 10 days time about this change. If there are any objections please bring those forward. Cheers Magnus Westerlund IETF Transport Area Director -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Draft-ietf-nsis-ntlp: Late change of IANA consideration section
Thomas, A mistake in writing the motivation from me. It is the IANA actions that has Standards Action that can't really be combined with experimental status. And you and Jari has clarified why that doesn't work. Yes, Specification Required would work, but would not require IETF last call. Which was one of the goals here. Thus the suggested IETF review. Magnus Thomas Narten skrev 2010-02-03 14:55: I like to inform everyone that we intended to make a post approval change to the IANA rules for GIST: General Internet Signalling Transport (draft-ietf-nsis-ntlp-20). This document is approved for publication as experimental. In the change of intended status during IESG processing, we failed to adjust the policies on the IANA registries this document creates. Thus there are registries that has the policy of Specification Required, which are almost impossible to fulfill when the normative reference is going to be experimental. Thus we intend to address this by changing all Standards Action policies to IETF Review as specified by RFC 5226. I don't necessarily have an opinion about the proposed changes, but I don't quite understand the rationale. Specification Required is intended to allow for publication of documents outside of RFCs. It reqiures an Expert Reviewer to look at the document and make a determination about whether the spec is sufficiently implementable. That is, RFC 5226 says: Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind permanent and readily available is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review. Examples: Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124], TLS ClientCertificateType Identifiers [RFC4346], ROHC Profile Identifiers [RFC4995]. Given that, could you please clarify what you mean by Thus there are registries that has the policy of Specification Required, which are almost impossible to fulfill when the normative reference is going to be experimental. IMO, an experimental RFC would be fine for specification required. Thomas -- Magnus Westerlund IETF Transport Area Director -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-Art Review: draft-ietf-nsis-qspec-22.txt
: Should there be an editorial note when minimum QoS is first described indicating that the term minimum is used generically, as for many parameters, like loss rate or latency, what needs to be specified is the maximum acceptable value? -- Magnus Westerlund IETF Transport Area Director -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC
Hi, My review of the changes is that they appear reasonable changes to address the raised changes. I have putted the document on the IESG agenda for the 13th of August. If you think that the changes are not addressing your concern please raise this before the 30th of July. Best Regards Magnus Westerlund IETF Transport Area Director -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC
Hi, I got a comment regarding my statement below. I missed making it clear that this concerns what it possible to do using a single IP address on the client side, even if there are more possibilities if you have multiple ones. Magnus Westerlund skrev: Hi, After having reviewed all the last call comments I like to make a consensus call on this document. I think there is rough consensus for publication of this document given that it is updated to make the following clear: - Make the applicability statement more clear on that any determination is transient and may contain error requiring a user to have a fall back. - Make the proposed experiments clearer on how they can utilize the mechanism. Especially the P2P needs to make clear why this could be applicable given the limitations. - Make clear that the algorithms are proposals of what can be determined using the STUN attributes and their behaviors using a single IP address on the client side. Additional determinations are possible. -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC
Hi, After having reviewed all the last call comments I like to make a consensus call on this document. I think there is rough consensus for publication of this document given that it is updated to make the following clear: - Make the applicability statement more clear on that any determination is transient and may contain error requiring a user to have a fall back. - Make the proposed experiments clearer on how they can utilize the mechanism. Especially the P2P needs to make clear why this could be applicable given the limitations. - Make clear that the algorithms are proposals of what can be determined using the STUN attributes and their behaviors. Additional determinations are possible. Best Regards Magnus On Mar 10, 2009, at 8:44 AM, The IESG wrote: The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'NAT Behavior Discovery Using STUN ' draft-ietf-behave-nat-behavior-discovery-06.txt as an Experimental 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-03-31. 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-behave-nat-behavior-discovery-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15728rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/919/ https://datatracker.ietf.org/ipr/945/ ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Last Call: draft-ietf-behave-nat-behavior-discovery (NAT Behavior Discovery Using STUN) to Experimental RFC
the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'NAT Behavior Discovery Using STUN ' draft-ietf-behave-nat-behavior-discovery-06.txt as an Experimental 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-03-31. 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-behave-nat-behavior-discovery-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15728rfc_flag=0 The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/919/ https://datatracker.ietf.org/ipr/945/ ___ Behave mailing list beh...@ietf.org https://www.ietf.org/mailman/listinfo/behave -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Where to discuss NAT66?
Tony Hain skrev: Cullen Jennings wrote: I'm sure that the IAB and IESG is keenly interested in this topic but everyone that cares is subscribed to behave. While I agree that everyone interested in defining nat behavior is subscribed to Behave, I doubt that everyone in the application community is, yet every one of them will be impacted by the fundamental architectural implications of this backroom rush to market effort. There has been no justification of the need for a 66nat, only wild claims that we need to do something now because people will be shipping them in the next few months. While I have no doubt that vendors will ship what their customers are asking for, it is not clear that the IETF should endorse an effort with such a wide ranging architectural impact. Never mind that if the vendors are really shipping in the next few months there is no chance that an IETF document would be published before there are products on the street Hosting this discussion in Behave assumes the outcome, and is absolutely the wrong place for an architectural discussion. This should be held in the Applications area, and only moved to Behave to resolve the implementation details once it is decided that a 66nat is absolutely necessary. Trying to do it by having people pre-disposed to an answer and without any concern for the impact to the application community is guaranteed to result in perpetuating an unnecessary architectural wart. Tony, We had quite some discussion in IESG about where to discuss this topic. There is no perfect fit. I think it is time to move it from Behave to its own list as the discussion continues to go on and impacts Behave's chartered work. However, the issues as you say is that it is an architectural discussion and it affects all layers from routing up to application. Which means that we need insights from all layers. But, we can't continue to have a good discussion by cross posting to all area list or the ietf@ietf.org list. Also be certain that we haven't decided anything about what to do with NAT66, except saying that we are allowing the discussion. There will be a BOF before anything if any is chartered on this topic. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: [EMAIL PROTECTED] -- ___ 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
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. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] Lack of need for 66nat : Long term impact to application developers
Please, any input into this debate shall go to the behave list. People interested in this topic please subscribe to Behave. Regards Magnus Peter Dambier skrev: Keith Moore wrote: absolutely it's too onerous. why in the world should an application's deployability depend on the existence of a server that lives in global address space -- or for that matter, on a bank of servers that exist to do nothing but forward traffic? isn't that what the network is supposed to do? That is what bothers me too. sip is mostly peer to peer, so for most of your communication (in megabytes) no server in a rack needed. Email, with fixed IPv6 addresses will become peer to peer again too. html? html is not much traffic. Many people do html hehind their NAT44 boxes today. There is still a lot to be done for zeroconf, so DNS still is ok with a server in a rack. Oh, I forgot. For DNS you are still dependent on IPv4. All the enthusiasts with their linux and freebsd boxes using ISATAP to communicate don't see a need for NAT66. It is the big guys with big windows servers who really need NAT66 to hide their fragile machines from the bad wild internet. I am one of those poor guys who has never been told what good NAT66 can do for him. I am still troubled by NAT44 preventing me from connecting with my ISATAP interface. I am running more than one computer. That is why I am imprisoned behind my NAT44 and I am afraid NAT66 will be yet another prison. I have seen with tunneling (slow as molasses) I get only a single /128. So I guess a bilingual router will sit on both his single IPv4 and another single IPv6 and keep all the traffic for himself letting me do the guesswork how to drill the holes I need to connect to the internet. I see with IPv6 I do have to compete with my fridge and the central heating drilling holes to talk to the butcher, the baker and the oil-tanker. None of them is living in a rack in a colocation. They all have to drill holes into their NAT66 to talk to my home. There is a hole industry living from selling me super excluse and expensive drilling machinery, I would not need if there was not a NAT66 in the first place. I know NAT44 is like my front door and keeps the bad internet out. But it is not NAT44, it is the firewall who keeps them out. Only a vague feeling for symmetry keeps telling me I should have a NAT66. Math is telling me that need not be true. IPv4 brought us from point to point clothes line to 2-dimensional space spanning continents. IPv6 will bring us 3-dimensional space spanning the globe and DNT will bring us even further. I do not know if there is such a thing as NAT66 existing. In 2-D space we do have trigons, squares, pentagons, hexagon... In 3-D space live stops with things built from pentagons. The guys with their big windows servers behind NAT44 are living in a 2-D world, dreaming their 2-D dreams bout selling us 3-D NAT66 boxes without even knowing the math. Kind regards Peter -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 10 7148287 Färögatan 6| Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
John C Klensin skrev: But apparently the IESG does not agree -- I hope not because, for some incomprehensible-to-me reason, they prefer the obscurity. The IESG is currently spending a substantial amount of time discussing this issue. I hope the community will see some of the fruits of this discussion in the near future. cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
SM skrev: At 03:01 22-09-2008, Magnus Westerlund wrote: As I stated in response to John's question. No, the spam problem for us contributors are one of the prices to contribute to IETF unfortunately. Item (1) takes us one step closer to discouraging the publication of email addresses instead of seeing it as one of the prices to pay for contributing to the IETF. I suggest dropping item (1) from the proposed statement. Okay. Will authors have to seek the permission from the holders, in the case of domain names (e.g. www.w3.org), before using such domains in RFCs? Depends fully on the context. In a reference I clearly say no. In a configuration script or as point to load validation data from, definitely! That sounds sensible at the outset. The following question is for a specific case. Will the IESG ask (I-D) authors to seek permission from the W3C before using the domain name in XML schemas? I would say no, without looking into this. Schema names that include domains clearly need to be included and in my view the one publishing schemas implictly have allowed the usage. I think this comes back to the common sense angle of this. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
Randy Dunlap skrev: Hi, My comment isn't similar to the rest of the mail threads here: I find the use of the word codepoint confusing here. It apparently means something different to some readers (or writers) here. To me (and I'm almost never unique in things like this), it means a point in a character set space. See http://en.wikipedia.org/wiki/Codepoint or possibly http://code.google.com/search/#q=codepoint . Maybe here it means an extension of that, like a (virtual) point in some world network address space. Is that close? Perhaps it should define what a codepoint is or use some other word/phrase for it. Thanks Randy, We used codepoint as the best word that was sufficiently encompassing about the different type of names and values for different type of name and value spaces. I think a clarification/definition will be the best way to resolve your comment. cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
Dave CROCKER skrev: Magnus Westerlund wrote: From my point of view the long usage and the lack of actual reported issues and minimal impact a change would have on the situation is why I cleared when I finally was engaged in any discussion on the issue. Magnus, Offhand, it would seem as if these ought to be strong factors nearly always. If folks disagree, that's probably worth discussing, since this is such a fundamental issue. (It's called protecting the installed base...) Fundamentally I do agree on this. However, I am also quite concerned that we in the IETF are not receiving reports about any problems we are creating. If an example creates just a little extra load this may never be looked into. One simply accepts it. I see a problem of correctly categorizing the impact of examples. That is why I would error on the side of caution. Especially when this can be done without any significant impact on how examples reads. At the least, it would seem that it ought to require that a very compelling case be made for changing things. If you are talking about updates to already deployed specifications I agree. But when it comes to new specifications that are written now I don't see a reason to not think about this. From what you are saying, it swayed you at the end. But evidently you weren't swayed at the start. It might be worth understanding why not, since it might provide some input for better understanding these types of disconnection between a working group's comfort with a decision, versus and area director's dis-comfort. In the SMTP case there where never any communication with me in the loop about my discuss position until after the appeal has been submitted. From the point we actually had any discussion it didn't take that long. But clearly a communication problem that involved several parties. I still consider it impolite to use others domain names and would have preferred to have some of the domain names changed for that reason. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
Hi John, I have tried to write a statement that allows the IESG to use common sense. However, the problem I have seen several times when the IESG tries to use common sense in issues that comes up regularly is that some people complains about not knowing about this and that we can't enforce it because there are no written rules. Thus the draft statement is an attempt to satisfy several different requirements: - Provide motivation why there are issues with examples - Provide some guidance on how to handle situations which aren't clear cut - Be clear that this is something IESG do look at and authors need to think about. - Prevent complaints about late surprise and heavy hands when we are applying what we think are common sense. If you have a suggestion on how this better can be written up I am interested. When it comes to harm, I think we clearly have some cases where examples can have really serious effects, configurations being what comes to mind. When it comes to email addresses they are primarily an annoyance, but I think any one of us would be might irritated to learn that the suddenly started receive spam in large quantities because someone published their address in example in an internet draft or RFC. I think that this is as far as this goes and something any contributor to the IETF unfortunately have to pay for their contribution in an open organization with open access to its documents. Best Regards Magnus -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
SM skrev: 1) Spam: apparently valid email addresses in an RFC are widely believed to have been harvested and included in Spam lists. The domain may receive spam at mailboxes other than the one used in the example email address, if the domain name is used in common name or brute force attacks. Given that the IESG states that the use of valid email addresses causes unwanted traffic, will the IESG prohibit the use of valid email addresses in RFCs? As I stated in response to John's question. No, the spam problem for us contributors are one of the prices to contribute to IETF unfortunately. Will authors have to seek the permission from the holders, in the case of domain names (e.g. www.w3.org), before using such domains in RFCs? Depends fully on the context. In a reference I clearly say no. In a configuration script or as point to load validation data from, definitely! Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
Spencer Dawkins skrev: Hi, Magnus, While not even dreaming of trying to speak for John, what I understood his point to be was that our process is, and needs to be, more than a set of rules. You guys are going to get complaints (and you know that better than I do). But you're going to get complaints whether there is a perfectly-crafted IESG statement or not. We've never recalled an AD, and we've never even had a public recall petition presented to the community. Please feel free to use your judgement, because the chances of that backfiring in any meaningful way are just about zero. On this particular topic, I've been really dismayed that we've gotten so far into the weeds on what was obviously (to me) an attempt to do the right thing - provide example domain names - that is now morphing into a set of rules. You guys can keep tuning (and probably will keep tuning), but - the principal justifications being advanced for why the problems you are solving are real, seem very bogus, and - you are spending valuable AD time trying to perfect a set of rules, so you are trying to use your judgement now to avoid having to use your judgement in the future. Specifications are hard. Corner cases make them harder. Don't write detailed specifications that you don't have to write. Asking authors to consider (!) using example domain names as part of last call comments, or AD review, is all that is required. Formally specifying when it is OK to use non-example domain names is overkill. I not trying to find perfect rules or even guidelines. I trying to find something that is reasonably works and is understandable by the community. And this is not about non-example domain names. It is about the general case. I thought that I had managed to do a reasonable generalization of the statement to cover examples of all types that may cause issues. But I am apparently wrong. However, I don't know if it is a function of the discussion around SMTP that make everyone dive straight into email addresses and domain names. But I do get the message make it even more general and don't have a lot of rules. Simply a statement about this and the need to consider it. Because I still have the feeling that if we don't publish any statement about examples then we will have a lot of complaints that; - the ID checklist can't contain think of statements because it is not a rule - as you haven't informed the community we will refuse to change text even if problematic. I also note that when we don't document reasonably well it becomes impossible for others than the long timers to understand what should be thought of. rant The but what if a domain name is published in an RFC and gets picked up by spammers? concern wasn't even realistic in 2000. It's totally unrealistic now. I challenge you guys to name any domain name that started getting spam because it was published in an RFC (or Internet-Draft) after 2005, and received no spam before publication. If this was a real problem we'd stop publishing author e-mail addresses in I-Ds and RFCs, and there's no chance we'll do that. So please take it as read that 99-point-something percent of e-mail is going to be spam anyway. /rant I agree that it is a red herring from most perspectives. I think all of us that have a reasonably big foot-print on the Internet do receive spam in quite large volumes. I personally receive on the order of 50 spam per day to my work account which is very well published, while my private account gets 5 per month. This is the result from writing to IETF mail lists, having my address in drafts and RFCs. No question about it. And I would be kind of annoyed if anyone of you decided to publish one of my private addresses without my permission. That is why SPAM was listed as an example. But as people are apparently get annoyed of this as an example of unwanted traffic I guess we should remove it because it isn't the most important. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
Doug Ewell skrev: Magnus Westerlund magnus dot westerlund at ericsson dot com wrote: I think any one of us would be might irritated to learn that the suddenly started receive spam in large quantities because someone published their address in example in an internet draft or RFC. and later: And I would be kind of annoyed if anyone of you decided to publish one of my private addresses without my permission. That is why SPAM was listed as an example. Is that the concern, that people will start receiving spam to their e-mail addresses, or excessive or inappropriate hits on their Web site, unexpectedly or without their permission, because these addresses were used in an RFC or I-D unexpectedly or without their permission? From my point of view this is one of many reasons why care needs to be taken with what one puts into examples. Clearly a minor issue, more about etiquette than anything else. Configuration files are clearly one of the major issues where inclusion of someones NTP sever in something that accidentally gets deployed can amount to a DDoS. I think that is a completely different use case, and moral problem, from using one's own e-mail address or URL in a document, or using well-known addresses such as [EMAIL PROTECTED] that have already appeared in well-known and heavily cited RFCs (John's use case that launched the present debate). Agreed. And that was not really what the discusses from IESG was based on either. The one I reacted to where the ones belonging to commercial websites. Which, I personally consider inappropriate an a bit rude. From my point of view the long usage and the lack of actual reported issues and minimal impact a change would have on the situation is why I cleared when I finally was engaged in any discussion on the issue. However, the goal with the statement is to cover the general issues not specific ones. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed IESG Statement on Examples
John, I might be to much a protocol designer to be a good writer of rule documents. I will take your, Spencer's and Dave's input when reformulating the note. Cheers Magnus John C Klensin skrev: --On Monday, 22 September, 2008 11:40 +0200 Magnus Westerlund [EMAIL PROTECTED] wrote: Hi John, I have tried to write a statement that allows the IESG to use common sense. However, the problem I have seen several times when the IESG tries to use common sense in issues that comes up regularly is that some people complains about not knowing about this and that we can't enforce it because there are no written rules. Magnus, Spencer's note does a fairly good job of summarizing most of my concerns. Let me address a few things that he does not, but please read his note along with this one. First of all, I see a huge difference among three categories that your note, and the draft statement, seem to roll together: (i) The class of things that the IPR WG might think of as code, here including MIBs, configuration files, tables, and code excerpts that implementers are expected to copy, either verbatim or with simple, template-like, modifications. (ii) Test scripts and similar things, written in a form in which they will obviously be copied, perhaps modified slightly, and then executed repeatedly (with fairly high multiples of repeatedly). (iii) Simple, illustrative examples that, even if executed, are not likely to be executed more than once by a given implementer. One might draw the boundaries in other ways, but they are different enough that saying the cases in the first group are harmful, therefore the cases in the third are harmful enough to require extensive rules is just bogus. Thus the draft statement is an attempt to satisfy several different requirements: - Provide motivation why there are issues with examples - Provide some guidance on how to handle situations which aren't clear cut - Be clear that this is something IESG do look at and authors need to think about. - Prevent complaints about late surprise and heavy hands when we are applying what we think are common sense. One can make extensive rules or one can apply common sense. The pushback when this came up was because of a perception that common sense was _not_ being applied. This document does not somehow instantiate common sense, what it does it to transform the rigid rule that was undocumented into the rigid rule that is. And, while undocumented makes things much worse, the real objection is to the rigid rule, especially against the backdrop of a concern that it will take far too much time and energy to get such a rule right and that there will _still_ be exception cases. In general, any time you write a page of rules and case analysis when a sentence of guidance would do, I (and perhaps others) are going to object. Keeping things simple is of significant and substantive importance. If you have a suggestion on how this better can be written up I am interested. Yes. I've made that suggestion several times. It was actually in my previous note (see Pasi's comment). Don't try to delineate every case and build a rule on that basis. Just indicate that you expect safe/protected/reserved names (or codepoints or other identifiers), to be used, especially when they occur in situations in which copying and repeated execution are likely and that, if the author believes otherwise, that must be explained in a comment (in the document or wherever else you would like it) that is clear enough that the community can comment on the justification during Last Call. If you want to say something about the difference between new and revised documents, I would, based on recent experience, appreciate it, but I don't think even that is necessary. When it comes to harm, I think we clearly have some cases where examples can have really serious effects, configurations being what comes to mind. When it comes to email addresses they are primarily an annoyance, but I think any one of us would be might irritated to learn that the suddenly started receive spam in large quantities because someone published their address in example in an internet draft or RFC. I think that this is as far as this goes and something any contributor to the IETF unfortunately have to pay for their contribution in an open organization with open access to its documents. See Spencer's note about spam and the comment above about conflating configurations with email addresses in a purely illustrative example. regards, john -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax
Re: Call for review of proposed IESG Statement on Examples
Hi John, Thanks for the comments. Please see inline. John C Klensin skrev: A brief comment on this... I may have more to say later on... --On Thursday, 18 September, 2008 10:07 -0700 The IESG [EMAIL PROTECTED] wrote: The IESG has received the attached text for a proposed IESG Statement: IESG Statement on the Usage of Assignable Codepoints in Specification Examples ... = = = = = = Text of Proposed IESG Statement = = = = = = = ... 1) Spam: apparently valid email addresses in an RFC are widely believed to have been harvested and included in Spam lists. The domain may receive spam at mailboxes other than the one used in the example email address, if the domain name is used in common name or brute force attacks. Please note that a careful reading of this paragraph would either ban or discourage the appearance of author email addresses in RFCs. Yet such addresses have been a firm requirement for many years (if I recall, since before there was an IETF). Questions: (i) Does the IESG intend to change the requirement for email addresses? No, that has not been the intention. I also don't think the statement say anything that explicitly changes that. (ii) Does the IESG believe that the appearance of a domain name in an email address in an example is somehow more harmful or likely to draw the attention of spammers than one in an Author's Address section? If not, could you explain your reasoning? No, I don't think there is a difference from a spam perspective. From my point of view it is quite clear that the moment I stuck my email address in a internet draft I started receiving spam volumes several magnitudes larger than before. So as an author using your own address in an example may not make much difference from a spam perspective. However, it make more difference for other reasons, like if it is a test script you are putting in your email address in. If you are putting someone else email address into your document you may increase there volume of spam. (iii) Does the IESG intend to pursue the idea, discussed many times, of creating a reserved mail domain and assigning all RFC authors mailboxes or aliases in it? We haven't discussed this at all at this point in time. I don't see how applicable this is to the general intention of the IESG statement to cover all type of codepoints, including domain names, email addresses, and media types. So if we want to continue any discussion on this topic, can we please that that in a separate thread. I note with interest that this statement does not appear to apply (or at least does not appear to offer justification for applying) these rules to domain names that do not appear in email addresses (or in configuration files, etc.). The statement intendeds to provide examples why using real domain names or other types of code points can be harmful. Reasons will vary with protocol and the type of codepoint. And there will be cases where there will be no impact, maybe other than us being a little rude and using someone else domain name. Which I think is a good enough reason unless there some real counter reason while this particular name is so good for the example and can't be illustrated with another. And as the statement says, in those cases, please ask the owner before going ahead. I note with even more interest that reservation of codepoints for example or other documentation purposes would violate existing IESG statements and rules about conservation of scarce resources (where scarcity is an issue) or would require negotiation with other bodies. Which IESG statements are you referring to? I can't find any on that topic, but I may be missing one. There clearly are tradeoffs between assigning code-points and the possible scarcity or unavailability of them. Then one simple have to use another option of ensuring that this usage has minimal impact. Including using assigned values with the owners approval. It also include the consideration of the impact. Maybe there are some text clarification that could help make this clearer. Adding something to the following bullet , unless prevented by scarcity or other registration considerations. - The specification itself can request further values or codepoints to be assigned. I do like to point out that the goal with the statement is to have people think about these issues. Be aware that IESG will consider them and may object to certain usages unless reasonably motivated. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto
Re: Call for review of proposed IESG Statement on Examples
Hi Stephane, See below: Stephane Bortzmeyer skrev: On Fri, Sep 19, 2008 at 10:34:46AM +0200, Magnus Westerlund [EMAIL PROTECTED] wrote a message of 122 lines which said: I note with even more interest that reservation of codepoints for example or other documentation purposes would violate existing IESG statements and rules about conservation of scarce resources (where scarcity is an issue) or would require negotiation with other bodies. Which IESG statements are you referring to? The rules I'm personally concerned about when reading the proposed IESG statement are: RFC 5236, section 3.3 (which mentions scarcity) Do you mean another RFC, that RFC is Improved Packet Reordering Metrics and Section 3.3 is the definition of Displacement metric. RFC 5237 for an example in a densely populated field Yes, I am aware that there exist codepoints where there are little space to assign values for example usage. That is why this is recommendations, not strict requirements. And if you are writing a new protocol and you think there will be need to examples including a particular field, then you can create the example codepoints at time of defining the field. I hear the message that we need to be clearer on that it might not be possible and the other alternatives is to be explored. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Färögatan 6| Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Should the RFC Editor publish an RFC in less than 2 months?
Brian E Carpenter skrev: On 2007-12-01 00:45, Harald Alvestrand wrote: Tom.Petch wrote: I recall a recent occasion when the IESG withdrew its approval, for draft-housley-tls-authz-extns a document that both before and after its approval generated a lot of heat, within and without a WG. Presumably the expedited process would, or at least could, have seen that published as an RFC. With that example in mind, a 60 day hold seems rather a good idea. In that case, it went into the RFC Editor queue on June 30,, 2006, and was yanked from the queue on February 26, 2007 - 8 months later. According to the third last call announcement: On June 27, 2006, the IESG approved Transport Layer Security (TLS) Authorization Extensions, (draft-housley-tls-authz-extns) as a proposed standard. On November 29, 2006, Redphone Security (with whom Mark Brown, a co-author of the draft is affiliated) filed IETF IPR disclosure 767. it was five months between approval and the IPR disclosure. A two-month hold wouldn't have caught it. (No idea why it was still hanging there long enough for the IPR disclosure to catch up with it...) In any case, I would much rather have seen that published and later declared Historic than hold up all other RFCs. It isn't as if the IETF can control what actually gets implemented and deployed in any case - so why on earth does it *matter*? Whereas getting the vast majority of RFCs published promptly *does* matter. I am actually worried with the inter SDO implications of blocking publication for 2 months. Unless we actually always block publication for 2 month for approval this doesn't help. So what are we going to say to other SDO and they ask, can you do your best to get this document published. And then we have to say, well the document can be made ready but we can't for formal reasons provide it until 2 months have past. I think this would be going in the wrong direction on use cooperating with other SDOs. However, it clearly solves the issue with appeals and if it is IESG or IAB discretion whether the document is blocked or not. I actually are worried that people may use a appeals always block publication as way of forcing removal of ietf protocols from other SDOs specifications. The reality is that neither IESG or IAB can process appeals extremely quickly. Unless they are obvious bogus. Cheers Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-avt-topologies-06.txt
Yes, it is a typo. Magnus Suresh Krishnan skrev: I am the assigned Gen-ART reviewer for draft-ietf-avt-topologies-06.txt For background on Gen-ART, please see the FAQ at 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. Summary: This draft is very well written, an enjoyable read and is almost ready for publication except for a minor comment. Minor = ASM is a term commonly used in multicast to mean Any Source Multicast (as opposed to Source Specific Multicast). The glossary of this draft redefines this to be Asynchronous Multicast. Is this just a typo? Because from my reading of the draft all instances of this acronym actually use it in the context of Any Source Multicast. If it is just a typo it can be fixed with just an RFC-Editor note. Cheers Suresh -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM/M -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
Hi, My reading of this thread of comments is that there is no reason to change anything regarding the document. I will therefore progress this document towards approval. Regards Magnus Westerlund Brian E Carpenter skrev: On 2007-10-05 05:38, ken carlberg wrote: I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) I would be concerned if outside groups spent time arguing foo is bad, or if they advocated other positions to the same issue. But I tend to feel quite uncomfortable with litmus tests based on inactivity of other groups/people. My personal view is that advocates of that line of reasoning place a bigger burden on themselves in providing specific in-depth arguments. Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. i appreciate work that is trivial because its generally simple, easy to accomplish, and leads to fewer interoperability issues. as for ISPs, its fascinating the disparity of how quiet and talkative they are depending on what side of the NDA you are on :-) In any case, if Pekka is correct, that's *exactly* why this draft and RFC 4594 are needed - to lay a minimum foundation on which ISPs can build operational practices and SLAs. It's always been clear to me that voice and video would be the main drivers for uptake of diffserv, and Marshall's comments confirm that. As that type of traffic grows, ISPs won't have any choice. Guidnace from the IETF seems entirely appropriate. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM/M -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iesg-media-type-00.txt
Hi Bruce, Please consider what Stephan Casner says. I totally agree with his response. I simply want to make a few comments. I think you really should ask yourself how it comes that the current process has been used in 6-7 years and for more than 70 registrations without anyone raising any issues. I take this as an sign that the current process works and is viable. It can only benefit from a bit of clarification. For example in the area of text. Where all we desire is clarification on the possibility to register types that are restricted to RTP without the strict requirement on basic parsing. I also question if the MIME world really can continue using that criteria themselves. Is this really working, it seems not in the application I am using. I don't want to see the html formating in my browser, even if it is readable. Bruce Lilly wrote: I have suggested grandfathering existing RTP-related registrations in a separate RTP registry. That would prevent further confusion and would give the RTP registry a separate sandbox with clean sand and new toys. Some small amount of copying work would be required, and of course registration procedures for both registries would require some minor tweaking. We don't want a new sandbox, moving from the current is such work that it isn't worth it with the small gain and great risk for confusion it creates. What I suggest is that we clean up the current sandbox so that we can reduce the confusion on what is in it and what is allowed. Because of widely-deployed mission-critical MIME applications, any such clean up cannot change the fundamental rules for text media types, as detailed earlier. We're not talking about mere entertainment applications, we're talking about email and things like Internet fax, voice messaging, and EDI. I am not intending to breaking MIME based applications. I want to avoid breaking any of the applications, MIME or RTP. But you seem to be fine saying that breaking RTP does not count, it isn't mission critical, despite it being a hugely deployed protocol. Separating the registries will cause confusion, generate errors and inconsistencies in a number of standard documents IETF's and others. Re workload: o for whom? A separate registry would mean that AVT would need to perform the following work: - Write a new registration RFC - Update the 70+ registrations documented in 35+ RFC - Inform a number of standard organizations or consortium like ITU, ETSI, 3GPP, 3GPP2, DLNA, etc about the new rules and have them update their specifications. Are you volunteering to see these changes thou? Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iesg-media-type-00.txt
Further clarifications inline. Robert Elz wrote: Date:Fri, 01 Jul 2005 17:38:19 +0200 From:Magnus Westerlund [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] I understand everything you're saying, except this part... | I do want to point out that how we RTP uses the top-part of the media | type name. They are used to explicitly identify which other media | formats they are okay to multiplex in the same session. OK, that part too... | This also | ensures that different media types are not multiplexed on the same RTP | session. And that... Due to what is written in section 5.2 of RFC 3550 different media types (audio, video, text) should be separated into different RTP sessions. To achieve this each RTP payload format has a top level media type it belongs to. This assignment binds it to which other media types it is possible to multiplex. This top-level type is also explicitly provided in SDP for each RTP session which is helping us to ensure that RTP payload are only used in RTP sessions of the correct media top level. | Thus we need to be able to register RTP payload formats also in | text top-level type. Now, I'm lost. You just finished explaining how the RTP media types are all different from all other media types, because they necessarily need to retain the RTP packet info (or I'd guess perhaps some of that, but it doesn't matter) as an essential part of a data. Yes, information in the RTP header is essential part of the data. Now you seem to be saying that it is OK to multiplex a text/plain or a text/html into the same data stream. How? Those don't contain the RTP packet info, do they? What you are suggesting isn't possible as neither text/plain or text/html has any defined RTP payload format and are not likely to get one as they have no real-time properties. Nothing is transported in RTP without an defined RTP payload format. What I like to stress in regards to the text top level type is the following. - From an RTP perspective all the media types (audio, video and text) are all needed, but non are special or have special rules. The only things that matters is the media types general properties and that they provide appropriate grouping. - Text is different in its properties from audio and video and should therefore be using its own media type. - When new RTP payload formats are defined for carrying text with real-time properties we will need to register them in the text top-level not any other top-level media type. Or is this just because you have some text/x types already, and want to be able to add new ones to the same set? If that's it, would it be possible to rename the existing text/* (RTP) types into something else, like rtp-text/* so that the confusion goes away? I think Colin responded to that. However, yes you are correct we do already have text/x types and we expect there will be a small but increasing set of type that are text. Renaming the current into another top-level domain does not reduce the confusion, it only increases it. It is also something that makes millions of deployed devices interoperable. Please understand that what we are discussing is something that has been done for a long time and have very many deployed implementations (on the order of 100 million instances). This usage of media types are in every Windows or Apple box that has Quicktime, Real, or Windows media players, it is in many mobile phones sold the last 2-3 years. So please remember that any change that would jeopardize interoperability has the same impact as when people touches the email system in a non backwards compatible way. So changing a top-level media type from text to rtp-text would be bad, really bad. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iesg-media-type-00.txt
Hi Bruce, I will comment some of the arguments that you list. And if we where having this discussion before any RTP payload name registry existed at all I would definitely be tempted by separated registries. However the fact that we have used an IETF established policy for more than 5 years and registered a large amount of names (70) makes it very hard to see that moving into separated registries will resolve any confusion. In addition it will require a huge work effort to move to the new registry. I can also contest that AVT doesn't have a hoard of people interested in updating media types registrations. We can barely manage to perform updates of our own major RTP payload formats. When it comes to RTP payload formats there are always demand for new ones as new media codecs are defined, but the ones are already out-dated and sees less and less use there is little interest for. Especially to perform an exercise that provides no improvement. To me the best way forward is that we clean up the registration procedures of the current media types registry. Clearly document the fact that there are at least two different usages for the media types registry. It will help reduce the confusion that exist and have minimal workload. Bruce Lilly wrote: Date: 2005-07-01 11:38 From: Magnus Westerlund [EMAIL PROTECTED] Both in RTP and MIME usage the types are after all media formats with specified represenations. That's a good reason to have registries which share certain characteristics, but it does not require sharing the same registry and namespace. The issue I see is that with two separate registries one will not seriously consider the names in the other registry. Having one registry with all representation instead of separating does not simplify the process of maintaining good usage of that registry and avoid duplicating entires when there actually are two different representations. I'm not sure that I completely understand what you mean. Anyway: Sorry for the bad sentence structure. What I intended to stress was that having cross review between registries is a hard way of avoiding having two different formats register the same name but in different registries. As the name structure looks the same, it is very hard to determine to which registry such a name would belong. Thus one needs to look up both if checking. I think having a single registry with clearly marked usage is a simplification. If there is a single registry: o each MIME and each RTP implementer will have to examine each entry and determine: * is this media type applicable to my work? - yes - no - unclear This is clearly more work for implementers if there is a combined registry. To the extent that implementers ask questions (what's this 'framed' stuff?), it may be more work for registered contacts also. From my perspective a implementor normally know what it needs to support on a fundamental level. I need to support the AMR codec. From that perspective looking up audio/amr in either of the registries will be simple. In fact this is one of the media types that are both RTP and file format. This would need to be doubly registered and thus needs links to the other registry to have people avoid taking the wrong version if they are lacking the necessary knowledge. If the registry page would include columns that indicated usage of the media type this can easily be resolved. o the registration procedures, forms, review forum, etc. will have to accommodate items which are the union of items which are individually applicable to different uses * MIME registrants will continually ask what is this 'framed' encoding stuff? * RTP registrants will continually be told your 'text' type is incompatible with the requirements for 'no software required', 'fallback to text/plain', etc. These reasons you list are due to the unclarity regarding the procedure. If one clears this up and makes it clear what is applicable and provide more concrete example then I don't think it will be a big problem. These have been observed issues with use of the MIME registry for RTP What are you referring to. I don't think there has been any serious issues other than the ones that occur at registration time due to unclear process. That I think can be understood also by those registering for MIME usage only. o if there is some media type that is usable by MIME and by RTP, it need only be registered once (unless of course there are differences in parameters, security issues, etc, in the registration form that would indicate separate registration) * the key question is, are there any such types? - clearly you have said that, unlike MIME media types, the RTP types cannot be stored in a file, etc. So it's clear that the RTP types cannot be used by MIME - can the MIME types be used by RTP? For example, can RTP make use of the MIME
How to unsubscribe from a mailing list
Please, If you have managed to subscribe to the list one could hope that people know how to unsubscribe. No mailing list that I know of perform unsubscribe operation by sending a mail to the complete list. Such mails only irritates other people on the list. The easiest way of unsubscribing is to go the the mailing lists web page: https://www1.ietf.org/mailman/listinfo/ietf Enter your email address in the field next to the button labeled: Unsubscribe or edit options, press it. The unsubscription information is actually present in every mail you receive from a mailman list. If you check the mail headers you will find the following header: List-Unsubscribe: https://www1.ietf.org/mailman/listinfo/ietf, mailto:[EMAIL PROTECTED] You also receive a link for option changing and unsubscription in the monthly reminder. Best Regard Magnus Westerlund G.V.Raju wrote: Please unsubscribe me -- Watch your thoughts; they become your words. Watch your words; they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character for it will become your destiny. - Frank Outlaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-iesg-media-type-00.txt
Robert Elz wrote: 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. My interpretation of what you try to express is that things should be have different names when they have different representations, but not when they are transported over different protocols. In response to that I do agree, however RTP is part of the representation of data. You can't remove RTP without loosing part of the data or converting it into another representation where RTP isn't included. I would like to point out that the same RTP payload media types are used independently if we send RTP over UDP, DCCP or TCP. 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. Your first error in this example is the (unchanged, but removed from its RTP transport) which directly relates to its representation. To remove the data from its RTP transport would not be possible without conversion. You will have to do some processing going from RTP to a file format. To be able to write it as a file you will need a file format. That file format will have its own media type that can be used to name what you have saved. Thus lets say you have an 3GPP Timed Text media stream in its RTP payload format (video/3gpp-tt). This media formats is only specified to be stored within a 3GP file (video/3GPP). Thus you have to perform a conversion with a clear mapping. If you wouldn't perform the removal of RTP you could possibly store the sequence of RTP packets. However that would be an RTP dump file. That file also needs its corresponding configuration data. Otherwise it is simply an stream of RTP packets containg something unknown. So please understand that RTP is part of the representation and it can't escape into another representation without deliberate processing. Thus defining media types that is explicitly called out as being RTP only and being framed does not represent a risk for ending up in a MIME processor unless someone has missused the type. Someting which could just as well happen with the media types intended for MIME. I do want to point out that how we RTP uses the top-part of the media type name. They are used to explicitly identify which other media formats they are okay to multiplex in the same session. This also ensures that different media types are not multiplexed on the same RTP session. The reason for this practice can be read in secton 5.2 of RFC 3550. Thus we need to be able to register RTP payload formats also in text top-level type. So if the conclusion is to go with keeping one registry I hope people understand we can't receive the same flak every time we writes text/. I think there are good reasons for keeping the registry as one. Both in RTP and MIME usage the types are after all media formats with specified represenations. Having one registry with all representation instead of separating does not simplify the process of maintaining good usage of that registry and avoid duplicating entires when there actually are two different representations. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: RTSP syntax definition incomplete.
Hi Johan, It is a known error in the RTSP specification. I can't really tell if your scenario is okey. You should forward your question to the MMUSIC WG, mailing list is [EMAIL PROTECTED], which created the RTSP protocol. Regards Magnus Johan Gerhardsson wrote: Hello, requesting comments from anyone who has worked with RTSP design, implementation or deployment. If I were to make an RTSP proxy, is it possible to change the SETUP response (from server to the proxy) and add the 'source' parameter in the 'transport' header field to be: source=address of server before forwarding the message to the client? The purpose of this action would be to instruct an access router to have the media (RTP) packets (from server destined to the proxy) redirected to the client instead of the proxy. The client would then see that the source address of the media packets is equal to the server address and not the proxy. In reading RFC 2326, Real Time Streaming Protocol the Transport parameter named 'source' is mentioned (on page 59) but not defined in the syntax definition (on page 61). I hope this is just a typo cause I want to use this mechanism for the purpose described above. Does anyone see a problem with this scenario? Johan Gerhardsson Reddo Networks AB email: [EMAIL PROTECTED] phone: +46 (0)73 942 2436 http://reddo.net Livdjursgatan 4 12162 Johanneshov, Stockholm, Sweden -- Magnus Westerlund Audio Technology, Ericsson Research -- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED]
