Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
On Oct 8, 2013, at 3:38 PM, Ted Lemon ted.le...@nominum.com wrote: On Oct 8, 2013, at 4:30 PM, Cullen Jennings (fluffy) flu...@cisco.com wrote: Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the OS to redo DHCP when they fail an application level connection. This use case is a good example of when to use an FQDN format for a DHCP option. However, it's not a great example of when to use a DHCP option—configuring SIP servers with DHCP is generally a bad idea, because if your device is connected to a new network, it will blindly take the SIP server IP address or FQDN information from the DHCP server and use it, and that SIP server might well perform an MitM attack or the like. So it's only in the very restricted use case of a Cisco IP phone permanently installed on a desktop and connected to a trusted network that (a) configuring SIP via DHCP makes sense, and (b) using the FQDN is a good idea. Of course it's possible that my limited understanding of how SIP works is preventing me from seeing why it's safe to configure SIP service using DHCP, but I'm assuming that that's not the case in this argument; please feel free to correct me. Nah, it's not quite like that - Long story how that it but the security mechanism make sure you authenticate both ends to stop that. We've actually been having this same conversation on the iesg mailing list, and I asserted that SIP was something you ought not to configure with DHCP; your use case is the one case where it sort of makes sense. Can you think of similar use cases where it actually makes sense to configure these parameters via DHCP? Possibly the right solution is to update the document to talk about this sort of restricted use case as one where FQDNs actually do make sense. The document certainly doesn't say you _can't_ use FQDNs, but we see people wanting to use them a lot in cases where they really don't make sense, hence the advice. Historically I don't think we bothered to make this distinction when defining new DHCP options, but it seems like a useful distinction to make. Help educate me on this a bit - I don't see all the things that get requested of DHCP. What are some examples of things where people are request FQDN where IP would be better. I think having some real examples that have come up would make it easier to see what advice is needed.
Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
On Oct 9, 2013, at 9:47 AM, Ted Lemon ted.le...@nominum.com wrote: On Oct 9, 2013, at 11:26 AM, Cullen Jennings (fluffy) flu...@cisco.com wrote: Help educate me on this a bit - I don't see all the things that get requested of DHCP. What are some examples of things where people are request FQDN where IP would be better. I think having some real examples that have come up would make it easier to see what advice is needed. DNS server IP address. NTP server IP address. Router IP address (not in DHCPv6, of course). AFTR IP address. Basically, network infrastructure IP addresses. Well DNS and Router obviously won't work with FQDN so lets talk about NTP for a minute. (and sorry, I don't even know what AFTR IP is). I design lots of devices that have to be plugged into a network and just start working with no user interaction. Getting the correct time is often really useful to have - particularly with synchronization protocols. One approach would be to hard code that NTP server name in the the product. That is not my preferred approach because stuff goes wrong and you end up with things like http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse . Another approach is for DHCP to provide the NTP server info. I would argue that getting a FQDN of the NTP server pool is a better design for DHCP than getting an IP address because this allow DNS load balancing across the pool and allows the server IP to change over time and still not have client failures. You agree that FQDN is would be a better design than IP for NTP ? Bear in mind that the set of services configured by DHCP ought to be pretty small—just things that really are local network infrastructure services, not things that are specific to the host and not to the network. It's not even clear to me that NTP ought to be configured by DHCP, and indeed in most cases it is not, despite there being an RFC describing how to do it. Considering the case of SIP, when you configure SIP I think that's probably a configuration that shouldn't change as the phone moves from network to network. Agree - it does not change as phones move network to network. It is uses DHCP the first time the phone is plugged in. The whole design is around making sure the phone can go from the manufacture to the end user without ever being removed from the box or powered up be an admin. The admin configures the call control system based on knowledge about the phone and which user the phone is going to but the admin does not need to touch the phone. When the phone first boots it imprint baby duck style on a network to get the configuration information which is encrypted with that phones public key. After that the phone use that configuration information not the DHCP (unless the phone is factory reset). It's actually a lot more complicated than that because security relies on replacement of manufacture certificates with the service provider certificates to make sure a comprise of the manufactures CA only results in service provider not being able to enroll new phones but does not compromise security of operational phone network. However, the first time the phone boots, DHCP needs to let the phone know who the likely service provider might be. If the phone gets the wrong DHCP information from an attacker or wrong network, the phone fails to configure but does not suffer MITM attacks. Using DHCP for phones has been used by pretty much every IP phone manufactures and most enterprise deployments and many residential providers including folks ranging from vonage to ATT take advantage of it. DHCP greatly reduce the deployment costs of setting up VoIP networks. We had a lot of learning from the phone deployments and I expect us to use what we learned there for how we do IoT. (I presented a paper on this at the IAB workshop on IoT). One of the things we learned the hard way was names work better than numbers. So it shouldn't be configured by DHCP. In the case where the phone happens not to be likely to move from network to network, you could _get away_ with using DHCP. But a solution that would work for phones that _do_ move from network to network would also work for phones that do not, and that solution would therefore be preferable, particularly as an MTI solution, since it addresses all use cases. As I mentioned in the IESG discussion, it is a shame that aggsrv didn't become a working group, since it was intended to address this specific problem, at least as I understood it.
Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
On Oct 9, 2013, at 11:53 AM, Ted Lemon ted.le...@nominum.com wrote: On Oct 9, 2013, at 1:32 PM, Cullen Jennings flu...@iii.ca wrote: Well DNS and Router obviously won't work with FQDN so lets talk about NTP for a minute. (and sorry, I don't even know what AFTR IP is). I design lots of devices that have to be plugged into a network and just start working with no user interaction. Getting the correct time is often really useful to have - particularly with synchronization protocols. An AFTR IP address is like a router IP address, but for a particular IPv4 transition technology. Other transition technologies of this sort are classic examples of services that make sense to configure with DHCP, because they are part of the network infrastructure. One approach would be to hard code that NTP server name in the the product. That is not my preferred approach because stuff goes wrong and you end up with things like http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse . Apple hard-codes the FQDN of a set of NTP servers they control into all their products. I think other OS vendors do as well, but am not clear on the details. The advantage of doing this is that you can then authenticate your communication with the NTP server. If you use DHCP to configure your NTP server, you cannot validate your communication with your NTP server. Of course there's a bit of a chicken-and-egg problem here in terms of replay attacks and key repudiation, but in principle you get more security if you hard code the FQDN of your NTP server than if you use DHCP to configure it. Hard coding it means you can't make your device work if you are on a network that behind a firewall that does not allow the traffic or is on a networks that is not part of the internet or is being set up for use in emergency communications where the the device is on a network say in Hati that has become partitioned from rest of network after an disaster. Obviously one can fallback to a hard coded option if no DHCP option is found but it's pretty important to have a chance of being able to configure things to work on networks with less than ideal connectivity. Of course there are cases where this doesn't matter, and DHCP is just fine, but I can't think of any other than perhaps a self-setting wall clock. Of course, if a CPE vendor were to hard-code the FQDN of an NTP server belonging to someone else into their devices, that would be disastrous. Another approach is for DHCP to provide the NTP server info. I would argue that getting a FQDN of the NTP server pool is a better design for DHCP than getting an IP address because this allow DNS load balancing across the pool and allows the server IP to change over time and still not have client failures. You'd get the same effect if the DHCP server did the lookup. I agree that if you want to suddenly add an NTP server and need it to be adopted in a time frame shorter than your typical lease time, and your DNS TTL is shorter than your typical lease time, you will get better service using DNS, but there's no clear win here—this would be a pretty weird requirement. I think this is the part where we disagree. I don't think you get the same effect if the DHCP server did the lookup and returned a single IP address. I realize you understand DNS better than me but DNS returns a lot more than a single IP address. In the most simple case it can be returning a list of IP so that if one server is down, the client can contact another. I don't see how to do that with single IP returned from DHCP. (yes, I realize that some people have requested DHCP options to return a list of IP). But more impotently if someone wants to do something like move the server from one data center to another, it is well understood by admins how to do that when clients access the server by FQDN. It's much harder when it's an IP address that has to be updated in DHCP servers. Not to mention opening up the use DNS tools like SRV and NAPTR. You agree that FQDN is would be a better design than IP for NTP ? No. I think the boxes that need NTP configuration via DHCP are most likely constrained devices, and that requiring them to do a DNS lookup in addition to the DHCP transaction is unnecessary. This is not really a constrained device issue - it has to do with hosts that don't have an IT administrator and need to just work. They might be constrained, but right now my house has devices doing DHCP, DNS, and HTTP all fitting in 12 k of flash, 512 bytes of ram, and an 8 bit processor at 16Mhz so don't think that DNS needs to be big - probably not fully standards compliant but it works. My house also has things like NAS, WiFI GW, TVs etc that have pretty powerful computers yet still need to turn on and just work with no administration. Probably not a hugely bad thing, but that depends on the device. A device with severe
Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
Ted, I'm trying hard to get my head around the argument you are making and obviously I am coming to the problem from a narrow point of view from the VoIP domain and I realize the WG has dealt with DHCP solutions for a wide range of solutions - but so far I'm not very convinced by this power + extra RTT when the device boots outweighs the opertational simplicity concerns of using names. I just can't think of a application or device where that extra DNS query at boot accounted for more than 0.1% of the power usage of the device. I've also received a couple private emails that I would more or less summarize as the DHCP WG is impossible on this topic, you will never convince them, just ignore the spec, it's not a MUST so just don't worry and do whatever you need to do. I really don't want to do that - if using FQDN really is the wrong choice, it sure would be nice if this draft offered a compelling argument of that. Few more comments inline…. On Oct 9, 2013, at 7:15 PM, Ted Lemon ted.le...@nominum.com wrote: On Oct 9, 2013, at 6:02 PM, Cullen Jennings flu...@iii.ca wrote: Hard coding it means you can't make your device work if you are on a network that behind a firewall that does not allow the traffic or is on a networks that is not part of the internet or is being set up for use in emergency communications where the the device is on a network say in Hati that has become partitioned from rest of network after an disaster. Obviously one can fallback to a hard coded option if no DHCP option is found but it's pretty important to have a chance of being able to configure things to work on networks with less than ideal connectivity. If this argument were correct, we'd expect to see major O.S. vendors supporting the NTP option, but we don't—instead, it's something that can be configured in the UI for situations like the one you describe, and that otherwise is defaulted to the preconfigured value, which of course can be updated when the operating system is updated. Right - I am certainly more focused on the devices that don't have an administrator that can configure them locally. So where I would expect to see the NTP option used is in devices that don't _have_ user interfaces. Your IP phone might be such a device. I suspect the bias you have toward using a DHCP option has a lot to do with where these devices are typically installed: in corporate environments. Agree I am focused on the VoIP stuff but it is both SP and enterprises. I don't even know if I could get one to use at home, or if it would work. They work in residential deployments (which might be a bit different than you mean by home) and DHCP can provide some very critical services for them. For example rfc5223 is a DHCP options that provides the LOST server that provides the mapping to locations that can be used for E911 calls and is applicable to residential. So in this environment, it certainly makes sense to use a DHCP option to do NTP service, as long as you are doing something to validate the NTP server so that you can't be trivially attacked by being fed false time information. A hardware RTC would help to sanity check the result received from the DHCP-provided NTP server, for example. Another approach is for DHCP to provide the NTP server info. I would argue that getting a FQDN of the NTP server pool is a better design for DHCP than getting an IP address because this allow DNS load balancing across the pool and allows the server IP to change over time and still not have client failures. You'd get the same effect if the DHCP server did the lookup. I agree that if you want to suddenly add an NTP server and need it to be adopted in a time frame shorter than your typical lease time, and your DNS TTL is shorter than your typical lease time, you will get better service using DNS, but there's no clear win here—this would be a pretty weird requirement. I think this is the part where we disagree. I don't think you get the same effect if the DHCP server did the lookup and returned a single IP address. I realize you understand DNS better than me but DNS returns a lot more than a single IP address. In the most simple case it can be returning a list of IP so that if one server is down, the client can contact another. I don't see how to do that with single IP returned from DHCP. (yes, I realize that some people have requested DHCP options to return a list of IP). There's nothing to disagree about. Sure I believe you about what DHCP servers are capable of doing (which I will note might be different than how they are commonly deployed). I was talking about the issue here of from a protocol design point of view, one should prefer the use of an IP address or FQDN in the DHCP option for a case like this. This is in fact how it works with most DHCP servers today: you do a DHCP transaction, the DHCP server looks up the name
Re: Last Call: draft-ietf-dhc-option-guidelines-14.txt (Guidelines for Creating New DHCPv6 Options) to Best Current Practice
(Dear OPs ADs, please read … ) I disagree with the advice in section 8. Cisco IP phones have been deployed with DHCP options that use FQDN and with options that use IP addresses. For this type of use case the FQDM turned out to be much better from an operational and administration point of view. IT departments are used to making sure that changes of IP addresses on servers are well coordinated with changes to the DNS - they are good at doing that and that and have good tools for it. Conversely, they are not used to coordinating server changes with DHCP changes and do not have good tools for that. Part of why you can't do this with DHCP is that clients are written so that when an IP address fails to work for an application connection, the application re does the DNS and gets the new address (assuming TTL had been moved down during the move). Applications can not tell the OS to redo DHCP when they fail an application level connection. For nearly every case in the real world, the power and RTT and reliability issues are simply not relevant - regardless of which way you do it, the application is unlikely to work if DNS is down, the extra RTT make no speed difference the user can percieve and the power difference over a day of use of the application is so small it is not measurable. FQDN allow usage of things like DNS SRV for load balancing, happy eye balls for v6 transition, and make it easier to get things to geographically close servers. I don't think it should come a a shock to anyone that the level of indirection that FQDNs provides turns out to be a really useful tool. Lets use that indirection tool where appropriate. Related to this, the advice in section 12 seems a bit off to me. I understand the issues - but keep in mind that many modern applications (browsers and SIP phones for example) do the DNS inside the application instead of using the OS resolvers. Part of the reason for this is asynchronous resolution but part of it is also control of which interface is used for DNS and if multiple interfaces are used, being able to keep the applications traffic on the the appropriate interface for the DNS server that returned the address. So while I agree that Existing nodes cannot be assumed to systematically segregate configuration information on the basis of its source; Equally true is you can't assume the converse of that. So I think the statement that As a consequence, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multi- homed client. Is just plain wrong. I think it would be more accurate to say in these cases the results are not always predictable. The issue is the DHCP server may get an DNS answer that contains and server that can not even be reached by the DHCP client. As a general rule of thumb, using FQDN in the configuration of a DHCP server is a really bad idea because IT admins assume that if they change the the DNS information, the clients will get the new information. But they don't. Cullen On Sep 19, 2013, at 3:54 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Guidelines for Creating New DHCPv6 Options' draft-ietf-dhc-option-guidelines-14.txt as Best Current Practice 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 2013-10-03. 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. Abstract This document provides guidance to prospective DHCPv6 Option developers to help them creating option formats that are easily adoptable by existing DHCPv6 software. This document updates RFC3315. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-option-guidelines/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: WG Review: Secure Telephone Identity Revisited (stir)
This looks reasonable to me and given how much effort it has taken to get agreement on theses words, I am not keen on any of the material changes I have seen proposed. On Aug 21, 2013, at 11:52 AM, The IESG iesg-secret...@ietf.org wrote: A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2013-08-28. Secure Telephone Identity Revisited (stir) Current Status: Proposed WG Chairs: TBD Assigned Area Director: Richard Barnes r...@ipv.sx Mailing list Address: s...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/stir Archive: http://www.ietf.org/mail-archive/web/stir/ Charter: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call. Since it has become fairly easy to present an incorrect source telephone number, a growing set of problems have emerged over the last decade. As with email, the claimed source identity of a SIP request is not verified, permitting unauthorized use of the source identity as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). In addition, use of an incorrect source telephone number facilitates wire fraud or can lead to a return call at premium rates. SIP is one of the main VoIP technologies used by parties that want to present an incorrect origin, in this context an origin telephone number. Several previous efforts have tried to secure the origins of SIP communications, including RFC 3325, RFC 4474, and the VIPR working group. To date, however, true validation of the source of SIP calls has not seen any appreciable deployment. Several factors contributed to this lack of success, including: failure of the problem to be seen as critical at the time; lack of any technical means of producing a proof of authorization to use telephone numbers; misalignment of the mechanisms proposed by RFC 4474 with the complex deployment environment that has emerged for SIP; lack of end-to-end SIP session establishment; and inherent operational problems with a transitive trust model. To make deployment of this solution more likely, consideration must be given to latency, real-time performance, computational overhead, and administrative overhead for the legitimate call source and all verifiers. As its priority mechanism work item, the working group will specify a SIP header-based mechanism for verification that the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation. The working group will consider choices for protecting identity information and credentials used. This protection will likely be based on a digital signature mechanism that covers a set of information in the SIP header fields, and verification will employ a credential that contains the public key that is associated with the one or more telephone numbers. Credentials used with this mechanism will be derived from existing telephone number assignment and delegation models. That is, when a telephone number or range of telephone numbers is delegated to an entity, relevant credentials will be generated (or modified) to reflect such delegation. The mechanism must allow a telephone number holder to further delegate and revoke use of a telephone number without compromising the global delegation scheme. In addition to its priority mechanism work item, the working group will consider a mechanism for verification of the originator during session establishment in an environment with one or more non-SIP hops, most likely requiring an out-of-band authorization mechanism. However, the in-band and the out-of-band mechanisms should share as much in common as possible, especially the credentials. The in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism. Expansion of the authorization mechanism to identities using the user@domain form is out of scope. The work of this group is limited to developing a solution for telephone numbers. The working
Re: [payload] Last Call: draft-ietf-payload-vp8-08.txt (RTP Payload Format for VP8 Video) to Proposed Standard
So do you expect your implementations on devices with hardware acceleration to have any limits on resolution of images they can decode? I can't imagine how I could implement the frame buffers in VP8 in VLSI without having an upper limit on both the width and height of the image. How do you deal with that? I don't know if you ever got the Google VHDL code for VP8 but I have never got it so I don't know what it does but if you do, that would be great. On Jul 24, 2013, at 12:57 PM, Timothy B. Terriberry tterr...@xiph.org wrote: Cullen Jennings (fluffy) wrote: There is one thing that as far as I can tell that all the implementors agree on. None of the implications control the resolution using m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=fmtp:96 max-fr=30;max-fs=3600 What resolution do you think max-fs=3600 is? I have no idea. It is not possible to implement so it is not surprising no one is doing it. However, this draft-ietf-payload-vp8 draft says the resolution is specified using the max-fs and max-fr. I can't speak for other implementations, but here at Mozilla, our interpretation of RFC 6236 was that the values specified in imageattr can be completely ignored by either side, if they so choose. That leaves max-fs and max-fr as the only mechanism to indicate a resource constraint that cannot be ignored, and we plan to use it as such. See https://bugzilla.mozilla.org/show_bug.cgi?id=881935 for details. ___ payload mailing list payl...@ietf.org https://www.ietf.org/mailman/listinfo/payload
Re: [payload] Last Call: draft-ietf-payload-vp8-08.txt (RTP Payload Format for VP8 Video) to Proposed Standard
Resent on different list … I would like to raise an issue interoperability with this payload specification that we are currently having with WebRTC implementations. In WebRTC, and many other places, you want SDP to be able to control the resolution of the image (or at least the outer limits of the resolution). Yes, I realize there are applications where you know the resolution vis a some out of band mechanisms but O/A SDP is not one of the where this is guaranteed. We do need to specify how this works for use with O/A SDP. Some implementations think that if you want the resolution to by 720 lines by 1280, you control the resolution of codec with a SDP line something like m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=ssrc:5 imageattr:* [1280, 720] Some other implementers think you control the resolution using RFC 6236 with something like m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=imageattr:96 [x=1280,y=720] There is one thing that as far as I can tell that all the implementors agree on. None of the implications control the resolution using m=video 62537 RTP/SAVPF 96 a=rtpmap:96 VP8/9 a=fmtp:96 max-fr=30;max-fs=3600 What resolution do you think max-fs=3600 is? I have no idea. It is not possible to implement so it is not surprising no one is doing it. However, this draft-ietf-payload-vp8 draft says the resolution is specified using the max-fs and max-fr. I raised this in the WG and the WG came to consensus that current draft is fine. So I actually believe that current draft does represent IETF consensus and that I was merely in the rough on that consensus. I had decided to just ignore it in LC because I was under the impressing that all the implementations would just ignore the RFC and do a=imageattr:96 [x=1280,y=720]. However, when it came to my attention that many were doing a=imageattr:96 [x=1280,y=720] but some where doing the non interoperable a=ssrc:5 imageattr:* [1280, 720], I decided that this problem actually needed to be fixed. I think this draft is broken and will create interoperability problems for years to come. I encourage the IESG to fix it. I don't care how it is resolved, I care that there is a way to for O/A to sort out the resolution and since the approach used be SDP to do this is codec specific, it needs to be in this draft. Cullen On Jun 4, 2013, at 3:25 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for VP8 Video' draft-ietf-payload-vp8-08.txt as Proposed Standard 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 2013-06-18. 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. Abstract This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-vp8/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1622/ ___ payload mailing list payl...@ietf.org https://www.ietf.org/mailman/listinfo/payload
Re: The Nominating Committee Process: Eligibility
I have attended some IETF meetings remotely and I am not in favor of this change. On Jun 27, 2013, at 5:50 AM, S Moonesamy sm+i...@elandsys.com wrote: Hello, RFC 3777 specifies the process by which members of the Internet Architecture Board, Internet Engineering Steering Group and IETF Administrative Oversight Committee are selected, confirmed, and recalled. draft-moonesamy-nomcom-eligibility proposes an update RFC 3777 to allow remote contributors to the IETF Standards Process to be eligible to serve on NomCom and sign a Recall petition ( http://tools.ietf.org/html/draft-moonesamy-nomcom-eligibility-00 ). Could you please read the draft and comment? Regards, S. Moonesamy
Re: call for ideas: tail-heavy IETF process
Few thoughts. 1) don't get wrapped around the axel of STD, PS, Foo bar label, it has nothing to do with the problem that that IESG believes many drafts need changes to fix significant problems. Lots of people imply that the IESG is setting the bar too high but when you look at the changes that are made to drafts from point they go in, to point they come out of IESG it seems to be a rare example where people don't agree that major changes were an improvement and needed. 2) On the point of what the IESG should be doing, I would like to see the whole IESG say they agree with the Discuss Criteria document and will stay within that (or change it if they disagree). The cross area review teams might want to also provide comments within this context. 3) Require each pub request from a WG to come with names of 3 nom com eligible people that are willing to say I have carefully reviewed this draft and I believe it is ready to be published as an RFC. If a WG can't find 3 people to do this, it should probably be closed. You might consider something similar for AD sponsored drafts but I am more interested in the WG ones. 4) Get the ADs involved earlier. My experience is that many ADs won't say much because they are worried that they would be over influencing the WG. ADs got the job because we think they are the right people to provide influence and obviously it would be better to get that early rather than late. 5) Given how long a WG takes, I have no problem with time IESG / RFCEd takes. I would suggest mitigating this concern by clearly telling the community that if there were a spec that truly needed to be fast tracked for some real reason, you would make it priority. And on the rare occasion that is needed, do it and track the stats for fast track separately. I would guess that less than 1 in 100 needs this and you could do theses with delays in the small numbers of weeks instead of months. How fast you can move when really needed is more important to me than the average and I know that the IESG/IANA/RFCEd team works well in parallel and can move fast when needed. 6) Over the long term, set up the tools to separately track IESG / RFCEd time where the ball is in the authors court. 7) Remember that in the end, the goal is not a standard. The goal is an feature rich interopeable internet that is a fertile ground for inovation. High quality and relevant standards that think about the future are the way to get there. The goal is not to publish lots of specification that aren't used and don't work. Cullen On May 1, 2013, at 9:33 AM, Jari Arkko jari.ar...@piuha.net wrote: I wrote a blog article about how we do a fairly significant amount of reviews and changes in the late stages of the IETF process. Next week the IESG will be having a retreat in Dublin, Ireland. As we brought this topic to our agenda, Pete and I wanted to raise the issue here and call for feedback ideas for improving the situation with all of you. http://www.ietf.org/blog/2013/05/balancing-the-process/ Jari
Re: call for ideas: tail-heavy IETF process
inline On May 14, 2013, at 10:34 AM, Ted Lemon ted.le...@nominum.com wrote: On May 14, 2013, at 9:58 AM, Cullen Jennings (fluffy) flu...@cisco.com wrote: 2) On the point of what the IESG should be doing, I would like to see the whole IESG say they agree with the Discuss Criteria document and will stay within that (or change it if they disagree). The cross area review teams might want to also provide comments within this context. I am not entirely convinced that the DISCUSS criteria are complete. agree but I like and think they help even thought they are not complete There are some rules in the criteria that are intended to curb abuse, and that I think do have that effect, but that also would make some very appropriate DISCUSSes fail to meet the criteria. If you could give some examples of DISCUSSes that you think are reasonable but fail to meet the criteria, it would be really great if you could provide some examples of that as I think it would help refine DISCUSS criteria. I think everyone agrees there could be things in that category but - that was part of the reason DISCUSS criteria did not end up as a BCP. I don't really know how to address that problem. The IESG needs to keep using common sense and keep doing the right thing. I'm happy that the IESG deal with the unexpected. E.g. the rule about not coming up with new DISCUSSes: if a DISCUSS winds opening up a can of worms, it ought to be possible to enlarge the DISCUSS, but I think that the rule about not adding new DISCUSSes after the first DISCUSS tends to forbid that, and the reason given is a good one. Having said that, I don't think the right answer is to ignore that requirement. I don't actually have a good answer. I think the IESG has generally followed a good path of not adding new things, and at the same time if some huge problem was found later, still dealing with it. A long time ago it was hard to know when the IESG might actually finish review, that is not longer a problem but I don't want to go back to it being a problem. It's worth noting that ADs are not omniscient, and hence the DISCUSS criteria apply to what the AD entering the DISCUSS _knows_, not to the full state of all knowledge in the world. Of course and that is part of why the name DISCUSS. The AD wants to DISCUSS it with people and improve their knowledge of state of work and what happened in WG and why it is the way it is and resolve it. I'm perfectly happy with DISCUSSes being resolved with once it got explained to me, I see it is not a problem and cleared. If someone other than the AD has knowledge that they think means that the DISCUSS doesn't meet the criteria, that doesn't mean the DISCUSS doesn't mean the criteria. In this case, the critic needs to communicate it to the AD, who may or may not agree with the critic's point of view. This is not to say that it's never correct to say this doesn't meet the DISCUSS criteria. But the reason given should be that it would be obvious to anyone reading the DISCUSS that it didn't meet the criteria. Sure but as everyone knowledge increases, I'd expect that AD would update the DISCUSS or remove it if it becomes clear it is not longer relevant. My experience has been IESG does do this. The critic's expert knowledge can't be given as a reason. I have also noticed that some authors have the impression that a DISCUSS means the AD doesn't like the document, or doesn't want the document to advance, or is a non-negotiable pronouncement from on high that the authors should not question. This is certainly not my motivation when I enter a DISCUSS. I'm just some guy who got nominated by the nomcom. Hopefully I'm qualified, but I don't claim to be right. I have seen DISCUSSes I've raised improve documents, and I've seen DISCUSSes I've raised turn out not to require any change, but just some discussion to clear up a misunderstanding on my part. I very much hope that in the latter case, the author will argue back, and not just make a change to shut me up! +1 to that. The reason I raise a DISCUSS rather than a comment is that at the time I'm writing the DISCUSS, it appears _to me_ to be the case that there is a problem that ought to be addressed before the document is published. I may think it's generally a great document, but I want the concern I've raised to be addressed before it moves forward. That is _all_ a DISCUSS from me means. If I think the document is an irretrievably bad idea, I will abstain, and say why I think so. Again, +1 to that and my experience is most the IESG feels the same way. Thanks for sending your email. I think it help people understand how ADs think about DISCUSSes.
Re: IPR view (Re: Internet Draft Final Submission Cut-Off Today )
On Mar 10, 2013, at 10:15 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 10/03/2013 14:35, Scott Brim wrote: On 03/10/13 09:12, Brian Trammell allegedly wrote: Solve it with better management, not artificial barriers that are imposed on everyone and that can be trivially routed around, albeit without the benefits of using the I-D mechanism. This seems like something that could be left to the discretion of the chairs on setting the agenda for each WG meeting, as long as there's transparency in the criteria that will be used to decide whether a recently-submitted draft can be discussed on the agenda. Yes, place the decision in the WGs. Once upon a time in a WG far away we did say You can submit drafts and discuss them on the mailing list any time you want, but the agenda for the meeting will be set two weeks in advance. Please don't. Currently we receive a flood of a few hundred drafts two weeks before each meeting, which gives time for some triage. I do not wish to receive a few hundred drafts on the first day of the meeting, with no time for triage, but that would be the inevitable end-point if the deadline was abolished. (Unless there has been an unannounced change in human nature, of course.) Brian +1
Re: Diversity of IETF Leadership
I am glad to see the IETF beginning to have this conversation about diversity. I am concerned that, as an organization, we avoid becoming locked into entrenched, polarizing positions, though. Some of us will take the view that qualified people may not be taking on, or may not be selected to fill, positions of authority within IETF because of structural barriers within the organization. Some qualified people may feel that they personally don't belong, in social terms, or they may be excluded because of economic costs that are greater than they can bear. On the other hand, other members may insist that individuals make their own choices, and that those who currently hold the various positions work very hard and make a range of sacrifices and compromises in order to meet the requirements of the offices. If we look at other organizations that have wrestled with diversity issues, we will see that many people argue that such initiatives may result in less qualified people, and people whose interest is in diversity rather than in technology, making it into positions of authority. Some members of our organization will therefore be concerned that technical decision-making will suffer and that the people who really care about the technical decisions will end up bearing even more of the organization's workload than they already do. Somehow we have to come up with an approach that fosters bringing in the talents of those who may currently be overlooked but also continues to put the organization's mandate first. Our goal as an organization must be to make sure that we are, in fact, welcoming and accessible, so that people who are deeply interested in the technological issues can and will take on an active role and move into positions of authority. The question is how to do this. I think we must first understand our own position within the larger social context. There has been a recession, which has hit some parts of the world harder than others and has hit different industries and industry players differently. A couple of years ago, the San Jose Mercury News reported that the workforce in Silicon Valley had in some respects become less diverse in the previous eight years (http://www.mercurynews.com/ci_14383730). The New York Times reported, around the same time, that women seemed not to be graduating in computer science in as large numbers as they had 15 or 20 years ago (http://www.nytimes.com/2008/11/16/business/16digi.html?_r=1;). It may therefore be the case that in part, membership in our organization is reflecting wider trends. On the other hand, general trends ought not to cause us to stick our heads in the sand and refuse even to examine the issue. We should also consider that increased diversity could come through different pathways: we could increase our international membership, or we could increase the racial and gender diversity of our North American and European membership. It may even be that if we increase our international membership, the percentage of women in our organization may decline, since it may be that women computer scientists and engineers are even rarer outside North America and Europe. I say may because I don't know the statistics, but I do think that expanding our reach into the world may lead to results we don't expect as well as results we do. One key aspect of our considerations, I think, has to be the broad question of how we draw new people into the organization. Attending the conferences has to be important. If there are barriers to attendance, those barriers would need to be considered. We should think about where we hold our conferences, how long it takes to get to them, how much it costs to participate, and whether we make it possible to be really involved remotely. We should minimize travel time and the cost of travel, in both money and time. Maybe we should think about some mechanism for subsidizing people who travel long distances, especially if they don't work for big companies. Maybe we should offer daycare. It would seem to me that there would be something to be said for looking very carefully at the processes for choosing venues and setting attendance costs. We should meet in different parts of the world. We should not treat meeting in Vancouver or Hawaii as equivalent to meeting in Asia. We should plan our meetings with the dual goal of increasing our attractiveness to new members and minimizing the commitment of time and money for existing members, because these are the goals that we seek to achieve through our meetings that are most important for our organization as a whole. Once we have qualified people involved in IETF, we want to draw them into greater roles within the organization. There are serious structural problems here, though. Being seriously involved requires volunteering many hours every week or month - sometimes almost the equivalent of a full-time job. We have to understand that most
Re: Last Call: draft-farrell-ft-03.txt (A Fast-Track way to RFC with Running Code) to Experimental RFC
My read of this draft is that it eliminates the need for rough consensus at both the WG and IETF level. Basically the WG chair can just decide and even if the WG disagrees with the chair. If the WG does not have consensus in WGLC that they they do want to publish the draft, it still gets published. I realize from the email list discussions this may not be what the author of the draft intended but it is how I read this draft. Because of this, I am against approving this and also believe it would need to be BCP not experimental as it changes the fundamental process to approve PS drafts. The rest of this draft, the part about overlapping, is already allowed by the process today as the draft points out. The WGLC is not required at all, the AD processing and IETF LC can overlap. However, I think that the AD should do their processing before they LC the draft because that means they check it is ready before wasting the IESG and everyone else's time revving a document. AD processing can often be done in a few hours or less if the draft is ready. Generally, WGLC avoids late surprises which take more time in the long run but all of this is a general guideline and there are cases where it make sense to overlap all this and put it through. Thus I think it is good that the current process allows this to all be overlapped at the chair and AD discretion. I encourage the AD Chairs to overlap where they think it will 1) is appropriate 2) will speed things up and 3) the speed up actually helps the internet or some groups of users in a meaningful way. I'm certainly not against some chairs, ADs, etc trying to put a draft throughout quickly that they think is ready (running code or not) but I don't see the need for this change to the process. I also have a question for the each IESG member that I think is very relevant - Do all of you agree to only put discussed that meet the Discuss Criteria this draft refers too? I really hope you do. If you don't that raises even more issues for how this draft changes the process. Cullen On Jan 11, 2013, at 8:14 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual submitter to consider the following document: - 'A Fast-Track way to RFC with Running Code' draft-farrell-ft-03.txt as 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 2013-02-08. 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. Abstract This memo describes an optional, fast-track way to progress a working group document to IESG review. It is provided as a process experiment as defined in RFC 3933 for use when working group chairs believe that there is running code that implements a working group Internet-Draft. The motivation is to have the IETF process explicitly consider running code, consistent with the IETF's overall philosophy of running code and rough consensus. In this process all of working group last call, IETF last call, and Area Director review are carried out in the same two week period. Only comments that meet IESG Discuss criteria need to be addressed during this stage, and authors are required to make any changes within two weeks. This experiment will run for one year. The file can be obtained via http://datatracker.ietf.org/doc/draft-farrell-ft/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-farrell-ft/ballot/ No IPR declarations have been submitted directly on this I-D.
Re: copyright notices in RFC 6716
I was only peripherally involved in this and don't know all the in's and outs of this but let me try and provide a bit of information and hopefully someone from the IETF Trust or RFC Editor can correct me where I am wrong. The internet draft was done with the normal boiler plate that granted a bunch of rights to the IETF Trust. There was also text in the draft where the authors granted additional rights. The trust normally publishes the RFC with about the same license that is used in the draft however the Trust retains the rights to do whatever they want within the range of the license granted to them in the draft. In this case, the RFC was published with slightly different boiler plate than what was in draft. So no, I don't think the policy has changed, and no I don't think this was a mistake. I think the RFC Editor working with the IETF Trust and IETF legal advice made this change. My understanding of the reasons for the change was something like this makes it easier for some linux distribution to include the RFC with their distribution or something. Keep in mind this is a weird RFC in that it includes a huge amount of normative code in the RFC. Hope this helps - and amazed anyone noticed. Cullen PS - I may have this all wrong - I'm not the person that knows but I hope that provides some help. On Sep 13, 2012, at 8:18 AM, Simon Josefsson si...@josefsson.org wrote: All, I noticed that the recent RFC 6716 contains some reference code that contain the copyright and licenses notice reproduced below. The IETF TLP [1] mandates a certain form of copyright notices and the TLP does not, as far as I can see, permit varying the boiler plate in any way. Note that both companies and organisations are mentioned in the copyright notice in RFC 6716, besides individuals. Does this indicate a policy change, a mistake with that document, or something else? Btw, kudos to the RFC 6716 authors for shipping reference code! I hope this will establish a best practice for standards in the future. /Simon [1] http://trustee.ietf.org/license-info/IETF-Trust-License-Policy-20091228.htm Copyright 1994-2011 IETF Trust, Xiph.Org, Skype Limited, Octasic, Jean-Marc Valin, Timothy B. Terriberry, CSIRO, Gregory Maxwell, Mark Borgerding, Erik de Castro Lopo. All rights reserved. This file is extracted from RFC6716. Please see that RFC for additional information. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I like the whole and +1 to it. I can see the pros and cons of make drafts actually go away but given it is impossible to get rid of a draft from the internet, all we end up with in the current situation are the cons and none of the pros. I do have one suggested change OLD An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. NEW The IETF Chair may decide to removed an I-D from the public I-D archive. We have better things to do than argue which courts we might accept court orders from or what a court order is so I suggest we just let the chair do the right thing. The chair will understand the goals of the IETF and have legal advice available to them. If the wrong thing happens, we can fix it after the fact by putting the ID back. On Sep 3, 2012, at 6:00 PM, IETF Chair ch...@ietf.org wrote: The IESG is considering this IESG Statement. Comments from the community are solicited. On behalf of the IESG, Russ --- DRAFT IESG STATEMENT --- SUBJECT: Removal of an Internet-Draft from the IETF Web Site Internet-Drafts (I-Ds) are working documents of the IETF, its Areas, and its Working Groups. In addition, other groups, including the IAB and the IRTF Research Groups, distribute working documents as I-Ds. I-Ds are stored in two places on the IETF web site. First, current ones are stored in the I-D directory. Second, current and past ones are stored in a public I-D archive. I-Ds are readily available to a wide audience from the IETF I-D directory. This availability facilitates informal review, comment, and revision. While entries in the I-D directory are subject to change or removal at any time, I-Ds generally remain publicly archived to support easy comparison with previous versions. Entries in the I-D directory are removed as part of normal process when it expires after six months, when it is replaced by a subsequent I-D, or when it is replaced by the publication of an RFC. In all of these situations, the I-D remains in the public I-D archive. An I-D will only be removed from the public I-D archive in compliance with a duly authorized court order. If possible, a removed I-D will be replaced with a tombstone file that describes the reason that the I-D was removed from the public I-D archive.
[ietf-privacy] Comments on draft-iab-privacy-considerations-03
I note this is information and not BCP and comments are sent in that context. Overall I like this - particularly section 6 which if far more actionable than many things I have read in the privacy space. Few comments ... Should this explicitly mention the example of communication from women's shelters - I find this example a good one for thinking about many privacy problems. I realize that everyones time is limited, but it someone got motivated to provide a second example, I think OAuth would make a great example. Small comments …. In A natural person. the word natural seems really weird.Would A human be better? The definition of Personal Data: Any information relating to an identified individual or an individual who can be identified, directly or indirectly. made me read it several times before I got it. Does it mean Any information relating to an individual who can be identified, directly or indirectly. Might want to add anonymity set to section 3.1 Typo intermediairies should be intermediaries ? ___ ietf-privacy mailing list ietf-privacy@ietf.org https://www.ietf.org/mailman/listinfo/ietf-privacy
Re: WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave)
WIll the IPFIX and MIB work also be usable by v4 to v4 NATs? On May 15, 2012, at 11:53 AM, IESG Secretary wrote: A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, May 22, 2012. Behavior Engineering for Hindrance Avoidance (behave) - Current Status: Active Last updated: 2012-05-10 Chairs: Dan Wing dw...@cisco.com Dave Thaler dtha...@microsoft.com Transport Area Directors: Wesley Eddy w...@mti-systems.com Martin Stiemerling martin.stiemerl...@neclab.eu Transport Area Advisor: Wesley Eddy w...@mti-systems.com Mailing Lists: General Discussion: beh...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive:http://www.ietf.org/mail-archive/web/behave Description of Working Group The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. An IPv4 network or an IPv6 network in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network to an IPv4 network, and (4) an IPv4 network to an IPv6 network. Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible. In addition, when a NAT (such as a NAT64 in the An IPv6 network to IPv4 Internet scenario) serves multiple subscribers, inter-subscriber fairness issues arise. As such, BEHAVE will complete its work on Carrier Grade NAT requirements for such scenarios, and update the NAT MIB as needed to meet such requirements. BEHAVE will not, however, standardize IPv4-specific behavioral mechanisms. The following scenarios remain in scope for discussion, but will not be solved by BEHAVE: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. This group will also provide reviews of any work by the MBoneD WG on multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). If the WG deems it necessary, BEHAVE will revise RFCs previously published by BEHAVE. Goals and Milestones Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requirements for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Done Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: relaying of a TCP bytestream (std) Done Submit to IESG: relay protocol
Re: [Gen-art] Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)
I think the authors just about have a -14 draft ready but I wanted to comment on one topic inline On May 16, 2012, at 3:26 PM, Elwyn Davies wrote: Hi, Jean-Marc. ... and thanks for the super-quick response! You have been quite busy. I have had a look through the new draft and I think the additions help considerably with comprehension for the naive (and to give new implementers a way in.) I'll leave you to negotiate with the RFC Editor over the Wikipaedia references. To quote the RFC Style guide http://www.rfc-editor.org/rfc-style-guide/rfc-style Section 4.8, item (x) References, last section: URLs and DNS names in RFCs The use of URLs in RFCs is discouraged, because many URLs are not stable references. Exceptions may be made for normative references in those cases where the URL is demonstrably the most stable reference available. References to long-lived files on ietf.org and rfc-editor.org are generally acceptable. They are certainly convenient *as long as they remain in place and aren't corrupted*. I found a couple of trivial editorial nits in the changes: s4.3.3 (in the added text): The CELT layer, however, can adapt over a very wide range of rates, and thus has a large number of codebooks sizes s/codebooks/codebook/ s4.3.3, para after Table 57: s?the maximums in bit/sample are precomputed?the maximums in bits/sample are precomputed? Also suggest: s4.3: Add reference for Bark scale: Zwicker, E. (1961), Subdivision of the audible frequency range into critical bands, The Journal of the Acoustical Society of America, 33, Feb., 1961. A few responses in line below (agreed pieces elided): Regards, Elwyn Davies On Tue, 2012-05-15 at 20:33 -0400, Jean-Marc Valin wrote: Hi Elwyn, Thanks for the very thorough review. We've addressed your issues and submitted draft version -13. See our response to each of the issues you raised (aggregated from all the authors) in the attached document. Thanks very much to all the authors. Cheers, Jean-Marc Elwyn Davies wrote: Major issues: Can we accept the code as normative? If not how do we proceed? The issue with code being normative was specifically addressed in the guidelines document for this WG (RFC 6569). Yes. I failed to read this although Robert Sparks did point out to me that the code was normative - but he didn't think he said this was agreed in advance (or maybe I didn't understand what he was saying). To be honest I would like to have had the time to tie the text to the code but realistically that is several weeks or even months work to do it properly - without that I feel that I have only done half a job. I may decide that it interests me enough to have a superficial go next week but no promises! Minor issues: Contrast between decoder descriptions of LP part and CELT part: The SILK descriptions go into gory detail on the values used in lots of tables, etc., whereas the CELT part has a very limited treatment of the numeric values used (assuming reliance on finding the values in the reference implementation, either explictly or implicitly). There are things to be said for both techniques. I was wondering (while reading the SILK description) if the authors have any means of automatically generating the tables from the code in the SILK part (or vice versa) to avoid double maintenance. On the other hand, there are pieces of the CELT decoder description (especially in s4.3.3 where knowing numbers of bands, etc.) where some actual numbers would help comprehension. We have made many changes to section 4.3 (and 4.3.3 specifically) to address the specific issues below. As for the tables, they are not generated automatically. I think this is addressed satisfactorily now. There is still some difference but it is much reduced and not so glaring now. The addition of the band tables really helps. s2 (and more generally): The splitting of the signal in the frequency domain into signal (components?) below and above 8kHz presumably requires that the signal is subjected to a Discrete Fourier Transform to allow the signal to be split. I think sometging is needed in s2 to explain how this is managed (or if I don't understand, to explain why it isn't necessary). No DFT is used. The lower band is obtained through resampling (which is already described) and the higher band is obtained by not coding the lower band with CELT (the text says that CELT starts at band 17 in hybrid mode). The explanation was reworded to make this as clear as possible at this point in the text. [I thought I had reworded this comment in the 2nd version to talk about MDCT but no matter]. Yes, para 5 of s2 does say that the bands are discarded. I think it would useful to have a concrete statement in the new text added to
Re: Gen-art last call review of draft-ietf-codec-opus-12.txt (completed)
Thank you kindly for the detailed review. More inline ... On May 14, 2012, at 9:06 AM, Elwyn Davies wrote: Summary: Before offering some views on the document, let me say that this piece of work seems to be a tour de force on behalf of its developers. It is certainly one of the (if not the) most technically complex pieces of work that has been presented to the IETF, And I would like to say thank you for the detailed review - having read the whole draft several times, I know that ones eyes can start to glaze over on what seems like something almost as long as the NFS spec ... so thanks for the review. I did want to comment on the one major issues Major issues: Can we accept the code as normative? If not how do we proceed? RFC 6569 says that the code needs to be the normative specification so I think this issues is pretty much resolved by that RFC. As a bit of irrelevant history - this topic was discussed at various stages. If was discussed in the chartering process - draft-valin-codec-guidelines referred to by the charter said code would be normative. I don't mean by this that the charter said the code had to be normative but just that this conversation goes back to before the WG was formed. It was later discussed in the WG and resulted in WG consensus to having the code as normative. Just as background on a few of the reasons that this was decided this way, many people felt that the spec would be much longer, and much harder to implement or review if the text was normative. Code is a very compact representation of what happens on boundary edge conditions and eliminates many types of misinterpretations. I do understand normative code introduces other types of issues but it is a fairly common practice in specifying codecs to use normative code. Cullen Codec Co-Chair
Re: Adequate time to review all WG documents
+1 I also wonder how the ADs manage to read the documents for their own WGs when the agendas are this late. It's a lot of reading. On Nov 7, 2011, at 11:24 PM, SM wrote: Hello, Since it is important that working group members have adequate time to review all documents, it would be good if relevant WG documents are made available at least two weeks before the start of the WG session. Could the IESG please do something so that participants have adequate time to review such documents? The following WGs have not published any agenda yet: 1. RADEXT 2. SOFTWIRE 3. OPSEC 4. CUSS cuss - got canceled 5. FORCES 6. TSVWG 7. OPSAWG 8. IDR 9. PPSP 10. PKIX 11. REPUTE (new WG) 12. MBONED 13. CONEX 14. TICTOC 15. ANCP 16. GROW 17. LISP 18. MULTRANS (BoF) 19. KRB-WG Will the above sessions, excluding exceptional cases, be cancelled? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
On Oct 23, 2011, at 10:19 AM, Melinda Shore wrote: On 10/22/11 10:26 PM, Dave CROCKER wrote: So the question is how to move the center of gravity back to mailing lists? In all honesty I'd say that the largest source of this problem is working group chairs, both for using meetings as deadline anchors and for doing a really crappy job managing remote participation during meetings (and thereby increasing the need to be there in person). A few do an outstanding job, a few don't even try, and most are somewhere in the middle. It may be worth doing a wg chairs training session on this topic during an upcoming meeting. Melinda I understand your point about using the meetings as an anchor but want to dig into the managing remote participation during IETF meetings better. Can you give an example of chairs that do it well and what is it they do? Then perhaps contrast with what it is that chairs that do it poorly are doing. Feel free to use me as an example of a chair that does it poorly - I have no idea how to do it so it works at all much less works well. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
The problem is that many of the things that make a meeting better for remote people, make it worse for local people. You can see that even in IETF meetings today - the virtual interim meetings were everyone is remote is a much better experience for remote people than meetings where lots of people are local in one room and some of the people are remote. To make any serious progress on this, I suspect we will have to discuss the trade offs of how a WG best makes progress vs fairness to people that don't/can't come. Note that depending on if you think I should have used don't or can't come in the previous sentences already highly biases the question. On Oct 23, 2011, at 11:01 AM, Stephen Farrell wrote: I'm not sure I'd blame chairs so much, but anyway... Here's a suggestion - create a list for people who are active IETF participants but who miss a lot of meetings. (And ask people who don't match that profile, like me, to stay out of the discussion - we can read the archive if we're curious.) Let folks on that list see if they can figure out things to do that they think would make things better then bring that back here. I'm not claiming this'd fix the problem, but I'd be interested in the output and it'd avoid most of the discussion about remote attendee things being discussed by the usual suspects who do in fact go to most meetings afaics. S. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Requirement to go to meetings
On Oct 23, 2011, at 12:02 PM, Melinda Shore wrote: On 10/23/11 8:59 AM, Cullen Jennings wrote: Can you give an example of chairs that do it well and what is it they do? Then perhaps contrast with what it is that chairs that do it poorly are doing. Feel free to use me as an example of a chair that does it poorly - I have no idea how to do it so it works at all much less works well. It's really not that big a deal. Make sure that audio is working, that there's a Jabber scribe/Jabber room watcher and liaison-y sort of person, and that remote participants are pinged regularly (and *always* before a change of topic). Decision questions should go out to the list as soon as possible, if not sooner. Make sure that questions in the room and other discussion are audible to remote folk. I'm unconvinced that having video would improve anything and while something like whiteboarding might be useful in some cases I don't think it would be used much. [As an aside I hope that the RFP process doesn't result in a fancy pile of technology that looks whizzy but doesn't actually improve meetings - I find that the current stuff works well when the chairs are thinking about remote participants] There have been a few sessions where audio wasn't working and there was nobody in the Jabber room who was in the session and could relay that information. One particularly badly-run session had the chairs completely ignoring remote participants during the entire meeting and then asking for volunteers, explicitly limiting it to people in the room even though it was longer-term work. (I wrote to the chairs and ADs after that one and never heard back from anyone). I really don't think it's that much effort and I don't think it's disruptive, but I do think it requires of chairs a somewhat different mental model of a meeting. Melinda Ah, OK ... that sounds achievable - I certainly hope most WG these days are doing that. (and Stephen, agree with your point good to hear from people that don't god) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 support in hotel contract?
We just failed to manager to find a venue in Asia because there was no venue that meant all the constraints. I'd rather not add more constraints to the hotel selection. I love the taste of dog food, but v6 in the hotel is not something that I find critical to accomplish the task I come to IETF to get done. On Oct 20, 2011, at 7:01 AM, George, Wes wrote: My last message caused something else to occur to me – there has been a lot of discussion both here and at NANOG about hotels being woefully underprepared for the internet (and address) use that their guests generate when a conference full of geeks and their multiple devices per person descend upon them. Sometimes the IETF is successful at convincing the hotel to let them take over the internet service in the guest rooms, sometimes not. Perhaps we can kill two birds with one stone by starting to require IPv6 service in the guest rooms when we enter into negotiations with hotels. If they don’t have it, we’ll be happy to temporarily take over the internet service, or assist them in getting it enabled permanently in their existing network, and if neither of those options are acceptable, it provides negotiating leverage on other things. This also has the net effect of starting to make it clear to hotel management that IPv6 is going to start being mandatory for some subset of their guests before too much longer. I realize that having something in the contract doesn’t mean that we’re any more likely to get it. But the fact that it’s in the contract makes a statement in and of itself. IAOC, any reason why this couldn’t be added, especially given how far in advance you’re negotiating with venues? Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review of draft-ietf-nfsv4-federated-dns-srv-namespace
On Sep 12, 2011, at 1:00 PM, Robert Thurlow wrote: Joe Touch wrote: Either this is an nfs service or it isn't. If it is, then it should be using _nfs._tcp.example.com, etc. If it isn't, then: a) a new service name is required which then *requires* b) a new port number be assigned This doesn't show any real understanding of what we're actually trying to do. To recap: We don't want to enumerate all NFS servers in a domain. That is not an interesting enumeration. We want to find certain ones that are known to share a domain root (hence the syntax we chose). When we find those servers, we will talk NFSv4 to them (not a new service). And we will talk NFSv4 on port 2049 (not a new port). Your proposal above makes things worse in that it will no longer be clear what the SRV record means. It also ensures that we have a problem if we ever want to enumerate other subsets of NFS servers (none of which have been discussed). Rob T Hi Rob, Few inputs you can take with a huge grain of salt 1) some people on this list have suggest TXT records. Keep in mind this is totally the wrong group to tell you how to use DNS. Last time I discussed TXT records with the DNS directorate they certainly would not have recommended them for this use. I suspect the advice to use TXT is very bad but either way, if you want advice on that, go talk to the DNS Directorate not the transport guys. 2) My understanding is that you have two types of service you want to be able to find using SRV. Now these two services both happen to use the same protocol to talk to them and both run on same default port so you don't need two ports allocated for them but you do need to be able to make separate DNS entries for the two because some servers offer one of the service and some don't. Using SRV and having one labels like _service1._tcp.example.com for one service and _service._tcp.example.com for the other service seem perfectly reasonable to me, but this is the TSV review and I don't know why the TSV directorate would be providing any comment on how you use DNS. Now the fact that both will likely point as the same port and same server in some times seems fine to me. 3) Nothing to do with TSV but, your motivation for separating the _service1._tcp into _service1._foo._tcp seems like something you don't really need and is going to make this harder for you to get this all approved. Unless you need this, I'd think carefully about how much you want it. Keep in mind if some other protocol wants the domain concept, they can just go allocate two tags for use in SRV DNS. 4) I have not seen a single transport issue raised in this thread Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Dean, I think you would be an ideal person to be on IAOC. Would you be willing to stand for that? Cullen On Aug 30, 2011, at 2:00 PM, Dean Willis wrote: On 8/23/11 9:24 AM, John C Klensin wrote: So I'm opposed to a USD 200 (or any other number) firm limit on hotel rates. At the same time, I continue to wish that the IAOC would be more open with the community about how these decisions are made and, in particular, how the tradeoffs between sponsorship (and hence lower costs to the IETF for meeting infrastructure and arrangements) and meetings costs to attendees are made... open enough that the community could give substantive guidance on the subject, guidance that I assume the IAOC would follow if it were coherent and plausible. Quite right. There's more than just the hotel rates. My budget is about $2500 US per IETF meeting. That has to cover airfare, the IETF meeting fee, the hotel, meals, service charges, ground transport, mobile phone roaming, incidentals, etc. $300 a night counting taxes and surcharge is just ABSOLUTELY OUT OF THE FREAKING QUESTION. Having the backup hotel a 10 minute taxi ride away is out of the question -- I can't afford taxis. If I can't walk, I can't go. So guess what? I told the wife last night that I wasn't planning to go to the Taiwan meeting. I wanted to go, but I just don't see how it can happen. Maybe I'll win the lottery between now and then... I'm disappointed. I'm hurt. I'm angry. And the trend has just been getting worse and worse with every venue. I want the IAOC's heads on a platter (preferably an inexpensive, disposable platter, like maybe the lid off an old pizza box) for signing us up to this venue. And I want a travel budget no larger than mine for the people we send to future meetings. If we can't find a reasonably inexpensive place to have a meeting, DON'T HAVE THE MEETING! -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [nfsv4] TSVDIR review ofdraft-ietf-nfsv4-federated-dns-srv-namespace
Craig, I can't see how the transport directorate is relevant given there are no transport issues involved but ignoring that, as an individual contributor at the IETF, what you are proposing below looks like a simple and easy path forward that would work fine. Thought I agree that RFC 2782 needs and update, preferable done by Stuart Cheshire, to bring it in line with what is widely deployed, I am pretty confident that updating 2782 will not be a quick or easy process. Cullen On Sep 13, 2011, at 6:58 AM, Everhart, Craig wrote: Hi, Thanks, Joe, for the thoughtful review. Extracting some light from yesterday's discussion and RFCs 6335 and 2782, much of the contention seems to be around whether there could be two assigned names for related services that both happen to be provided over a given assigned port number. I'd like to propose an adjustment of the request, in light of the RFC text, and ask your judgment on how that adjusted request would fit within the services rubric that's outlined. In RFC 6335, explicit room is carved out for assigned service name[s] without [a] corresponding fixed port number with explicit reference to RFC 2782. Such a service name assignment would be completely adequate for purposes of the NFS domain root concept. As I read RFC 6335, such assignments are RECOMMENDED, and that IANA strives to assign such names under a first-come first-served policy (with reference to RFC 5226). In this formulation, the existing nfs service could stand unaffected. The proposed service, nfsdomainroot, would request name assignment without a port number. The NFS client would seek SRV records under names such as _nfsdomainroot._tcp.example.com. The result processing would continue as before, with SRV records indicating the hosts providing NFS service for the root of example.com's file system. The SRV record then includes the port number on which the target NFS hosts provide nfsdomainroot service, which is given as an application of the NFS protocol in the subject I-D (including a mount point). The I-D would also need to propose, in the IANA section, that IANA assign the service name SRVnfsdomainrootTCP to this protocol. UDP service name allocation is unnecessary. In the judgment of the TSVDIR, would this take the I-D in a more acceptable direction? Craig -Original Message- From: Joe Touch [mailto:to...@isi.edu] Sent: Sunday, September 11, 2011 4:12 PM To: draft-ietf-nfsv4-federated-dns-srv-namesp...@tools.ietf.org; tsv- a...@tools.ietf.org; ietf@ietf.org; nf...@ietf.org Cc: tsv-...@ietf.org Subject: [nfsv4] TSVDIR review ofdraft-ietf-nfsv4-federated-dns-srv- namespace Hi, all, I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This document describes the use of DNS SRV records to coordinate NFS4 use and a global file namespace across a groups of clients and servers. There are no transport protocol issues in this document. The key transport issue is the definition of a new DNS SRV record and its associated syntax. There are issues with the intended syntax of the proposed DNS SRV record. The current syntax is defined in RFC 2782 as: _service._transport.NAME service is an IANA SRV name, the namespace of which is defined in RFC 6335 transport is _TCP or _UDP NAME is a DNS FQDN Given other considerations below (on versioning), the record should be one of the following _nfs._tcp.example.com TTL Class SRV Priority Weight Port Target _nfs._udp.example.com TTL Class SRV Priority Weight Port Target All other information specific to the exchange, e.g., organization (which may or may not be a suffix of the Target, FWIW), desired mount point, and various NFS-specific capabilities (e.g., mount options) ought to be expressed in an associated TXT record as defined fields, as is the case with other services that use SRV records. These options can have defaults if not otherwise present. Some other issues are discussed below. Overall, the above is the key concern, and needs to be addressed before proceeding. Issues below are indicated as either critical or suggestions for clarification. Joe Critical issues: - the IANA section is incomplete This document needs to request IANA assign an SRV service name, e.g.: SRV nfs TCP SRV nfs UDP It is not clear whether an additional assignment of SRV nfs SCTP is required; recent discussions on
Re: Who raised the bar? [Conclusion of the last call on draft-housley-two-maturity-levels]
On Sep 6, 2011, at 4:01 PM, Brian E Carpenter wrote: On 2011-09-07 09:35, Ted Hardie wrote: ... My personal opinion for some time has been that we ought to recognize that the previous PS moved into WG draft years ago and that anything named an RFC should be recognized as something that market will consider a standard. And who raised the bar? If you want my opinion on who raised the bar, it was the participants of the IETF that wrote many BCPs that they expected future RFCs to be compliant with. For example, take internationalization or security - 2026 does not have a lot to say about these but various other IETF documents do suggest certain things need to be done. Though there are some BCP I might like to ignore or deprecate, overall, I think the type of things that are considered in an RFC today are much better than the situation was when 2026 was written. I don't believe the IESG raised the bar, I think the community raised it in a series of IETF Last Calls. And I think this is good - if this document were lowing the PS bar from what it is today, I'd be strongly objecting to it. The problem in my mind is getting work done quickly, not figuring out how to lower the quality of our work. Cullen and on the irrelevant side note category 1) for just about all people I work with using or deploying things on the internet, RFC == standard regardless of type of RFC 2) though I don't see this draft helping a lot, I applaud those that are trying to make things better and perhaps when this draft is running code, I will see that it helps more than I expected. If it does not harm, it's OK with me. The reason I don't' see this changing what happens is that I don't see how this draft changes the incentives for progression beyond PS. 3) we do have a three tracks in widespread use - the first track is looks like dog food we can ship and see if the dogs will eat it (PS), this is awful dog food and I would not feed it to my children but someone thinks they can make a buck on it so lets ship it (Info), and many experts consider this dog food either toxic or against their religion but to stop the whining we are feeding it to you any way - sort of like the Canadian red cross tainted blood (Experimental). I find all these tracks, and the ISE, very useful in allowing the IETF to get important work done. It wasn't the IESG, it was the market, and more specifically the product managers and IT managers who adopted RFC conformance as their criterion. I'm a bit fed up with the IESG being blamed for this, rather than being congratulated on adapting to it. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
Seems like the public issue could be solved by requiring an NDA from anyone that wanted to see the information. I also imagine people would only need to see high level summary not the actual contract. On Aug 24, 2011, at 3:32 PM, Brian E Carpenter wrote: Keith, I would be amazed if any major hotel or convention centre would allow its bid to be made public in this way. I too am disturbed by the Taipei hotel rate, but I know from my own time on the IAOC that matching bids, dates, hosts and all the other constraints is essentially an insoluble problem. It would be interesting if someone with historical data could plot IETF hotel and meeting fee costs over the years since 1986, normalized to take account of inflation and trade-weighted currency variations. I really can't guess what the outcome would be. Regards Brian Carpenter On 2011-08-25 09:12, Keith Moore wrote: Maybe there needs to be some sort of voting system for future venues. You'd be eligible to vote if you'd attended an IETF anytime within the past, say, 2 years - or if you were willing to commit to attending the one you vote on if it wins. (say by putting down a deposit toward meeting fees). Instead of picking one venue, the committee would solicit bids from N (say 3-4) different venues within a geographic region.The bids would include: room cost per night in the conference hotel room cost per night in each of some small number of alternate hotels locations of said hotels and nature of transportation between there and the conference venue meeting fee for the entire week if that venue is chosen other pertinent information (like what kind of food is nearby, what kind of facilities there are in or near the venue for impromptu gathering, what kinds of sightseeing opportunities there are, etc.) The committee would survey attendees from time to time and tell the prospective venues what kinds of criteria the attendees found important, so they'd know how best to make their pitch. Every eligible voter would get one vote. There would be a strict deadline for submitting bids, and a strict deadline for voting. That way, everyone could figure his own travel costs, factor in his own willingness to stay further away for less cost, etc. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On Aug 25, 2011, at 12:13 AM, Henk Uijterwaal wrote: On 24/08/2011 23:12, Keith Moore wrote: Maybe there needs to be some sort of voting system for future venues. First of all, remember that the community asked for venue selections 2 to 3 years in advance. I don't think that many people can predict if they will attend a meeting 2 years from now. This proposal would require that the secretariat works out 3-4 proposals for meeting locations in great detail. That is a lot more work than the current approach: Really? that is fascinating in itself. I had assume that the current meeting selection did consider more than one place. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On Aug 24, 2011, at 2:27 PM, Sam Hartman wrote: Dave == Dave CROCKER d...@dcrocker.net writes: Dave ps. As a personal aside, I'll note that I've lobbied rather Dave vigorously for venues that entail less travel effort, by Dave eliminating the additional hop needed to get from a major hub. Dave Note that that has gotten essentially zero support from the Dave community. The community has vigrously expressed a preference Dave for interesting venues rather than ones that are chosen Dave solely for logistics convenience. Can you start by backing up the assertion that the community has vigrously expressed a preference for interesting venues? I may just need a new IETF community:-) What I have heard is that the community would prefer going to locations that were easy to travel to over interesting. I'd be perfectly happy with every US meeting being in Minneapolis. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
On Aug 3, 2011, at 2:45 PM, Peter Saint-Andre wrote: On 8/3/11 1:26 PM, Martin Rex wrote: subject_prefix will work even with very ancient MUAs, such as the one I use, so I'm OK. But the subject_prefix does not scale well when multiple IETF mailings lists are CC-ed and discussion ensues (replying to all lists). Doctor, it hurts when I do that. /psa Yah, I find this particularly bad when reading email on my Datapoint 3300 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
Thanks Marshall, I had suspect the process was something like that. I had not realized how much the pre picking the dates reduced the options. On Aug 27, 2011, at 9:43 AM, Marshall Eubanks wrote: On Sat, Aug 27, 2011 at 10:48 AM, Cullen Jennings flu...@cisco.com wrote: On Aug 25, 2011, at 12:13 AM, Henk Uijterwaal wrote: On 24/08/2011 23:12, Keith Moore wrote: Maybe there needs to be some sort of voting system for future venues. First of all, remember that the community asked for venue selections 2 to 3 years in advance. I don't think that many people can predict if they will attend a meeting 2 years from now. This proposal would require that the secretariat works out 3-4 proposals for meeting locations in great detail. That is a lot more work than the current approach: Really? that is fascinating in itself. I had assume that the current meeting selection did consider more than one place. Of course it does. For example, for the last meeting there were a number of venues considered, most of which were knocked out quickly, say because they were already booked for our week. Eventually, it boiled down to Vancouver vs QC, which were pretty even in every regard except for the travel situation. Thus, the survey. That rarely happens if the past 5 years are any guide. I think that the meeting selection process is inherently iterative. Pseudo code might be something like - Find a list of all venues we can in the target area for the target week. The number of these is rarely if ever more than 10. - do an evaluation of venues for availability and suitability - remove any sites that are not available or are unsuitable. - rank the remainder for suitability, and do a more thorough evaluation, focusing more on the higher ranked locations. - repeat the last 3 steps until convergence, tightening the filters based on what's learned about the sites At the end of the process, there may be only be one place left, but it certainly was not the only one considered. Until recently, sponsor availability was an important part of venue ranking. Now, with the 3 year out meeting selection process, that coupling will largely (but not entirely) go away. Basically, this change IMO increases the risk of not getting a sponsor, in return for a better choice of available venues. I suspect it will take a few years before we will see what the actual cost/benefit ratio is for this change. Regards Marshall ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART Review: Last Call draft-ietf-p2psip-base-17.txt
Thanks for the detailed review - you caught some good stuff. Most of this makes essence but we should probably talk about usage of 2119 language. On Aug 9, 2011, at 16:05 , Mary Barnes wrote: simple === Document: draft-ietf-p2psip-base-17 Reviewer: Mary Barnes Review Date: 9 August 2011 IETF LC End Date: 22 July 2011 Summary: Not Ready. Comments: The document is very a dense (with detailed technical information) and long (150 page) specification for a Peer-to-peer signaling protocol. While the overall technical functionality seems fairly correct and thoroughly specified, the primary issue is a tremendous lack of normative language in the main body of the document. Non-inclusive details of such are included below. The 2119 MUST/SHOULD/MAY terms are simply abbreviations for some words defined in 2119, and different WGs have different styles about how extensively they should be used. P2PSIP has obviously been on the more sparing side of that spectrum. This isn't to say that there aren't any places where it would be useful to add such language, but rather that our policy has been to add it principally where there is likely ambiguity, rather than everywhere where behavior is defined. I'll work thought these and see where they might help reduce the chance of a an implementers doing the wrong thing but in generally when we define a structure in something like ASN.1 or ABNF, if the structure always has a field X, we just use the language like ASN.1 or ABNF to indicate it always has that. We don't also say it MUST be there. Major Issues: --- General: --There is a fair number of cases where normative language should be used. I have detailed some (but certainly not all) instances where it is lacking with proposed rewording. I have also noted cases where it is used (lower case) where it could be confused with needing normative language and where it isn't necessary and there are some cases where it's just not clear. I consider these major since it can impact interoperability and could lead developers to not implement key functionality. --There is also little or no normative language for the majority of the elements in the structures - i.e., the reader has to assume which elements are mandatory and which are optional and it's not always clear. For example, rather than saying Field x contains blah, it should say Field x MUST contain blah and rather than The contents of the message will be x, y and z, it should say something like The message MUST (or SHOULD) contain x, y and z. I have not detailed the places where this is necessary in most cases. The authors should review the detailed definition for each of the messages. However, the syntax actually tells you whether a field is mandatory or not. I.e., there is a select/case syntax for indicating optional fields (and some fields are variable length). So I don't think it's really ambiguous in the general case whether a field need be present. With that said, this seems like something that would be better discussed real time - I may be missing the point on some of these. When would be a good time to have a call? --The message names are used inconsistently. The IANA registry has the message codes all lower case. There are places in the examples and the body of the document where the _req part is missing, there is no _, the first letters are Upper case, etc. The messages are also used in a general sense - e.g., MUST perform an Attach, which should really be stated as MUST send an attach_req message) Well, it's the Attach is much more than sending a attach_req and we found that trying to add more just make the document even longer and harder to understand than it currently is. We been pretty careful about the case as some systems auto generate code out the the structures in the draft. I'm glad to walk through these and figure them out with you. That said, these have been changed various times and it's hard to find them all so there could certainly be a mistakes in this. Major - Detailed: - Sections 32.1, 3.2.2 and 3.3: lots of changes needed to reword using normative language. - Section 3.4, last paragraph: Needs to be reworded normatively and more precisely. It's really not clear to me what the required behavior is as it first says it needs to (which I'm not sure is a SHOULD or is REQUIRED to) maintain connections to all the peers near and enough others.., but how much is enough. Also, what is meant by the specified link set - is that referring to all the nearby peers or the peers+enough others? Or is this more clearly (and normatively) specified elsewhere, such that a reference could be added All of section 3 is overview and not meant to have the normative descriptions which happen in the later sections.
reading drafts on an ipad
Has anyone found a particularly good solution to reading drafts on an ipad? What about markup and notes on drafts? Thanks, Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PCN] Last Call: draft-ietf-pcn-cl-edge-behaviour-08.txt (PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation) to Informational RFC
On Jun 12, 2011, at 8:48 AM, Tom Taylor wrote: What I propose is that I submit the documents with the fixes that were carried out, and the IESG restart the Last Call process. Tom, glad was caught this before this was an RFC. I think your proposal sounds like the right way to proceed. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [codec] Last Call: draft-ietf-codec-requirements-04.txt (Codec Requirements) to Informational RFC
This is all a sort of confusing point of many IETF documents and not unique to this one. I think the important points is that for many IETF documents, the people listed on the front page are not the authors. Typically the list of authors is a much longer list. And to clarify what I mean by Author, I mean it in the sense that it would used in copyright law. I do think the Acknowledgements section needs to identity anyone who is a contributor to the document. The limit on number of people on the front pages makes it impossible to even put all the authors on the front page if we wanted to. So my main point is, just because someone is listed on front page or not, should not be used to decide if they are an author or not. The use of Ed. has been a bit inconsistent at the IETF and I'm not aware of good guidelines on how and when to use it. Traditionally when we have had a few people producing the drafts and incorporating work from the multiple people in on the mailing list, the people where were actively editing the document have often been listed on the front page. There are many exception to this - I was a bit cheesed to not be listed on the front page of RFC 4244. Back to the matter at hand ... This is a pretty classic sort of document where an individual draft got selected as a basis for the WG document, multiple people in the WG contributed text, a final draft was produced. Historically, most IETF docs like this do not put Ed after all the people on the front page. However, perhaps we should, I don't really have any strong opinion one way or the other. I can confirm that this document, like many documents coming out of a WG, includes contribution from people beyond the list of names on the front page. Cullen On Jun 16, 2011, at 2:42 PM, Christian Hoene wrote: Hello, In this draft, the editors of draft are not named as editors but as authors. Thus, I would suggest to follow the example given in http://www.rfc-editor.org/rfc/rfc5620.txt and add an , Ed. behind the names. A list of authors is given in the acknowledgement section of the draft. With best regards, Christian Hoene -Original Message- From: codec-boun...@ietf.org [mailto:codec-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, June 16, 2011 9:24 PM To: IETF-Announce Cc: co...@ietf.org Subject: [codec] Last Call: draft-ietf-codec-requirements-04.txt (Codec Requirements) to Informational RFC The IESG has received a request from the Internet Wideband Audio Codec WG (codec) to consider the following document: - 'Codec Requirements' draft-ietf-codec-requirements-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-30. 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. Abstract This document provides specific requirements for an Internet audio codec. These requirements address quality, sampling rate, bit-rate, and packet loss robustness, as well as other desirable properties. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-codec-requirements/ No IPR declarations have been submitted directly on this I-D. ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ codec mailing list co...@ietf.org https://www.ietf.org/mailman/listinfo/codec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mmusic-ice-options-registry-01.txt (IANARegistry for Interactive Connectivity Establishment (ICE) Options) toProposed Standard
On Apr 28, 2011, at 11:22 AM, Mykyta Yevstifeyev wrote: 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? Just wanted to add my 2 cents that I agree this needs to be Standards Track as is is effectively a key part of standards track spec that got, uh, forgotten. Changes to this registration procedure need the standards track level of approval. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [paws] WG Review: Protocol to Access White Space database (paws)
GEOLOC has been a WG that is somewhat on the edge between Apps and RAI. Much of what geoloc was doing, particularly the location for emergency calling, had real time issues and the interested people largely lined up with the the other RAI groups even though geoloc has uses outside anything to do with SIP. PAWS on the other hand does not seem to have real time application issues so it seems like Apps is probably a more appropriate area for it. Cullen On Apr 19, 2011, at 11:50 AM, Joel M. Halpern wrote: I think this working group is a good idea. My inclination would be to place it in the Applications area. It looks like a nice application protocol to me. There is a reasonable argument for placing it in RAI, as that is where the relevant GEOLOC work has been done up till now. Yours, Joel M. Halpern On 4/19/2011 12:56 PM, IESG Secretary wrote: A new IETF working group has been proposed. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, April 26, 2011. Protocol to Access White Space database (paws) Current Status: Proposed Working Group Last updated: 2011-04-14 Chairs: TBD Area Directors: TBD Area Advisor: TBD Mailing lists: Address: p...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/paws Archive: http://www.ietf.org/mail-archive/web/paws/ Description of Working Group: Governments around the world continue to search for new pieces of radio spectrum which can be used by the expanding wireless communications industry to provide more services in the usable spectrum. The concept of allowing secondary transmissions (licensed or unlicensed) in frequencies allocated to a primary user is a technique to unlock existing spectrum for new use. An obvious requirement is that these secondary transmissions do not interfere with the primary use of the spectrum. Often, in a given physical location, the primary user(s) may not be using the entire band allocated to them. The available spectrum for a secondary use would then depend on the location of the secondary user. The primary user may have a schedule when it uses the spectrum, which may be available for secondary use outside that schedule. The fundamental issue is how to determine for a specific location and specific time, if any of the primary spectrum is available for secondary use. One simple mechanism is to use a geospatial database that records protected contours for primary users, and require the secondary users to check the database prior to selecting what part of the spectrum they use. Such databases could be available on the Internet for query by users. In a typical implementation of geolocation and database to access TV white space, a radio is configured with, or has the capability to determine its location in latitude and longitude. At power-on, before the device can transmit or use any of the spectrum set aside for secondary use, the device must identify the relevant database to query, contact the database, provide its geolocation and receive in return a list of unoccupied or white space spectrum (for example, in a TV White space implementation, the list of available channels at that location). The device can then select one of the channels from the list and begin to transmit and receive on the selected channel. The device must query the database subsequently on a periodic basis for a list of unoccupied channels based on certain conditions, e.g. a fixed amount of time has passed or the device has changed location beyond a specified threshold. The databases are expected to be reachable via the Internet and the devices querying these databases are expected to have some form of Internet connectivity, directly or indirectly. The databases may be country specific since the available spectrum and regulations may vary, but the fundamental operation of the protocol should be country independent, thus extensibility of data structures will be required. The solution will not be tied to any specific spectrum, country, or phy/mac/air interface but may incorporate relevant aspects of these as needed for proper operation. The proposed working group will : - standardize a protocol for querying the database, which includes a location sensitive database discovery mechanism and security for the protocol, and application services. - Standardize the data structure to be carried by the query protocol. The protocol must protect both the channel enablement process and the privacy of users. Robust security mechanisms are required to prevent: device identity spoofing, modification of device requests, modification of channel enablement information, impersonation of registered database services and unauthorized disclosure of a users
Re: Last Call: draft-ietf-enum-iax-10.txt (IANA Registration for Enumservice 'iax') to Informational RFC
FWIW ... I reviewed this and thought it looked fine. On Apr 5, 2011, at 5:48 AM, The IESG wrote: The IESG has received a request from the Telephone Number Mapping WG (enum) to consider the following document: - 'IANA Registration for Enumservice 'iax'' draft-ietf-enum-iax-10.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-19. 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-enum-iax/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-enum-iax/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IONs Report (was: Where to find IONs?)
you might want the intended status of that draft to be historic not informative On Mar 6, 2011, at 11:04 PM, Mykyta Yevstifeyev wrote: Hello all, I've just made the Internet-Draft containing some summary on IONs experiment available. You may find it here: http://tools.ietf.org/html/draft-yevstifeyev-ion-report-00 Any comments and suggestions are welcome. All the best, Mykyta Yevstifeyev 06.03.2011 22:11, Brian E Carpenter wrote: On 2011-03-07 00:15, Adrian Farrel wrote: Hi Mykyta, Please see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04792.html Adrian One could argue that http://www.ietf.org/iesg/process-experiment.html should also contain pointers, or at least a status line, for concluded experiments. (It's my fault that it doesn't, since I created the original version of that page.) Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sipcore-199-05.txt (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard
On Feb 7, 2011, at 2:01 PM, Adam Roach wrote: On 2/7/11 12:44 PM, Cullen Jennings wrote: I was somewhat surprised to see this back in LC. I am still not aware of any use case where this actually helps. I searched the IETF and WG lists for email with the subject draft-ietf-sipcore-199 and I do not see a single email that suggests there is support for this draft or the changes in it since the previous LC. This draft has no use that I understand how it helps - it is at best a very limited optimization. The SIP standards is already too complicated with too many extensions. I believe this draft makes SIP worse.Thought the draft mandates that systems need to work even when the 199 are lost, I do not think that is how the proponents of the work intent to use. I could be very wrong but I presume that people intent to use to control middle boxes that control media gates. It's broken for that but given that is not discussed in the draft, it's hard to discuss how it is broken and what would be needed to fix it. I do not support publishing this draft as standards track without actual WG discussion on what the problem is this draft solves and if there is WG consensus that problem is worth solving. Cullen: Speaking as a chair of SIPCORE, I would like to clarify a minor point. Although it may not have been your intention, your message can be read as implying that the SIPCORE chairs and/or the RAI area directors have decided to move this document forward without community input. It was really just sloppy overly fast writing on my part - I did not mean to imply that. The total time I'm willing to spend on this draft is pretty minimal. For the benefit of those on this mailing list who were not involved in the earlier stages of this document's progress: the initial community input on whether to pursue the problem solved by this draft was taken at the face-to-face SIPPING meeting during IETF 69. In particular, the minutes for that meeting reflect: Hum... in support of working on this problem. In April of 2008, the requirements document was handed over from SIPPING to the SIP working group for working on actual protocol mechanism. (The SIP change process at the time limited core protocol changes to the SIP working group, requiring a change in venue). Within the SIP working group, there were at least 316 message in 38 different threads on the protocol document over the one year period spanning April 2008 to April 2009. This period included a two-week long Working Group Last Call period in November of 2008. In April of 2009, the RAI area underwent a reorganization, which resulted in the conclusion of the SIP working group. As part of the chartering of the SIPCORE working group, this document (and its associated milestone) was transferred to the SIPCORE WG. In January of 2010, the document entered IETF last call for the first time. During IETF balloting, certain issues were identified by the IESG, and balloted as a DISCUSS position. Over the course of 2010, the document's author worked with the RAI ADs to address these issues to the satisfaction of the currently seated IESG. I thought we were still in middle on conversation about what to do about any this stuff - thus my surprise it was in LC again. Last email I had was you in May of asking Christer if he was going to reply. He eventual did but it did resolve what this was use for. It did point out that no one was complaining about it. That caused me to send an email in June that said Silence is not consent - the WG does not care about this and there is not consensus that it is useful, what it is useful for, or that it should be published. I'd be happy to shown to be wrong as I, like I suspect many others, don't care too much one way or the other. After that, other than people saying the IETF had to do this because 3GPP had already made it mandatory, I had not heard any more about it. As a result of these conversations, a technical issue involving interaction with another SIP extension mechanism was identified, and brought back to the SIPCORE working group. A resolution to the issue was identified in early December 2010, and a revised version of the document was produced to reflect this resolution. Uh, you mean the one where the total traffic seems to be Chair (Paul) proposed the WG should see if the WG was OK with it Christer (Author) said he was OK with even though he did not really like it Keith proposed some text without saying if he actually liked any of it or not Christer (Author) said he was OK with it And no one else said anything. Hopefully I failed to find the email, or lost it, or am just confused, but I have a hard time imaging how that looks like consensus in one of the largest WG in the IETF. At every step of this process, the IETF, RAI, and SIP community has opportunity for involvement. The volume of discussion
Re: Last Call: draft-ietf-intarea-server-logging-recommendations-02.txt (Logging recommendations for Internet facing servers) to BCP
I'd like to see a bit of text about privacy considerations added to this. For some servers, the advice in draft is fine but for many servers, I think logging this sort of information is an awful idea. It makes the owner of the server a subpoena target, possibly violates laws in some countries around personal identifying information, and will have no benefit for the operator of the server business or ability to debug, improve, or provide service. The draft should also point out that the source port, ip, and time does not uniquely identify a host behind the nat. Some NATs are designed so that two devices inside the NAT, call them A and B, are talking to different external servers, call them C and D. The NAT may use the same external IP and port on the NAT for the flow from A to C as it uses from the flow from B to D. The nat can different them looking at the 5 tuple. So if an email server sees a packet form a given IP port at the same time that a bittorent server sees packet from same IP and port, there is no guarantees that they came from the same host. This recommendation fails to say anything about what protocol one might use to log this information - given the rates of information from CGN the existing IETF logging protocols may not be appropriate. It seem to me that an BCP about what web, email, sip, and xmpp servers should do should probably be run by theses areas. On Feb 25, 2011, at 8:04 AM, The IESG wrote: The IESG has received a request from the Internet Area Working Group WG (intarea) to consider the following document: - 'Logging recommendations for Internet facing servers' draft-ietf-intarea-server-logging-recommendations-02.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-03-11. 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-intarea-server-logging-recommendations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-intarea-server-logging-recommendations/ 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 ___ 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
I propose some text for the draft near the bottom of this email On Feb 2, 2011, at 2:16 AM, Magnus Westerlund wrote: 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. Sorry Magnus ... I really did not mean to twist your words. I know you are very straight up about this type of stuff. I suggested some text bellow. - 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. I understand that but we both know appeals are a painful tool to use and we would like to avoid it where possible - they waste an incredible amount of time for everyone involved and particularly the IESG. - One can take a assignment request through the IETF process I'm not as focused on drafts in IETF process but even in theses cases, WGs will look to this BCP for guidance on what would be acceptable behavior. So even if this draft might not legally block a WG from doing something, the WG will still be influenced by the goals this draft strives for. That is a good thing - BCP advice that applies to non IETF work should guide IETF process work too. 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? For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. The reason I think this needs to be in the draft is very simple. In my mind there are clear and compelling cases for two ports - many of them involving DTLS and real time protocols that actually care about number of round trips. Joe Touch has already said he would reject an example use case that I think should be accepted. I think this is much easier to resolve this issue now than with an appeal. The CORE WG, which I co-chair, needs clear advice now on what direction would be acceptable and is not particular interested in waiting for a year or two for the drafts to be done, appealed, and then redesigned. 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
Paul's text is much better than mine. That was what I trying to get at. On Feb 15, 2011, at 8:59 PM, Paul Hoffman wrote: On 2/15/11 7:34 PM, Cullen Jennings wrote: I propose some text for the draft near the bottom of this email For the user ports the document should have some text along the lines of: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol therefor the export reviewer should not reject a request for a second port to run a secure variant of the protocol over. That feels close, but too prescriptive. Also, the requests are usually for a protocol with two ports, not a later request for a second port. How about: There is not IETF consensus on when it is appropriate to use a second port for a secure version of protocol. Therefore, an expert reviewer should not reject a proposal for a protocol that uses a second part to run a secure variant for the sole reason that it using two ports. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-iana-ports-09.txt now draft-ietf-tsvwg-iana-ports-10.txt
It seems like the text in version 10 are changes that would need a LC to decide if they had consensus. Consider the change to add the text Because the port number space is finite (and therefore conservation is an important goal) the alternative of using service names instead of port numbers is RECOMMENDED whenever possible. I think at least one member of the expert review teams believes that it is possible to use SRV for most protocols so does this mean that ports will not be assigned for most protocols? Take SIP or XMPP for example, they both use SRV - would they get a port? If we were doing a new protocol like HTTP that did not define a SRV record but could be designed to have one, would the expert reviews approve a port or not? I think all these topics need significant discussion before the a LC of text like this. Anyone want to elaborate on how whenever possible would be decided? I find the the following text a bit outrageous. Applicants should be aware that IANA decisions are not required to be bound to these principles. These principles and general advice to users on port use are expected to change over time and are therefore documented separately, please see [I-D.touch-tsvwg-port-use]. The basic complaints about this draft can mostly be summarized as a view that everything that the authors of this draft could not get agreement on in the WG, they just made the draft silent on and Joe is asserting that the expert reviews can do whatever they think was best regardless of any IETF consensus and then people can appeal it. So this text would have this BCP assert that the place to find out what was OK and not OK was in documented in an individual draft written by Joe. This is not OK. Consider if I asked that instead, it pointed at I-D.fluffy-port-use. I'm sure many people would think that was totally unacceptable. I don't see how this is any more acceptable. It seems like an inappropriate change to make without a new LC. I don't think that it is OK for a BCP on how to register ports to point people at a spec without consensus approval that says what is OK to register and what is not. I am confused by use of the Expert Review helps advise IANA informally in cases where IETF Review or IESG Review is used, as with most IETF protocols. I read this to mean that IANA would also ask for expert review on allocations made in IESG reviewed drafts? This seemed to be the opposite of what was discussed on list. The draft removed the and so strives to avoid separate assignments for non-secure variants out of IANA strives to encourage the deployment of secure protocols, and so strives to avoid separate assignments for non-secure variants I suspect this was done to try and address my main complaint but I don't see how it helps. On Feb 11, 2011, at 6:15 PM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Area Working Group Working Group of the IETF. Title : Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry Author(s) : M. Cotton, et al. Filename: draft-ietf-tsvwg-iana-ports-10.txt Pages : 32 Date: 2011-02-11 This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number Registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry. This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780], and it updates the IANA Service Name and Port assignment procedures for UDP-Lite [RFC3828], DCCP [RFC4340] [RFC5595] and SCTP [RFC4960]. It also updates the DNS SRV specification [RFC2782] to clarify what a service name is and how it is registered. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-iana-ports-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Mail Attachment___ I-D-Announce mailing list i-d-annou...@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ___ 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
I've been thinking more about this thread and my concerns about this draft. I was originally looking for the draft to have advice for the expert review team that gave them guidance on what the IETF thought was all right to approve or not approve. It's become clear that this draft does not have that advice and is not likely to get it in the very short term. This BCP will empower the expert reviewer to reject or approve just about any request. Appeals are not the best way to balance putting that power because they are incredibly corrosive and time consuming to everyone involved. I think this thread somewhat suggests an alternative approach for a check and balance. What do people think of the idea of: for all ports requests, the request and the expert reviewer reposes including reason for accepting or rejecting them need to be posted to a public email list. This seems like a simple way to help mitigate this issue and it will help educate people writing a port request to know what types of issues they need to address and what would be appropriate or not. Pros cons of this idea? On Feb 8, 2011, at 1:41 PM, Christian Huitema wrote: I don't see that public identity (of expert reviewers) is required for interactive discussion. Or would anonymous interaction fail a Turing test of some kind? Public identity is required for reviewer accountability. It is easy to imagine how withholding registration of some required numbers may delay a competitor's products. The best protection against shade is sunlight. -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-sipcore-199-05.txt (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard
I was somewhat surprised to see this back in LC. I am still not aware of any use case where this actually helps. I searched the IETF and WG lists for email with the subject draft-ietf-sipcore-199 and I do not see a single email that suggests there is support for this draft or the changes in it since the previous LC. This draft has no use that I understand how it helps - it is at best a very limited optimization. The SIP standards is already too complicated with too many extensions. I believe this draft makes SIP worse.Thought the draft mandates that systems need to work even when the 199 are lost, I do not think that is how the proponents of the work intent to use. I could be very wrong but I presume that people intent to use to control middle boxes that control media gates. It's broken for that but given that is not discussed in the draft, it's hard to discuss how it is broken and what would be needed to fix it. I do not support publishing this draft as standards track without actual WG discussion on what the problem is this draft solves and if there is WG consensus that problem is worth solving. On Feb 7, 2011, at 10:02 AM, The IESG wrote: The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog' draft-ietf-sipcore-199-05.txt as a Proposed Standard This is the second IETF last call for this document. The previous last call was on version -02. While resolving review comments, an issue with the interaction of the 199 response and the 100rel extension was identified and addressed by the SIPCORE working group. A full summary of the changes are available in section 13 of the document. 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-21. 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. Abstract This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate towards upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Test messages 1
Sorry for this - please ignore but some people are having issues with this list. ___ 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
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. On Jan 31, 2011, at 8:06 , Magnus Westerlund wrote: 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? ___ 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
inline On Feb 1, 2011, at 5:14 , Magnus Westerlund wrote: 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? I've provided reason why I think this is needed for security in previous email on this thread. I'm not arguing you need more ports for versions or feature support - I don't think you do. 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. I'm far more worried about people just using ports without registering them than I am about running out. Keep in mind the allocation policy is more or less anyone can get one port for just about anything so if we are really worried about running out, we would change that. Most protocols will not need or request two ports. 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. Reasonable here is the problem. I don't want the expert review to tell me a second port for security is not reasonable for cases where latency is a relevant. - Be reasonably tough from the expert reviewer to ensure that applicants has done this. Again - I want to be able to register ports for proprietary protocols without disclosing the details of the proprietary algorithm 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. It's not just an ease of anything - it's the real time performance of the resulting system that is an issue. 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 -- Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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
On Jan 31, 2011, at 8:14 , Paul Hoffman wrote: On 1/31/11 7:06 AM, Lars Eggert wrote: But I see the point you're raising. The document should somewhere say that Expert Review is the procedure used for assignment requests made directly to IANA, whereas for documents on the IETF Stream, IETF Consensus is sufficient to make the assignment. In other words, no expert review doesn't really need to happen for those, since IETF Review and IESG Approval are at least equivalent. Did I get that right? Yes, that would greatly reduce the concern about where and when (and how often!) the review would happen. Hmm ... I don't agree that solves the issue. 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 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. 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. ___ 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
So IANA has a huge amount of technical expertise and takes maintaing the registries very seriously. I've seen them catch technical mistakes that made all the way through WG and IESG review. I've got huge respect for technical competence of IANA and in particular Michelle. So I'm not questions that but I don't recall seeing them override an expert on a technical issue. I'd be happy to hear of examples but lets consider the example I am actually concerned about here. I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, that will not meet the latency goals of the protocol. Joe does not agree. So Michelle, in that case, would you be willing to override Joe? I'm sure you would be willing to help facilitate any conversations, bring in other people such as ADs that can help etc. I was sort of working on the assumption that you would not override Joe in this case and the the only path forward would be an appeal to Lars but perhaps that is just a bad assumption on my part. Appeals are really the worst way possible to resolve things. I have a hard time imagining that IANA would want to engage in a technical discussion to resolve this and instead relies on the expert reviewer. I'll note that the expert review may report to IANA but they are selected by and replaced by the IESG. The important point here is that I really don't care if it is Joe or IANA that is saying no - I think this document should be clear that this BCP can not be used as grounds for rejecting the request for a second port for security. On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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
Thanks - yes that makes it clear and I like the way IANA handles all of this. On Jan 31, 2011, at 9:55 , Michelle Cotton wrote: Cullen, We do have some technical expertise within the IANA staff, however our expertise is more aligned with the process of creating and maintaining registries. Part of that includes relying on the experts that the IESG designates to make the decisions for requests that utilize the Expert Review policy in RFC 5226. In the past, if there is strong disagreement from an expert and the requester disagrees, we have brought the Transport Area Directors into the communications to see if all parties can come to an agreement. In almost all cases, this is where a final decision is made. If that set of folks can not come to a conclusion, we then would default to going to the IESG. With all requests, if there is any uncertainty as to what decision should be made, we go to the IESG for guidance. We do rely on the technical expertise of the appointed experts for all registries, but we ALWAYS have the possibility to seek guidance form the IESG. I don't believe we have ever had an official appeals with ports (Knocking on wood really hard!). Does that help? --Michelle On 1/31/11 8:33 AM, Cullen Jennings flu...@cisco.com wrote: So IANA has a huge amount of technical expertise and takes maintaing the registries very seriously. I've seen them catch technical mistakes that made all the way through WG and IESG review. I've got huge respect for technical competence of IANA and in particular Michelle. So I'm not questions that but I don't recall seeing them override an expert on a technical issue. I'd be happy to hear of examples but lets consider the example I am actually concerned about here. I put in a request for a latency sensitive protocol that uses DTLS and request a different port for the secure version. Joe as expert review says we should redesign the protocol to use something like STARTLS and run on one port. I assert, with very little evidence, that will not meet the latency goals of the protocol. Joe does not agree. So Michelle, in that case, would you be willing to override Joe? I'm sure you would be willing to help facilitate any conversations, bring in other people such as ADs that can help etc. I was sort of working on the assumption that you would not override Joe in this case and the the only path forward would be an appeal to Lars but perhaps that is just a bad assumption on my part. Appeals are really the worst way possible to resolve things. I have a hard time imagining that IANA would want to engage in a technical discussion to resolve this and instead relies on the expert reviewer. I'll note that the expert review may report to IANA but they are selected by and replaced by the IESG. The important point here is that I really don't care if it is Joe or IANA that is saying no - I think this document should be clear that this BCP can not be used as grounds for rejecting the request for a second port for security. On Jan 30, 2011, at 12:09 , Michelle Cotton wrote: David has said this well. Thank you. Please let me know if there are any other questions. --Michelle On 1/30/11 10:52 AM, David Conrad d...@virtualized.org wrote: Cullen, On Jan 29, 2011, at 8:54 PM, Cullen Jennings wrote: AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. Joe is closer. In general, IANA staff are not technical experts in any of the wide variety of areas for which they are asked to provide registry services. As such, they rely on technical experts to provide input/advice/recommendations. In the past, there were some very rare cases in which the advice provided by the technical experts was deemed insufficient and IANA staff looked to the ADs or the IESG for additional input. However, at least historically, IANA staff viewed the maintenance of the registries as their responsibility (at the direction of the IESG), not the technical experts' responsibility. I would be surprised if this had changed. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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
On Jan 31, 2011, at 9:41 , Magnus Westerlund wrote: 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. 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. ___ 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
So first, we already have a BCP that says more or less all protocols must implement a secure version but deployment is optional. This is a good BCP, and it comes from the right area to say that - security. It's probably impacts design work in working groups more than any other BCP. It has IETF consensus. The IESG holds protocols to this. Now - I am at loss to see why forcing people to use one port will make it more likely to have secure protocols. This seems crazy. Please do enlighten me. And on the topic, I'm still looking forward to an explanation of how the current CoAP design stomping all over the TLS code points would be an acceptable design. On Jan 31, 2011, at 9:27 , Eliot Lear wrote: On 1/31/11 5:13 PM, Cullen Jennings wrote: Hmm ... I don't agree that solves the issue. 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. Who, ultimately, is the steward of this precious resource? If it is not the IANA and it is not the IETF, then who? To say that it is everyone's responsibility is to avoid responsibility entirely. Who gets to say which standards organizations are stewards and which are not? 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. This is a VERY VERY dangerous approach you propose, Cullen. It is akin to saying, you can think about security later, because we'll have to give you a port for it later. We don't want to be saying that. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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
On Jan 27, 2011, at 17:29 , Michelle Cotton wrote: We are changing that process right now. We have begun to report the reviewer (with the review) in the email to the requester. We just need to make sure this small change is communicated to those experts that are part of review teams as their individual names are not published on the main list of registries. I don't think it needs to go in this document as this is already in progress. Let me know if you have any questions. As long as we agree that is the process, it's not a big deal to me if it is in or out of the document but I don't see any reason not to put it into the document. ___ 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
On Jan 27, 2011, at 17:10 , Joe Touch wrote: On 1/27/2011 12:52 AM, Lars Eggert wrote: ... Small Issue #3: I object to anonymous review The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several emails with an expert reviewer relayed via IANA where the conversation was going no where - once I knew the name of the reviewer, the whole conversation changed and stuff quickly came back to the realm of sane. I'm not willing to forward these emails to the list as that would just not be kind to anyone but I am happy to forward them to the IESG if they think looking at them is really critical. I can see your point, and I personally have no problem with disclosing the reviewer identity. What do others think? AFAICT, the experts team reports to IANA. We make recommendations to them. They are the ones who have the conversation with the applicant. They can take our advice or not - that's their decision. I think you are pretty misrepresenting the situation. My impression of the reality of the situation is that if the IANA did not like the advice of the expert reviewer, they might ask the AD to override but short of that they pretty much do whatever the expert says. ___ 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
On Jan 27, 2011, at 8:12 , IETF Chair wrote: Originally, two ports were assigned for plain and over-TLS, which for HTTP mapped to two different URL schemes: http and https. Many people thought that this was a waste of a port, and the STARTTLS approach was developed. You say that it does not work in some cases, and you seem to be suggesting that we go back to the original way. Maybe it works in some cases and not others. Can we say which is which? I did misread the draft as saying that 2 ports were not allowed when clearly that was not what people meant but ... I'm mostly concerned about cases where latency or bandwidth are an issue - basically protocols for real time protocols for internet of things. For things like email I'm less concerned. However, I think we can make some observation about which works best. Consider some of the most successful protocols on the internet http, 2 ports email, pop, imap, and smtp, - more use on multi ports than STARTLS though many deployment support both sip, 2 ports ___ 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
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. On Jan 27, 2011, at 1:17 , Magnus Westerlund wrote: 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 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ 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
On Jan 27, 2011, at 1:26 , Lars Eggert wrote: On 2011-1-27, at 11:20, Carsten Bormann wrote: With UDP-based protocols, it is harder to do this. Please look at section 7.3 of http://tools.ietf.org/html/draft-ietf-core-coap-04.html#section-7.3 and tell us whether this is how you would like this to be handled for UDP-based protocols in the future. If not, we may want to add to the guidance in the (tsvwg) draft. This looks like a totally reasonable way to to this in-band using a single port. How is the COAP working stepping on top of TLS code points any different that the ITU-T stepping on MPLS code points? ___ 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
consider a protocol like FTP data transport - first FTP does some signaling and it can pass the ports to be used for the data transport connection so you might think the dynamic range is fine for the transport part - but policy on firewalls has resulted in people wanting to have a well known port for that FTP uses for the data connection. Most FTP now supports PASV and things like that to meet this well known port requirement. You need to do this to make NAT port forwarding work. I think this draft need specific actionable advice on what grounds the expert review can say No. Obviously violating any of the MUST in this draft is fine reason to say no - but beyond that it is just too vague. Next we come to the issue of if a new protocols is allowed or not. Cisco developed a new protocol - the retransmission and flow control part of it was stollen from another protocol that is an RFC. I viewed this as a good thing as it ensured that we did not reinvent something new that was broken. The IANA expert review felt that we should not make a new protocol and should instead extend the old one and would not approve the port. Eventually sanity prevailed and the port was allocated but it worth noting that when the port was approved, the product had already shipped and the port was fixed. Had IANA not allocated the port, Cisco would have just kept using the port anyways. I'll note most other vendors feel about the same way - if they need to build a product that needs a port, they will take a port, or more than one, if one is not allocated. This does not make me happy but I think we need to be realistic about what our grounds are for saying no and the probable result of say ing no. Along these lines, I have no idea what review guidelines the expert would use to decide if something was OK to be in the System port range instead of User. What would be an appropriate argument for System instead of User? Along these lines, I think the draft should contain an example registration for a protocol in the port range where the description of the protocol is not a reference to a document but is provided in this example - using an existing protocol such as HTTP might make it easier for everyone to read. Similarly be nice to have example for something in the System range. Anyways, my meta point is the draft need to give enough advice to the expert review that they know what to do. Of course the expert applies human intelligence but the review and applicants have to be on the same page about what is expected here. Small Issue #3: I object to anonymous review The current review is anonymous and this draft does not seem to change that. I don't like anonymous review - it's not how we do things at IETF and it encourages really bad behavior. I have several emails with an expert reviewer relayed via IANA where the conversation was going no where - once I knew the name of the reviewer, the whole conversation changed and stuff quickly came back to the realm of sane. I'm not willing to forward these emails to the list as that would just not be kind to anyone but I am happy to forward them to the IESG if they think looking at them is really critical. On Jan 18, 2011, at 14:26 , The IESG wrote: 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. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Feedback on Day Passes
On Nov 29, 2010, at 11:39 AM, Tobias Gondrom wrote: Bob, agree with James request for more detail on the used day passes, if possible. Personally, I believe the risen cost for day passes probably knocked out some of the demand (basic supply-demand curve from economics ;-) ). Probably day passes are more attractive to local participants who want to get a taste of the IETF or only visit one WG session. I you want to get a taste of IETF, you can do it for free. You join ISOC, which is free, then as an ISOC member you can come to IETF for free on the tuesday of any IETF meeting. You might not be able to go to the WG meeting you want if it is not on tuesday, but you can get a taste of IETF. I think this is a good thing and have encouraged people to do it - it's how we get new people to IETF. I know there are some people that disagree with me because it basically results in tourists at the meetings. So far the number people doing this is so low that it is not a problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Review of draft-saintandre-tls-server-id-check-12
The latest version of this draft resolved all my concerns. Thanks to everyone that put in all the time and effort. Cullen On Dec 16, 2010, at 12:17 AM, Cullen Jennings wrote: So let me start with I think there is great information in here and I think it should be published as a standards track RFC however I do think there are some issues with the relation with this draft and the realities of what would help improve security in deployment of SIP, HTTP, IMAP, XMPP etc. There are many places where this draft makes choices to improve the security from many current practices. At face value this seems like a good thing but it's not always. The thing reducing the overall security available to users of TLS is not if certs use CN-ID or DNS-ID, it is that it's such a PITA to deploy a TLS server that people choose to not use TLS at all. Everywhere there is a trade off between making things marginally more secure, or making things cheaper and easer to deploy, I think we need to seriously consider the cheaper and easier approach. Yes, some things are just broken even if they are easy and obviously we can't do those. Let me give an example of this. I looked at the cert for the domains for the authors of this draft. www.cisco.com has 3 DNS names even though as fas as I can tell one of these are for something that would typically be used in a ftp URI and the other HTTP URI. This is because it makes it easier and cheaper for them to use TLS yet seems t o go against the recommendation of this BCP. Then I went over the www.paypal.com domain which uses, gasp, a CN-ID. Do we really believe that paypal is seriously compromising their security by using a CN instead of URI-ID? If so, how? I'm pretty sure the paypal guys know how to run a secure web server. With the exception of Microsoft small business server certificates (which are outrageously expensive by the way) it pretty hard to get SRV name certs. In making these recommendations, did the TLS WG consider the relative prices of various types of certificates? Lets say I had a certificate for the domain example.org because I was using it for email and it has a CN because I got it years ago. Now lets say I am going to go deploy a SIP service on example.org. My position is that best way to encourage the use of security on the internet is to just reuse the certificate I have. It cheap, it's easy, it secure enough even if it does make you feel a bit dirty. I think Jeff disagrees with me, we argued for years about this topic and my understanding is his position is that it would be better to say that all new deployments MUST not use a CN name because it's less secure. Give the prevalence of CN on the internet today, I think it is fine to tell people how DNS-ID is better but I don't think it's OK to tell them they should not use CN-ID and I definitely don't think it is OK to tell implementors they don't need to implement CN-ID. I encouraged Chris to write this draft long ago and what we had discussed at the time was forming a RFC with one or more boiler plate pieces of text that could be used in creation of the name matching section of new protocols that got developed. I was thinking of something similar to the way we use rfc 5226 for writing IANA consideration section. Instead we have a document that is creating a very complex situations about whats normative. This draft is a BCP level, and it says you have to do everything in PKIX and PKIX takes precedence. That is basically elevating PKIX to a BCP without appropriate process review. Next this draft contradicts the procedures in existing protocols and says that it does not apply to the existing protocols but that it would take precedence over any future updates of existing protocols that use TLS within the scope specified here. I do not believe you have the consensus of the people woking on SIP that the next time some specification is marked as an UPDATE to 3261, that implementations need to implement the procedures in this draft. Furthermore, I think that would be counter productive. I think you should make it clear this guidelines for designers of new protocol and people updating existing protocol and that these protocols could make their own choices but would want to take into account the information in this draft. When I read the sentence, However, the best current practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so. I think that is exactly the right solution to the problem. However, that not a BCP, thats a standards track spec. Furthermore, I think this draft is going to have all the normal bugs etc of any other spec that defines algorithms and such it should proceed through the standards track process. If this draft is going to go as a BCP, that text contradicts
TSV-DIR Review of draft-ietf-mptcp-architecture-03
I have 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. Please consider these like any other last call comments, Summary: This draft is ready for publication as Informational. This draft is easy to understand and does a fine job of explaining the overall big picture of the solution without going into the details of the the design. In addition to being an architecture, it is also a set of requirements for the protocol design. It describes a protocol that is consistent with, and meets the goals of, the WG charter. I raise two minor issues which folks might want to consider but in my opinion it would be fine to publish the draft without any changes to address these issues. Minor Issues: I was a little surprised not to see any discussion of OOB data. Would this be support? send on both path? send only on one path? I wonder if anything needs to be said about TCP options - particularly the case where an application that thinks it is using TCP is actually dealing with MPTCP and the options are different on the two paths. Consider a hypothetical case like such as TCP Compression Filters. If an application had a socket level API to turn this on and off and see if it was working or not, and one path supported it but the other path went through an IDS systems that did not support it, what would happen? Perhaps all that needs to be said is that each option is separate and just because an given OS supports a specific option for TCP, it does not mean the option will work for MPTCP. From a practical point of view, when I look at the options in use today, this does not look like a big deal for MPTCP. Nits: On page 8 2n'd para from bottom, you have as a significant deployment bottleneck for any transport that is not TCP I think this should by changed to say TCP or UDP instead of just TCP ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-yevstifeyev-http-headers-not-recognized-08.txt ('Headers-Not-Recognized' HTTP Header Field) to Experimental RFC
I'm pretty surprised to see this in IETF LC - its not at the level where it is ready to have a WG start working on the idea. It's unclear what this draft is for, who wants it, or how it would work. Consider a HTTP request going to something like GAE. First some front end web gets the message, call this server A, it probably forwards on to separate web server running the python system, call this B, this pass on to a framework like say django, call this C, which passes on to end application call this D. It's really unclear what software is responsible for knowing which header each of A, B, C, and D supports or how the proposed header would get filled out in the response. It gets even more unclear as you start adding in caches, TLS accelerators, and such. It's not clear to me what the client would be able to do even if it had this information. I don't think this should be published until it has actually been discussed in the appropriate WG. On Dec 13, 2010, at 6:28 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - ''Headers-Not-Recognized' HTTP Header Field' draft-yevstifeyev-http-headers-not-recognized-08.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 2011-01-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-yevstifeyev-http-headers-not-recognized/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Review of draft-saintandre-tls-server-id-check-12
So let me start with I think there is great information in here and I think it should be published as a standards track RFC however I do think there are some issues with the relation with this draft and the realities of what would help improve security in deployment of SIP, HTTP, IMAP, XMPP etc. There are many places where this draft makes choices to improve the security from many current practices. At face value this seems like a good thing but it's not always. The thing reducing the overall security available to users of TLS is not if certs use CN-ID or DNS-ID, it is that it's such a PITA to deploy a TLS server that people choose to not use TLS at all. Everywhere there is a trade off between making things marginally more secure, or making things cheaper and easer to deploy, I think we need to seriously consider the cheaper and easier approach. Yes, some things are just broken even if they are easy and obviously we can't do those. Let me give an example of this. I looked at the cert for the domains for the authors of this draft. www.cisco.com has 3 DNS names even though as fas as I can tell one of these are for something that would typically be used in a ftp URI and the other HTTP URI. This is because it makes it easier and cheaper for them to use TLS yet seems to go against the recommendation of this BCP. Then I went over the www.paypal.com domain which uses, gasp, a CN-ID. Do we really believe that paypal is seriously compromising their security by using a CN instead of URI-ID? If so, how? I'm pretty sure the paypal guys know how to run a secure web server. With the exception of Microsoft small business server certificates (which are outrageously expensive by the way) it pretty hard to get SRV name certs. In making these recommendations, did the TLS WG consider the relative prices of various types of certificates? Lets say I had a certificate for the domain example.org because I was using it for email and it has a CN because I got it years ago. Now lets say I am going to go deploy a SIP service on example.org. My position is that best way to encourage the use of security on the internet is to just reuse the certificate I have. It cheap, it's easy, it secure enough even if it does make you feel a bit dirty. I think Jeff disagrees w ith me, we argued for years about this topic and my understanding is his position is that it would be better to say that all new deployments MUST not use a CN name because it's less secure. Give the prevalence of CN on the internet today, I think it is fine to tell people how DNS-ID is better but I don't think it's OK to tell them they should not use CN-ID and I definitely don't think it is OK to tell implementors they don't need to implement CN-ID. I encouraged Chris to write this draft long ago and what we had discussed at the time was forming a RFC with one or more boiler plate pieces of text that could be used in creation of the name matching section of new protocols that got developed. I was thinking of something similar to the way we use rfc 5226 for writing IANA consideration section. Instead we have a document that is creating a very complex situations about whats normative. This draft is a BCP level, and it says you have to do everything in PKIX and PKIX takes precedence. That is basically elevating PKIX to a BCP without appropriate process review. Next this draft contradicts the procedures in existing protocols and says that it does not apply to the existing protocols but that it would take precedence over any future updates of existing protocols that use TLS within the scope specified here. I do not believe you have the consensus of the people woking on SIP that the next time some specification is marked as an UPDATE to 3261, that implementations need to implement the procedures in this draft. Furthermore, I think that would be counter productive. I think you should make it clear this guidelines for designers of new protocol and people updating existing protocol and that these protocols could make their own choices but would want to take into account the information in this draft. When I read the sentence, However, the best current practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so. I think that is exactly the right solution to the problem. However, that not a BCP, thats a standards track spec. Furthermore, I think this draft is going to have all the normal bugs etc of any other spec that defines algorithms and such it should proceed through the standards track process. If this draft is going to go as a BCP, that text contradicts what a BCP is and needs to come out and the rest of the draft be adjusted appropriately. My preference would be that this draft be standards track. Its writing exactly the same sort of normative algorithm text that we
Re: Last Call: draft-salowey-secsh-uri-00.txt (Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)) to Proposed Standard
Several things in this draft surprised me a bit thought nothing looked completely broken. I You need an IANA registry for the parameters and a way new parameters get added Do you need to say anything about encoding when the host name is an IPv6 address? It says the fingerprint is in 4716 format but the examples have ssh-dss in them that does not look like that format. I would have expected they type of the fingerprint to be on the left not the right of the equal sign so instead of fingerprint=ssh-dss-c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63...@host.example.com I would have expected md5-fingerprint=c1-b1-30-29-d7-b8-de-6c-97-77-10-d7-46-41-63...@host.example.com I was surprised to see the c-param added to the user instead of the right hand side of URI so Instead of ssh://user;foo=...@example.com I would have expected ssh://u...@example.com;foo=bar I was surprised that the c-param required the equal so I can not have a parameter like useFooMode but must instead have a parameter like useFooMode=1 I'd be interesting hearing the logic or why the // - I'll point out XMPP, SIP, email, etc don't see to have this GIven a major use of SSH is SCP, I wish this URI worked for file paths as well The draft says This document is discussed on the IETF SSH list: ietf-...@netbsd.org I realize that was the list for the closed WG but I don't think that is an IETF list. It is not under IETF rules and is not listedhttp://www.ietf.org/list/nonwg.html. I would highly suggest moving the conversation to an IETF list. On Nov 17, 2010, at 11:58 AM, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Uniform Resource Identifier (URI) Scheme for Secure Shell (SSH)' draft-salowey-secsh-uri-00.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-12-15. 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-salowey-secsh-uri/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-salowey-secsh-uri/ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-simple-msrp-sessmatch
The new draft is clearer but I still don't think it addresses my concerns. I would say at this point they could be summarized as 1) The draft is very hard to review without doing the diffs to 4975. To try and help instead of just complain, I'm willing to go back patch these changes into the last XML for 4975 and provide a draft that we can actually read to see what this all means. I can't do that till after the -01 deadline. 2) As far as I can tell, this does change the security of 4975 in a pretty significant way in that this allows a MITM to masquerade with the wrong to and from path that may be in the cert. It is not clear how it work when the end points are not using self signed certs and changes the preferred deployment mode from using certs rooted in a trust anchor to self signed. All this seems to significantly weaken the security of 4975 which concerns me and I have not seen relevant discussion of all this. I am open to the idea that it does not making this much worse than they currently are in 4975 and that it is a reasonable trade off but I'd like to see concrete discussion of the issues and tradeoffs. How bad is it? how much worse is it? People says it is no worse but I and several others remain unconvinced that it is the same as 4975. I'd rather see a very explicitly discussion with people like the security reviewer about how much this changes things and if it is acceptable. It's not easy to sort this all out - it actually might be acceptable - I'm just not convinced yet and the there is no problem because there is not change form of argument is not convincing me - clearly there is a a change and at causal glance the point of that change seems to be to insert a MITM. 3) The backwards comparability issue seems huge. Some people have said an endpoint using this draft will not talk with one that only does 4975. Yet if this draft if published as an RFC would basically depreciate the 4975 and replace it with a the result of applying this diff to 4795. So if one person implements the pre update version, and another person the post - it's not clear to me how we migrate from old to new on the existing deployments. A flag day is obviously not going to work. The more I look at this, the more I think this draft needs to be recast as a backwards compatible extension to 4975 and not a draft that update 4975. When I look at how this changes 4975 it seems to mostly relax the existing security but not disallow things that used to work so I think it should be possible to do this. On a side note, I phoned a few people who I know that have MSRP implementation and none of them had any plans to implement this and were surprised to hear there was a draft that would update in 4975 with a change like this. To me this combined with the no backwards compatibility issue argues strongly for figuring out how to make this an extension instead of a change to MSRP. 4) When I search the email lists, I find more more people who see significant problems with this than I find people that seem to think it is OK. I don't think it has consensus -I think it just has people who stopped care. The changes that needed to happen in IETF LC to fix this draft so it had any chance of working at all more or less convinced me the WG did not read this draft. The ietf@ietf.org list is not an ideal location for discussion that rewrites pretty much all of the normative text of this draft (which is what is happening here). Cullen On Oct 5, 2010, at 1:33 AM, Gonzalo Camarillo wrote: Hi, Christer has submitted a new revision of this draft: https://datatracker.ietf.org/doc/draft-ietf-simple-msrp-sessmatch/ Those of you who sent IETF LC comments on this draft, could you please have a look at the new version and let Christer know if he has addressed your concerns? Thanks, Gonzalo On 31/08/2010 8:39 PM, Christer Holmberg wrote: Hi, The purpose of this e-mail is to address the secdir comments given by Richard Barnes and Ted Hardie. Due to summer vacations, standardization meetings etc it took a while to put the e-mail together, and we appologise for that. GENERAL === First, the draft does NOT propose any changes to the TLS authentication procedures – that will be clarified. The changes are only related to the procedure for matching an incoming MSRP message to an MSRP session that has been negotiated using SDP – once any TLS authentication procedure has already taken place. So, in case of TLS and name based authentication, if an SBC/ALG modifies the a=path MSRP URI, the TLS authentication WILL fail. That is the current behavior, and sessmatch doesn’t change that. We understand that this fact needs to be clearly indicated in the draft. Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBCs and SIP aware firewalls can be in the SIP signaling path without acting as MSRP B2BUAs. But, for an SBC or ALG to interwork correctly
Re: Abandoning draft-ietf-simple-interdomain-scaling-analysis
I think this is the best thing to do. This draft would need a lot of work and there is not the energy to do that. On Sep 29, 2010, at 7:46 AM, Gonzalo Camarillo wrote: Folks, the following draft was IETF LCed in July 2009. https://datatracker.ietf.org/doc/draft-ietf-simple-interdomain-scaling-analysis/ At this point, there does not seem to be interest in progressing this draft within the SIMPLE WG any longer (this issue has been discussed on the SIMPLE list recently). Therefore, I intend to move this draft to the dead state in the ID tracker shortly. If you have any comments, please let me know. Thanks, Gonzalo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Roll] Last Call: draft-ietf-roll-rpl-11.txt IPR Concern
I'm not closely involved with ROLL but I am working on devices using the CORE work that would likely make use of and depend on this protocol. I have some concerns about the practically of using ROLL given the IPR. My understanding of the IPR is that one would be required to use certificates that are from an CA license by Certicom. My belief is that the many of the low cost devices that would want to implement ROLL would be based on Linux implementation as that has become one of the most widely used operating systems for low cost networking devices such as residential routers. Given the optimal ways of integrating a protocol such as this into the kernel, and the issues of likening such as this in GPL code, I really wonder if the current IPR will be a major determent to deployment of ROLL. It's not easy to search the archives and I easily could have missed things but I can not find any significant discussion of it the WG could avoid this IPR. There were a few emails in July but it did not seem like it really hit this topic. I would have expected to see discussion on such topics as David McGrews draft on Fundamental Elliptic Curve Cryptography Algorithms or perhaps using RSA approaches. I think discussion about this IPR, and ways it could be avoided, would be appropriate before approving this draft. Cullen On Aug 18, 2010, at 4:28 PM, The IESG wrote: The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' draft-ietf-roll-rpl-11.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-09-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 https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ The following IPR Declarations may be related to this I-D: /ipr/1270/ /ipr/1356/ /ipr/1366/ ___ Roll mailing list r...@ietf.org https://www.ietf.org/mailman/listinfo/roll Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-ietf-simple-msrp-sessmatch
contain a port. The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device. A particular value of session-id is only meaningful in the context of the associated authority; thus, the authority component can be thought of as identifying the authority governing a namespace for the session-id. This proposal changes the concept of a namespace authority present in the URI matching section of RFC 4975. I am sorry if my wry reference to this in my previous message was hard to follow; I should have known better. To be more plain, this proposal fundamentally changes the matching semantics of the URI set out in RFC 4975, by requiring a match on only a portion of the URI. At a bare minimum, this would require noting a normative update to section 6 and 6.1 of RFC 4975, which this draft does not do. In reality, this is unlikely to be sufficient, as URI matching semantics do not generally have the concept of ignoring the authority in providing a match (at least in my reading of the RFC 3986 ladder of comparison text). That means you'd have to special case the MSRP matching semantics, rather than have the URI be parsed and compared using a standard library. Sessmatch removes the URI matching as a means to do MSRP session matching, and replaces it with a pure session-id matching. There is no need to create a new URI scheme that does not re-use the authority component. We believe the minimum 80-bit randomness of the session-id, together with the fact that the UA itself generates the session-id it matches on, to be enough for the session-id to be unique in the scope of the sessions that are active at the UA. I still believe that this requires special-casing the MSRP URI handling in any libraries that are meant to parse and match URIs. There is always a cost and risk to that kind of special-casing, and I remain less than convinced that using a URI here if you are not using URI matching makes much sense. Also, the security of the matching is not particularly decreased, since it is relatively easy to find out the authority name anyway. I also note that the security considerations, in addition to having some fairly disingenuous language about the impact of this change, seems to fail to mention MSRPS URIs and what, if any, impact this would have on them. There are no impacts to MSRPS URIs. I assumed it would be implicitly understood since MSRPS URIs are not mentioned in the draft. However, we could explicitly make it clear by modifying the first sentences of section 5: The change of session matching procedure does not impact the format of MSRP URIs, disregarding if the msrp scheme or the msrps scheme is used. However, MSRP endpoints can only check that the session-id part of the MSRP URI... This doesn't seem to me to actually work, based on Richard's comments, unless what you mean to say is if MSRPS is in use, nothing in this draft can be used. That gives you different matching semantics for MSRPS (authority must be present and must be matched using TLS semantics) vs MSRP (only session-id is checked) which is at the very least a violation of the principle of least surprise (no other foo over TLS protocol works that way that I know of ). Session matching is done when receiving MSRP packets on an already established TCP or TCP/TLS connection, and there will not be any different session matching procedure depending on if the connection uses TLS or plain TCP. Thanks again for the clarifications, Ted Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Dedicated list for technical discussions
On Aug 28, 2010, at 18:06 , Mark Nottingham wrote: I know it's been brought up many times before, but I'd appreciate a separate list for technical discussions regarding drafts, etc., since this list seems to have become a travel tips forum. +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Tourist or business visa from US?
Wow, I find this whole email thread shocking. Given the text explanation you get of F and L visa from the embassy web site, which Mary quoted below, I have a very hard time seeing how anyone comes to the conclusion that L (tourist) visa is the right visa for an IETF meeting. I believe the the explanations that you are likely to get away with it, but I have a very hard time believing it is not breaking the law. I'd be fascinated to hear the reasoning of people who think it is legal. On Aug 24, 2010, at 9:21 AM, Mary Barnes wrote: The note posted suggested that if you were planning to sightsee a day or more before or after the meeting that a tourist visa might be sufficient. However, I prefer to err on the side of caution in this situation since it clearly states on the chinese visa website: Business Visa (F Visa) is issued to an alien who is invited to China for a visit, an investigation, a lecture, to do business, scientific-technological and culture exchanges, short-term advanced studies or internship for a period of no more than six months. versus Tourist Visa (L Visa) is issued to an alien who comes to China for sightseeing or visiting family members or friends or for other personal affairs. Personally, I'd rather not risk any problems in this area. Since, my company is sponsoring to attend the meeting, I don't consider that I'm going to China for personal affairs. In my experience, you're typically asked why you're visiting a country and sometimes the questioner wants more details as to what you'll be doing. So, unless you have figured out a detailed sightseeing itinerary in advance, I would think it's possible you could easily answer that question unsatisfactorily. Just my opinion, Mary. On Tue, Aug 24, 2010 at 9:43 AM, Andrew G. Malis agma...@gmail.com wrote: Is there a consensus that a tourist visa is sufficient to attend the IETF from the US? Thanks, Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
Bob, Thank you for providing this but this data seems to support something closer to 2-1-1 than 1-1-1. How do you get to the 1-1-1 conclusion because I can't figure out how to get there with this data. It seems tome the ratio of NA To Asia is closer to 2 than 1 any way you slice it. Cullen (and sorry I just joined the thread now - been on vacation ) On Aug 6, 2010, at 2:44 PM, Bob Hinden wrote: During my IAOC chair plenary talk at IETF78 (slides are in the proceedings) I asked a question about continuing the current meeting policy (3 in North America, 2 in Europe, 1 in Asia in two year period (3-2-1) ) or changing to a 1-1-1 policy based on current meeting attendance. The talk included a graph of attendance by continent for IETF72-IETF78. I was asked to provide this data to the community. It is attached. It includes the raw data and a new graph that shows attendance by percentage. It appears to me that a 1-1-1 meeting policy is justified by current overall IETF meeting attendance. Your comments are appreciated. Bob AttendanceByContinent.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
I read the thread, but I still don't see how people come to 1-1-1, could you enlighten me. Seriously, I know this sounds facetiously but in the case, I really am trying to understand how you come to that conclusion out of this data. On Aug 26, 2010, at 3:18 PM, Dave CROCKER wrote: On 8/26/2010 2:08 PM, Cullen Jennings wrote: Thank you for providing this but this data seems to support something closer to 2-1-1 than 1-1-1 ... (and sorry I just joined the thread now - been on vacation ) Cullen, The rest of the thread explored this issue by a number of us, looking at it in different way. Is your push-back to Bob based on a review of that additional discussion? I'm asking because I took there to be a reasonable consensus from that that 1-1-1 made the most sense. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Huge number of subscriptions disabled on ietf lists
Yesterday a roughly 50 people seem to have been unsubscribed from of the ip...@ietf list - It's possible this is perfectly normal but it struck me as sort of weird. Are others seems stuff like this on other lists? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: web security happenings
On Jul 13, 2010, at 22:26 , Iljitsch van Beijnum wrote: On 13 jul 2010, at 18:49, Peter Saint-Andre wrote: fun technologies like AJAX but also opens up the possibility for new attacks (cross-site scripting, cross-site request forgery, malvertising, clickjacking, and all the rest). Isn't this W3C stuff? It's important stuff - if they are not making progress on it, some SDO with people that have skill and expertise in this area should do work on it. A BOF is a great way to find out if we have people with the expertise and the interest to do work. My gut feeling is that we probably do. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Call Control UUI for SIP (cuss)
I don't think this resolves the issue. The issue is if this information is used for a call control. Basically do proxies need to be able to look at this to make decision about what they are going to do. We at least need a Yes/No answer to this question from the proponents of this work and the charter to make that clear. On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote: Hi, thanks for your comments on the charter proposal. Per the comments received, we will modify bullet 5 as follows so that it is clearer: OLD: 5. SIP elements may need to apply policy about passing and screening the information. NEW: 5. SIP elements may need to apply policy about passing and filtering UUI. The included application, encoding, semantics, and content information will allow endpoint or intermediary SIP elements to allow or block UUI based on the type and originator, not based on the actual UUI data, which may be end-to-end encrypted by the application. Further discussions on this topic should happen on the mailing list of this WG. Cheers, Gonzalo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Call Control UUI for SIP (cuss)
OK - that removes a large part of the issues I raised. Let me see if I can propose some text that we could all agree on. Cullen PS - Just to be clear these emails are all in my individual contributor role. That was clear when it was IETF LC comment but given this is all cross posted to dispatch, just wanted to be clear. On Jul 15, 2010, at 8:07 AM, DOLLY, MARTIN C (ATTLABS) wrote: Cullen the answer to your question is No. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cullen Jennings Sent: Thursday, July 15, 2010 10:06 AM To: Gonzalo Camarillo Cc: DISPATCH list; IESG IESG; IETF-Discussion list Subject: Re: WG Review: Call Control UUI for SIP (cuss) I don't think this resolves the issue. The issue is if this information is used for a call control. Basically do proxies need to be able to look at this to make decision about what they are going to do. We at least need a Yes/No answer to this question from the proponents of this work and the charter to make that clear. On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote: Hi, thanks for your comments on the charter proposal. Per the comments received, we will modify bullet 5 as follows so that it is clearer: OLD: 5. SIP elements may need to apply policy about passing and screening the information. NEW: 5. SIP elements may need to apply policy about passing and filtering UUI. The included application, encoding, semantics, and content information will allow endpoint or intermediary SIP elements to allow or block UUI based on the type and originator, not based on the actual UUI data, which may be end-to-end encrypted by the application. Further discussions on this topic should happen on the mailing list of this WG. Cheers, Gonzalo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On Jul 5, 2010, at 10:05 AM, Alissa Cooper wrote: A few months ago I drew up a strawman proposal for a public-facing IETF privacy policy (http://www.ietf.org/id/draft-cooper-privacy-policy-00.txt). I've submitted an update based on feedback received: http://www.ietf.org/id/draft-cooper-privacy-policy-01.txt In discussing the policy with the IAOC and others, it seems clear that the RFC model is probably not the best model for maintaining and updating a document like this. It is more likely to fall within the scope of the IAOC and/or the Trust. In order for the IAOC to consider taking this on and devoting resources to figuring out what its format should be, they need to hear from the community that a public-facing privacy policy is something that the community wants. So I have two requests for those with any interest in this: 1) Respond on this list if you support the idea of the IETF having a privacy policy (a simple +1 will do). +1 2) If you have comments and suggestions about the policy itself, send them to this list. I would be very happy if the IETF adopted the privacy policy proposed in your draft. It seems to me the work of writing an acceptable policy is 90% done and the arguments that creating a privacy policy will detract from other work are pretty weak. It's a volunteer organization, people vote with their feet with what they want to work on. Just because Alissa spend time writing a policy document does not mean that time would be directed to other things if we did not want to do a privacy policy document. I don't think that having a privacy policy is going to bring a bunch of new contributors to the IETF, but I can imagine a case where the lack of a privacy policy caused some administrative group to do something really unfortunate which resulted in some good people leaving the IETF. A privacy policy is not something the IETF typically has a lot of people that are really experienced and qualified to draft. But we are very lucky here - we have multiple people that understand IETF culture and values, understand internet privacy policies and laws, and are willing to write a proposal. Unless this proposal is deeply flawed in some way I can't see, why wouldn't we just do it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Call Control UUI for SIP (cuss)
On Jul 3, 2010, at 7:33 AM, Alan Johnston wrote: Many of us have worked hard on this approach over many years, and you have been involved in this at every step of the way, in both SIPPING and DISPATCH. For you to just try to block even the formation of a working group to address this at this eleventh hour is just not right. For better or worse, the AD's voice do strongly impact others thinking on the many subjects at IETF. As an individual contributor, my review in IETF LC pretty much my current thoughts on it. However, if I had sent that same review when I was an AD this charter would have been very unlikely to get a fair shake at moving forward so I just would not have sent that email while I was AD. The ADs often can't express their own opinions because and instead have to just try and measure community consensus and go with that even if it does not match what they think is best. Really this is the first chance I've had to express an opinion on this where I was not one of the RAI AD. There discussion that has happened since my initial review has made me wish I had said a bit more about SIP-T in my first email. I'm not really proposing that someone should have to implement all of ISUP processing and SIP-T just to pass around the UUI field but from a thought experiment point of view, this does not sound like it is going to provide anything that we would not get if we did implement SIP-T to pass this data. It seems this will have all the limitations of SIP-T combined with the interoperability limitations of UUI in ISDN. I want to be clear, I'm not trying to stop us from doing some work that helps supports uses cases such as the one Laura sent to the list. I just don't see this charter as leading to any improvement in interoperability. If we agree that in theory we could more or less do this with SIP-T thought that is not a practical path from an implementation point of view, then I can see a path of some middle ground. If we don't agree on that then we proba bly need to think about what we need to add to the charter regardless of if I agree with or not that high lights the additional part of this problem that makes it so SIP-T can't solve it. The other things that has happened in this discussion is that I was assuming that the proponents of this felt that proxies needed to modify the data. From the email that came out it's became clear that not everyone believed that. If there was consensus on changing this such that UUI information is not meant for proxies, then I can start to see ways to rewrite the charter to have it reflect what I think people want to do. If the consensus is proxies need to look at this, I have a hard time seeing how it is not involved in call control. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)
...@ietf.org] On Behalf Of Gonzalo Camarillo Sent: Wednesday, June 30, 2010 2:51 AM To: Paul Kyzivat Cc: dispa...@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Hi, please keep both the IETF and the DISPATCH mailing lists in the recipients list in this discussion. Cheers, Gonzalo On 29/06/2010 8:23 PM, Paul Kyzivat wrote: DRAGE, Keith (Keith) wrote: The UUI information is NOT ISUP. It is a transparent envelope to the entire ISDN, so it is not part of an ISDN protocol and therefore not part of an ISUP protocol. When carried by ISUP the envelope is bundled up in another envelope with other information that ISUP carries transparently. So I believe, and have said repeatedly in the past, that references to SIP-T are irrelevant in this case. The problem we do have though is that are legacy usages of this information. In particular applications in PBXs carry it between themselves in ISDN call establishment. The information itself is not standardised. If you want to migrate a PBX from DSS1 to SIP, then you have to take this information into account. The desire is not for a WG group to standardise this existing usage (which in my view would be a complete non-starter), but to allow the transfer of the existing information when migrated to a SIP environment. The information transferred does not form part of SIP, and should not be standardised as part of SIP. How many different mechanisms do we have to construct for the purpose of tunneling stuff over SIP? Its especially bad if the stuff is neither standardized nor negotiated. It then just provides more opportunity for non-interoperability. It had been my impression that this content was standardized by ITU. If nobody can bother to standardize it, then it hardly seems worth working on. Thanks, Paul regards Keith -Original Message- From: dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] On Behalf Of bruno.chat...@orange-ftgroup.com Sent: Tuesday, June 29, 2010 1:00 PM To: gonzalo.camari...@ericsson.com; dispa...@ietf.org Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 does state that SIP-T does not come into play when there is no PSTN involved. At the end of clause 2 we can read the following: 4. IP origination - IP termination: This is a case for pure SIP. SIP-T (either encapsulation or translation of ISUP) does not come into play as there is no PSTN interworking. Besides, SIP-T would require encapsulating a full ISUP message (e.g. IAM) while we are interested in just one parameter of the message in the context of CUSS. This would I believe be a more severe drawback if SIP-T were used for this purpose. Bruno -Message d'origine- De : dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] De la part de Gonzalo Camarillo Envoyé : mardi 29 juin 2010 13:03 À : DISPATCH Objet : [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Hi, FYI: note the discussion below on the IETF general list. Cheers, Gonzalo Original Message Subject: Re: WG Review: Call Control UUI for SIP (cuss) Date: Mon, 28 Jun 2010 20:24:23 +0200 From: Cullen Jennings flu...@cisco.com To: i...@ietf.org i...@ietf.org CC: IETF Discussion Mailing List ietf@ietf.org As far as I can tell, the WG says they wants to transfer some information to achieve cross vendor interoperability. However, what I believe the charter is actually going to do is exactly the opposite of that. When you get your head around what this charter is proposing, it is going to form a more or less opaque container for transporting proprietary information in a SIP header. It's hard to imagine how this will help interoperability. If we wanted to have interoperability, the charter would say what information needs to be transferred and have the WG define a way to get it between systems in an operable way. What the charter for this WG actually says they are going to do is make a special container for transfer proprietary information. There's not even willing to say what that proprietary information is used for other than things ISDN UUI which is a non interoperable and fairly proprietary field in ISDN. Furthermore they have asserted that existing containers such as SIP-T or SIP bodies can't be used for reasons that are hard to describe. (I reject the idea that because the call might not involved the PSTN, it can't use SIP-T). I think the folks that want to do this should get a much clear explanation of how this results in interoperability and why exist approach such as SIP-T will not work before this is chartered. I do think there is a need to standardize some important call control
Re: [dispatch] VIPR - proposed charter version 3
The user surprise is problem is largely masked by the user preference problem so in practice it is not a big deal. Let me explain what I mean by this. I have a video phone on my desk and so does my boss and they are on the same PBX and can trivially do video between each other. However, when my boss calls the number of my video phone, he does not actually expect to get video. My preferences may have totally turned that off. I may have forwarded the phone to my cell phone. I may have just muted the camera because I am wearing a jacket and tie and would not want him to catch me in that. The call may go to voice mail because I was on another call. Users are not particularly surprised when the video is not there. Similarly, they are not very surprised when the audio quality is radically different than they might have hoped due to the other parties preference. My boss's phone and mine both do wideband audio but we are not surprised when we don't get that. Audio preferences included putting people on speaker phones, using just about mobile phone and so on, taking calls while riding a bike a nd so on. But let's not get too wrapped up in this. This whole topic is a non issue with a validation scheme that transferred some random secret in the first second of the PSTN call then did real time validation followed by moving the call (still in first few seconds of the call) from the PSTN to the IP network. One can imagine how to insert this into the audio by using watermarking or by fingerprinting existing media. A validation scheme like this is much better than the start/stop time based one proposed in the current vipr drafts but unfortunately it requires changing something in the media path at both ends and doing that takes longer to deploy. So the current validation scheme is pretty easy to get rolled out as everything was already collecting CDR in some form but a media path validation scheme could work in real time instead of waiting to the end of the PSTN call to validate. On Jul 6, 2010, at 9:00 AM, Peter Musgrave wrote: Yeah. Sigh. I guess the issue then becomes whether this is enough of a step in right direction that it can be built on - and whether it's worth the effort. Cullen/Jonathan - can you speak to any of the operational issues w.r.t. 'failure surprise' in the existing implementation? Regards, Peter Musgrave On Tue, Jul 6, 2010 at 10:28 AM, Adam Roach a...@nostrum.com wrote: On 7/6/10 7:20 AM, Peter Musgrave wrote: From my perspective what this is really about is the ability for me to have interoperable ad-hoc video calls between businesses which can be established via SIP with a good enough level of authentication and security. You're looking in the wrong place, then. The problem is that VIPR really provides something more like random failure surprise, as some portion of the call attempts must go over the (non-video-capable) PSTN. The user doesn't have any idea about, or control over, when this will happen. So while it might be something you could use for personal purposes -- where frequent video call setup failures would be okay -- I doubt it's a viable video solution in a business environment. To run a business, you need something better than random failure surprise. /a ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Call Control UUI for SIP (cuss)
On Jun 29, 2010, at 3:25 AM, Elwell, John wrote: Cullen, Whilst neither agreeing nor disagreeing with the charter, I did not find anything in the charter that said the information had to be in the SIP header rather than in the body. On what basis do you make that deduction? John When I read 5. SIP elements may need to apply policy about passing and screening the information. And the discussion about it's not just UA. I reached that perhaps flawed conclusion that proxies needed to be able to change the information when screening and thus it needed to be in a header. Note I would have far less of an issue with an opaque container for proprietary information if it was in a body instead of a header and had the types of constraints that SIP-T has. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Call Control UUI for SIP (cuss)
centers, call centers, and automatic call distributors (ACDs). A major barrier to the movement of these applications to SIP is the lack of a standard mechanism to transport this information in SIP. For interworking with ISDN, minimal information about the content of the UUI is available to the PSTN-SIP gateways. In this case only, the content will just indicate ISDN UUI Service 1 interworking rather than the actual content. Call control UUI is user information conveyed between user agents during call control operations. As a result, the information must be conveyed with the INVITE transaction, and must survive proxy retargeting, redirection, and transfers. The mechanism must utilize a minimum of SIP extensions since it will need to be supported by many simple SIP user agents such as PSTN gateways. The mechanism must interwork with the existing ISDN service but should also be extensible for use by other applications and non-ISDN protocols. Even though interworking with the PSTN is an important requirement, call control UUI can be exchanged between native SIP clients that do not have any ISUP support. Therefore, existing SIP-T encapsulation-based approaches defined in RFC3372 do not meet the requirements to transport this type of information. Mechanisms based on the SIP INFO method, RFC2976, will not be considered by the working group since the UUI contents carry information that must be conveyed during session setup at the user agent - the information must be conveyed with the INVITE transaction. The information must be passed with the session setup request (INVITE), responses to that INVITE, or session termination requests. As a result, it is not possible to use INFO in these cases. The group will produce: - A problem statement and requirements document for implementing a SIP call control UUI mechanism - A specification of the SIP extension to best meet those requirements. Goals and Milestones Sep 10 - Problem statement and requirements document to IESG (Informational) Mar 11 - SIP call control UUI specification to IESG (PS) ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-simple-msrp-sessmatch (Session Matching Update for the Message Session Relay Protocol (MSRP)) to Proposed Standard
This draft is a standards track update to MSRP that mandates that MSRP allow man in the middle attacks. I am strongly opposed to this change and feel that it would be a violation of the spirit of BCP 61 as well as just a bad idea. The security is OK is based on the idea that MITM attacks are already possible so this makes it now worse - see section 5 where it says However, since a man-in-the-middle would in any case be able to modify the domain information in both the SDP and the MSRP messages I don't agree with the assumption that SIP can not protect against MITM attacks and therefore it is OK to mandate support for MITM attacks in MSRP. Who did the security review for this draft? Cullen MSRP co author On Jun 7, 2010, at 8:40 AM, The IESG wrote: The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'Session Matching Update for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-sessmatch-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-21. 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-simple-msrp-sessmatch-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=19446rfc_flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Simple] Last Call: draft-ietf-simple-msrp-acm (An Alternative Connection Model for the Message Session Relay Protocol (MSRP)) to Proposed Standard
I can not see why this draft is needed other than making MITM attacks easier. I request that this not proceed until we can figure out what is going to happen to draft-ietf-simple-msrp-sessmatch then decide if these changes to MSRP are needed or if the existing mechanism are sufficient. On Jun 7, 2010, at 8:39 AM, The IESG wrote: The IESG has received a request from the SIP for Instant Messaging and Presence Leveraging Extensions WG (simple) to consider the following document: - 'An Alternative Connection Model for the Message Session Relay Protocol (MSRP) ' draft-ietf-simple-msrp-acm-09.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-21. 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-simple-msrp-acm-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=18161rfc_flag=0 ___ Simple mailing list sim...@ietf.org https://www.ietf.org/mailman/listinfo/simple Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
I support this change. Cullen PS - and when I read the ietf@ietf.org mailing list, I am often convinced I don't understand the culture of the IETF so I am glad to note the IESG only talks about what is clearly not sufficient and makes no implications about what might be sufficient to understand the IETF. I agree the current scheme does not ensure the best nomcom but it's better than any other proposal we have on the table. On May 6, 2010, at 4:07 PM, The IESG wrote: The IESG is considering the following Statement on the Day Pass Experiment. The IESG plans to make a decision in the next few weeks on a policy statement, and the IESG actively solicits comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-20. 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. = = = = = = = = RFC 3777 requires that voting members of the nominating committee (NomCom) be selected from volunteers that have attended at least three of the last five IETF meetings. The IAOC is conducting a day pass experiment, making it necessary to augment the NomCom eligibility rules to address IETF participants that make use of a day pass. An update to RFC 3777 to will be needed to address this situation if at the end of the experiment the IAOC decides to make day passes a regular meeting registration alternative; however, a BCP update for an experiment is overkill. The IESG observes that attending a single day of the IETF meeting is not sufficient for a new participant to learn the culture of the IETF or the qualities that would make an effective IETF leader. Further, ongoing exposure to the IETF standards process is necessary to appreciate the significance and importance of cross-area review. The eligibility requirements of volunteers for NomCom voting member positions are provided in RFC 3777, which includes: 14. Members of the IETF community must have attended at least 3 of the last 5 IETF meetings in order to volunteer. In the context of the day pass experiment, this is interpreted to mean: 14. IETF participants must have attended at least 3 of the last 5 IETF meetings in order to volunteer, and that use of a day pass does not count as IETF meeting attendance. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: Policy Statement on the Day Pass Experiment
Spencer, I think the right way to fix this problem is to allow anyone who self declares themselves as currently unemployed get a significantly reduced rate for a 5 day pass (perhaps the same rate as 1 day pass). I know this could be abused by people who are self employed consultants but given the type of people that are self employed consultants and that choose to come to IETF, I don't think it would be abused. Cullen On May 6, 2010, at 10:51 PM, Spencer Dawkins wrote: Dear IESG, I'm conflicted on this one. I agree that three days at IETF meetings does not a NomCom member make, but I know several people who are very experienced, but who are self-funding, and I can easily imagine someone doing a day pass during a trough in their business cycle. I would be comfortable allowing someone volunteering for the NomCom membership pool to count ONE IETF attended on a day pass - not more than that. Allowing a day pass as one of your three of five doesn't seem dangerous to me, and if you DID attend two tutorials, the reception, the social, and a day of IETF meetings, you certainly could have inhaled some IETF culture. Considering how many NomCom volunteers we get, tuning the algorithm may not affect the membership of a NomCom more than once out of twenty years, of course, so please don't spend much time tuning the algorithm! Thanks, Spencer The IESG is considering the following Statement on the Day Pass Experiment. The IESG plans to make a decision in the next few weeks on a policy statement, and the IESG actively solicits comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-20. 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. = = = = = = = = RFC 3777 requires that voting members of the nominating committee (NomCom) be selected from volunteers that have attended at least three of the last five IETF meetings. The IAOC is conducting a day pass experiment, making it necessary to augment the NomCom eligibility rules to address IETF participants that make use of a day pass. An update to RFC 3777 to will be needed to address this situation if at the end of the experiment the IAOC decides to make day passes a regular meeting registration alternative; however, a BCP update for an experiment is overkill. The IESG observes that attending a single day of the IETF meeting is not sufficient for a new participant to learn the culture of the IETF or the qualities that would make an effective IETF leader. Further, ongoing exposure to the IETF standards process is necessary to appreciate the significance and importance of cross-area review. The eligibility requirements of volunteers for NomCom voting member positions are provided in RFC 3777, which includes: 14. Members of the IETF community must have attended at least 3 of the last 5 IETF meetings in order to volunteer. In the context of the day pass experiment, this is interpreted to mean: 14. IETF participants must have attended at least 3 of the last 5 IETF meetings in order to volunteer, and that use of a day pass does not count as IETF meeting attendance. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Apr 6, 2010, at 16:47 , Bernard Aboba wrote: Hadriel Kaplan said: “Howdy, This may not be within the normal rules of etiquette, but I will re-iterate my issues with this draft which I raised when it was discussed in RAI. 1) The mechanism does not scale, for large SSP's. (is this only meant for small deployments?) Expecting every UA to keep a permanent SIP Subscription to config change servers is unreasonable. Either the UA makes this Subscription directly to the Server(s), in which case there will be a large volume of keep-alives just to keep NAT pinholes alive; or it makes it through edge proxies, in which case it's a lot of SIP messaging both in the sense of keeping the Subscribe dialog alive but more importantly at the worst possible time: during avalanche restarts. Either way, it's not good. All this state and signaling is to achieve what? So that once a year or so we can tell UA's to do another HTTP Get so they change one of their config settings, or upgrade their firmware?? How is that cost-burden justified? Do most other applications keep permanent connections for such changes? Not as far as I can tell. They poll on a (very) infrequent interval. 2) I would be ok with (1) if it was optional, so only providers that wanted it had to pay for it, but as far as I can tell the mechanism *requires* implementation of this SIP Subscription service. Maybe I'm reading it wrong? Section 2.5.1 says the HTTP response MUST have the Link header, with a SIP URI, and if the Subscription attempt fails then it has to start again, etc. Seems to me you're requiring/mandating a nice-to-have-feature, and an expensive and complicated one at that. Why? -hadriel ” [BA] I agree with your assessment. This is one of those situations where (infrequent) polling scales better. That is how currently most OS update mechanisms work; they poll the update servers at intervals orders of magnitude longer than NAT refresh times (e.g. weekly or daily at most), with randomized polling times. That way there is no need to maintain NAT bindings, and no danger of “flash crowds”. Yes, it might take a while to bring all the clients up to the latest version, but if you’ve got any substantial client population, then you need to spread out the updates anyway to control the load on the update servers. So there are somethings like upgrading the software firmware on phones where a slow roll over makes sense, however there are other things like moving from a 4 digit to 5 digit internal dialing plan where you want to flash cut over all the phones at a given site. Can you imagine telling a site, uh, your phone will switch from 4 to 5 digit dialing some time in the next few days - if 4 digit stops working, try 5 digits and see if that works. That the sort of think that generates support calls that are far more expensive than servers. I realize that if you put the poll rate low enough, polling can achieve the same as notification but the rates required for many services make notification scale better than polling. In my experience, even where NOTIFY is used to provide update notifications today, SUBSCRIBE is not. Yes, that is non-standard, but I think it demonstrates concern about the overhead relating to SIP subscription/refresh. __ Having dealt with many or the problems that come from setting MWI lights using NOTIFY without subscribe I am fairly confident that this NOTify without SUBscribe is broken is some many ways it is not even worth discussing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Apr 8, 2010, at 13:51 , Scott Lawrence wrote: Perhaps our fundamental disagreement is whether or not having a prompt way to reconfigure a UA is a requirement. When the SIP Forum chartered this work, it was agreed that that was requirement (and I certainly think it is). I think that a configuration mechanism that does not allow for updates under the control of the service won't be successful. +1 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ok .. I want my IETF app for my iPad ..
And if you shake it violently, all the discusses clear Seriously, I would like to have an app where I could read drafts, and make free form annotations on top of them like circling things in red, then check the annotations back into SVN or something like that were other people such as authors could sync and get my annotations. If the app could work off the xml version of the draft, it could be even nicer about inserting comments into the XML source for the draft. Another nice app might be something where I just flag the WGs I go to and it downloads the agenda for the meeting, gathers the drafts on the agenda, and puts them all in a book to read. I realize we have much of this already. Perhaps an app that gave you roughly all the information that is in the data tracker but could cache the data so you could use it offline on a plane. Nothing particular to the ipad on this app, but it would be a nice app to have. Seems like a great HTML5 summer project for some student. Cullen PS - Is anyone working on any cool IETF related ipad apps? On Apr 3, 2010, at 7:20 PM, Dave CROCKER wrote: On 4/3/2010 6:11 PM, Ole Jacobsen wrote: And what, pray tell, does an IETF app actually do? A squeeze of the fingers tightens a spec. Flicking sends it to the RFC Editor. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
So I agree with Hadriel that we want the document to be very clear on what code the implementors need to write but I'm not exactly seeing the confusion. Perhaps I need to go reread the doc from that point of view. However,I did want to comment on the use cases for this. There are many service providers that think it is important to be able to push a new configuration to a UA quickly and the definition of quickly varies widely. Imagine the case where someone is having problems getting their fax to work and the SP wants to change the preferred codec from 729 to 711. Now I realize you could do that by using an SBC that forced negation to only 711 but that would reduce the flexibility of the system. Some operators want to be able to change the config on the UA. I have talked to some that seem fine with the idea that the UA would poll ever 24 hours or that the end user user would need to power cycle the UA. I have talked to others that think that is totally unacceptable and need to be able to trigger something that causes the UA to get the new config in something more like 30 seconds. Different folks have different ideas of how fast you need to be able to update this however when you star t talking about how fast people would like to roll out fix to a security of DOS attack problem, all the service providers I have talked to start talking about much faster times than 24 hours. I'm sure there are some deployments where polling would be fine but there are lots that don't find this acceptable. On Apr 5, 2010, at 3:55 PM, Hadriel Kaplan wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott Lawrence Sent: Monday, April 05, 2010 3:55 PM On Mon, 2010-04-05 at 15:09 -0400, Hadriel Kaplan wrote: This form of optional is right up that alley. For example, if I am a service provider who wants to not have Subscription mode, and the only way to do it is through UA config framework itself by setting a config field for Subscribe-UA-Config=false or whatever, then clearly the UA's MUST use the config. A MAY statement does nothing. The draft is clear that the configuration data can modify any part of the procedures in the draft. Section 2: The User Agent MAY obtain configuration information by any means in addition to those specified here, and MAY use such information in preference to any of the steps specified below, ... But all that statement is clear about is that it's NOT clear - not clear what the UA will do, in practice/implementation. Leaving it up to the UA to decide what to do does nothing to assure the service provider of anything. I'm not trying to be difficult (really!) - I'm just asking: imagine I'm a service provider. I want my users to go into a Best-Buy/Wal-Mart/whatever and buy a SIP phone, plug it into the Internet, download some config stuff from my Apache HTTPS servers, and work. Can I do that, without having to also deploy SIP Subscription servers? As I read this doc, I cannot. So if you're looking for an escape clause, you've found it, but the rest of the sentence is important ...but MUST be capable of using these procedures alone in order to be compliant with this specification. Yes, I read that and was thoroughly confused. :) I think that the wording of that particular statement is perhaps unfortunate, but have not found a better one. In effect, what we were trying to do is express that the UA is not required to wait until the subscription exists to use the data, and can continue to use the data should the subscription fail for any reason. This prevents various failure modes and/or delays in the UA when the Configuration Service is overloaded or otherwise unavailable. It's not an 'optional requirement' it's a non-requirement. But saying the UA is not required to do Foo is NOT the same as saying the UA is required to not do Foo. In effect, any and all UA's in the Universe can meet the former, but only some can meet the latter. What I mean is, with this language, ALL UA's automatically comply with the RFC, but only *some* will actually use their config without waiting for a subscription. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Apr 6, 2010, at 10:16 AM, Hadriel Kaplan wrote: -Original Message- From: Cullen Jennings [mailto:flu...@cisco.com] Sent: Tuesday, April 06, 2010 11:53 AM To: Hadriel Kaplan However,I did want to comment on the use cases for this. There are many service providers that think it is important to be able to push a new configuration to a UA quickly and the definition of quickly varies widely. Imagine the case where someone is having problems getting their fax to work and the SP wants to change the preferred codec from 729 to 711. Now I realize you could do that by using an SBC that forced negation to only 711 but that would reduce the flexibility of the system. Some operators want to be able to change the config on the UA. I have talked to some that seem fine with the idea that the UA would poll ever 24 hours or that the end user user would need to power cycle the UA. I have talked to others that think that is totally unacceptable and need to be able to trigger something that causes the UA to get the new config in something more like 30 seconds. Different folks have different ideas of how fast you need to be able to update this however when you start talking about how fast people would like to roll out fix to a security of DOS attack problem, all the service providers I have talked to start talking about much faster times than 24 hours. Right, so what happens if the Subscription *is* the DoS attack? I'm not saying this to be cute - we need a way to turn it off, and have it off to start with (i.e., on reboot). No one has any empirical evidence or experience with what this thing will do to large subscriber domains. (and by large I mean multiple millions of UA's, which is the scale several SIP deployments are in now) I'm aware of deployments with millions of UAs that use subscribe. Agree there are growing points in scaling anything and everything As you know, there were several painful growing pains in the past in large subscriber domains with unforeseen UA behavior. Similar issues cropped up again when reg-event Subscriptions started getting deployed. If what we really want is something to force the UA to download a config *right now*, then do that explicitly. Give each registered UA a private gruu, known only to the SSP and UA. When you want to refresh the UA, send a PUBLISH to the gruu, telling it to refresh its config. You can do that gruu statelessly on the SSP side, any number of ways. I care more there is a way to do it than how it is done but can you explain how that is lighter weight than a subscribe? I would think that a subscribe could be done stateless on the SSP too given the usual state in dialog information techniques. I get how using a register to form an implicit subscribe would reduce the traffic of the initial subscribe formation and that might be a interesting optimization for someone to go write a draft on. I'm sure there are some deployments where polling would be fine but there are lots that don't find this acceptable. Absolutely - different strokes for different folks. That doesn't mean everyone should be forced to do it. This conversation constantly confuses the issue of must implement vs must deploy. Which one are you objecting to here. -hadriel Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
On Apr 1, 2010, at 12:59 PM, Hardier Kaplan wrote: 1) The mechanism does not scale, for large SSP's. (is this only meant for small deployments?) Why is this any worse that say a registration? I don't buy this assertion that it does not scale. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Sip] Last Call: draft-ietf-sip-ipv6-abnf-fix (Essential correction for IPv6 ABNF and URI comparison in RFC3261) to Proposed Standard
I'm very support of this draft and think it should move forward but I have a NIT to pick with it. It says the ABNF in 3261 is incorrect and this one corrects it. I don't believe that is correct. I believe the ABNF in this draft is more specific than the one in 3261 but they are both correct. I think this is an important distinction that should be corrected in the draft and I will try and motivate why. The ABNF is what helps an implementor know what sort of parse they need to write such that it can successfully parse over unknown extensions. It also constrain what future syntax extensions can use. There is a constant pressure to make it explicitly represent the current semantic limitations of the protocol. But the ABNF is not what defines the protocol, the text in the RFC does that. For example, most ABNF that have a port number would allow a number that was greater than 2^16. We could write ABNF that limited the port number to a 16 bit integer but typically we don't and instead define the port in the text. As far as I can tell, there is nothing wrong with the ABNF in 3261, it is just less specific than we would like and this new ABNF is more specific will limit future RFC and extensions to conform with the range of syntaxes allowed by this extortion. Because of this I don't believe this should update 3261. Every time we have an update to 3261 vendors have to go thought a huge exercise and discussion with customers if their products are still compliant etc. In the case of this draft that would be a huge waste of time as clearly no code is changed by this. Cullen in my individual contributor role On Mar 5, 2010, at 4:30 PM, The IESG wrote: The IESG has received a request from the Session Initiation Protocol WG (sip) to consider the following document: - 'Essential correction for IPv6 ABNF and URI comparison in RFC3261 ' draft-ietf-sip-ipv6-abnf-fix-04.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-19. 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-sip-ipv6-abnf-fix-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16959rfc_flag=0 ___ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is essentially closed and only used for finishing old business. Use sip-implement...@cs.columbia.edu for questions on how to develop a SIP implementation. Use dispa...@ietf.org for new developments on the application of sip. Use sipc...@ietf.org for issues related to maintenance of the core SIP specifications. Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
On Mar 17, 2010, at 2:01 PM, Michael Edward McNeil wrote: On Wed, Mar 17, 2010 at 12:29, Bob Hinden bob.hin...@gmail.com wrote: On Mar 17, 2010, at 9:02 AM, Michael Edward McNeil wrote: Since Americans habitually use month-day order anyway, why would -MM-DD be especially difficult for them? It's Europeans and others who typically use day-month order that would seem likely to incur difficulties -- except that putting the year first is a pretty glaring clue that the order shouldn't be regarded as it usually is for them. Since this thread is about making things clearer, I would comment on your use of the word Americans. Americans means everyone in North and South America. I suspect what is meant here, is just the USA. Reminds me of a little kid who runs up and proclaims (this actually happened to me), I'm not a kid! Kids are baby goats! Well, kids may be baby goats -- but they're also (sometimes brattish) young humans -- and most speakers of human languages quickly become cognizant of the fact that every spoken language has words with more than one accepted meaning, which are perfectly correct in context, viz. dictionary.com: A·mer·i·can [uh-mer-i-kuhn] 1. of or pertaining to the United States of America or its inhabitants: an American citizen. 2. of or pertaining to North or South America; of the Western Hemisphere: the American continents. 3. of or pertaining to the aboriginal Indians of North and South America, usually excluding the Eskimos Hm, I wonder which of those meanings could possibly have been intended here? Michael McNeil Canadians like to think of themselves as fairly peaceful people, unless of course, you call them American. Or you are discussing hockey at the Olympics. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
What day is 2010-01-02
I just got abused by someone reading the IESG web pages and pointing out dates like 2010-01-02 , are confusing. Is there a better way to do dates that we should be using on the ietf.org web pages? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
