Re: motivations (was: Re: draft-housley-two-maturity-levels-00)
Hi Ran, and thanks for your reply. There are two separate issues that we need to distill. First, what to do about draft-housley-two-maturity-levels-00, and second, how do take input to improve the overall process? I have not really come down on one side or the other on this draft (yet). To be sure, two maturity levels seem better than three, and as you know, I've proposed a single maturity level in the past, so to me, the draft goes in the right direction. However, I do not know how many times we get to change this sort of procedure, and I believe the community and IESG choice could be better informed than it is today. Having been involved in NEWTRK, and having produced what I think was the only output from that group, in terms of RFCs or processes, I think I know about which I write, when I say this community can become a bit of an echo chamber, and could use a bit of formal academic input. Conveniently, there are researchers in this area. This is an even stronger reason for for me to not state an opinion about whether to advance the draft. As to the questions I asked, you and I obviously hold very different views. In the end, it is of course for researchers (who are the real target of my questions) to ask what questions that they think might be telling about our process. I hope this discussion informs them, if and when they review it. You claim I have a vendor bias. Guilty, but I am also concerned that we do the right things for the right reasons, and that motivations are reasonably aligned so that we have some reason to believe that what is proposed will work and not have perverse impact. Absent some serious analysis, we also are making the assumption that the logic of decisions of over twenty years ago holds today, when in fact we don't really even know if it held then. And now as to your specifics, you have placed a lot of weight on one example, seemingly extrapolating from it, the Joint Interoperability Test Command. I have no experience working with them, and defer to yours. However, when you say, As examples, the JITC and TIC requirements pay a great deal of attention to whether some technology is past PS. Various IPv6 Profile documents around the world also pay much attention to whether a particular specification is past PS. It leads to the following questions: * Would the vendors have implemented the functionality ANYWAY? Specifically, would other RFPs have already driven vendors in this direction? Can you cite a counter example, where that was not the case? * Is the defense industry at all representative of the broader market? My own experience leads to an answer of, “barely at all”, and this has been assuredly the case with the Internet where a huge portion has run on on PS, Internet-Drafts, and proprietary standards, and not waited for advancement. Examples have included BGP, MPLS-VPNs, HTTP, SSL, and Netflow, just to name a few. But again, I would like to see a rigorous analysis, rather than simply rely on either of our personal experiences. The IETF already has a tendency to be very vendor-focused vendor-driven. It is best, however, if the IETF keeps the interests of both communities balanced (rather than tilting towards commercial vendors). While this is a perhaps laudable idea, someone has to do the work to get specifications to the next standards level. The whole point of my questions is to determine what motivations that someone might have for actually performing that work. If we look at the 1694 Proposed Standards, are we seeing a lack of implementation due to lack of stability? I would claim that there are quite a number of examples to the contrary (but see below). Wrong question. How clever to knock down the wrong strawman. There's no need to be rude or snarky with me, even if you disagree. You are looking at this from the angle of the customers, and that's perfectly reasonable. I'm looking at it from the developers' point of view, and from the supply side of your equation. Both seem reasonably valid, and so I have no qualms with the question part of your (A), although as I mentioned above, I question your answer. B) whether that signal has a feedback loop to implementers/ vendors that still works. The answer to this is also clearly YES. Technologies that appear in RFPs or Tender Requirements have a stronger business case for vendors/implementers, hence are more likely to be widely implemented. Certainly so, but I don't understand how you made the leap of logic from your question to your answer. Do we have situations, for instance, where a proposed standard is compared to a draft standard, or a draft standard is compared to a full standard, and one is chosen over the other? If so, are they the norm, and are they likely to drive implementation? Also, if all this gets you is interoperability, but
Re: The IPv6 Transitional Preference Problem
David Conrad wrote: On Jun 18, 2010, at 7:21 PM, Martin Rex wrote: What you described is a client with a pretty selfish attitude that doesn't care about network, servers and the other clients put into code. Well, no. What I described was my understanding of a proposal to facilitate transition that comes with some benefits and some costs. If nothing else, given the truly inspirational amount of crap on the Internet, I find it a bit difficult to get worked up about a few additional packets at communication initiation that are actually beneficial. What you described results in a negative incentive for servers to become accessible under IPv6 as an alternative to IPv4. That is a real problem. If a large number of clients would follow your proposed strategy, ever server that announces an IPv6 address gets hit by twice the amount of connection requests, half of them being killed prenatal or during infancy. If IPv6 connectivity is still bad, then the connection request will not reach the server and the server will not notice. But it is a clear goal to considerably improve on IPv6 connectivity in near term. So the problem this selfish client-side hack addresses is going to become worse for the servers over time. I wonder at what point clients with a selfish attitude will stop optimizing for their own interest alone. The largest effort for client apps is to implement the parallel connection handling at all. Using it for parallel IPv4 connects and not only IPv4+IPv6 comes essentially for free. For typical HTTP-style protocols with small app-requests, sending the client requests in paralell would also be cheap for the client. Deciding which connection to retain based on which one yields the fastest server reply is going to improve the user experience even more. But the more it seems to improve for the client, the worse it gets for the server, the network and all the other clients. The concept works only as long as very few individuals try to get an unfair advantage over the rest. But it definitely is doomed if EVERYONE, or even a larger number of people would practice this. We seem to be talking about different things. At the abstract level, it is exactly the same thing. When a project is falling behind schedule there are two things that the responsible manager could do: - ask for more frequent status reports - ask the team what he could do to help them getting it done One of them is inconsiderate, ineffective and popular. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-housley-two-maturity-levels-01.txt
It's been amusing to see the same old arguments going past for the Nth time. Maybe we can have a side-thread about the value of N. That said, my comment on this proposal is: ship it. It's simple, simple to implement, and it aligns RFC 2026 with current practice. So let's just do it. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-00
John, That's news to me: I can't recall any recent discusses calling for operational experience before publishing as Proposed Standard. Some years ago, there was such a requirement for Routing Area, but that was declared obsolete. (In actuality, there seems to still be a somewhat informal requirement to document implementations for _some_ Routing Area documents, but it is not by IESG direction.) AFAICT the IESG is not setting any requirements like this. We are careful about documents stating correctly what their limitations or not so well understood areas are. And sometimes a working group may decide that they do not want to forward a document for publication until it has some operational experience. But as a general rule the IESG is not demanding this. I don't want to say that we would never do it for any document, however. I remember a recent case were one AD wanted operational experience on a new, relatively complex design. Other ADs pushed back and the document was approved without that experience. However, there might be cases where we should have that experience. One case that comes to mind is draft-ietf-intarea-ipv4-unique-id which among other things does an Update: 791 and we would never do that without years of very widespread experience. In short: its a judgment call but generally speaking the IESG does not require operational experience for PS. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IPv6 Transitional Preference Problem
Joel's iPad On Jun 23, 2010, at 6:06 AM, Martin Rex m...@sap.com wrote: David Conrad wrote: On Jun 18, 2010, at 7:21 PM, Martin Rex wrote: What you described is a client with a pretty selfish attitude that doesn't care about network, servers and the other clients put into code. Well, no. What I described was my understanding of a proposal to facilitate transition that comes with some benefits and some costs. If nothing else, given the truly inspirational amount of crap on the Internet, I find it a bit difficult to get worked up about a few additional packets at communication initiation that are actually beneficial. What you described results in a negative incentive for servers to become accessible under IPv6 as an alternative to IPv4. That is a real problem. If a large number of clients would follow your proposed strategy, ever server that announces an IPv6 address gets hit by twice the amount of connection requests, half of them being killed prenatal or during infancy. We have tcp syn cookies actually to protect against the impact of state generation on connect. As long as you as a client reply only to one syn/ack, everything is cool. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IPv6 Transitional Preference Problem
Joel Jaeggli wrote: On Jun 23, 2010, at 6:06 AM, Martin Rex m...@sap.com wrote: What you described results in a negative incentive for servers to become accessible under IPv6 as an alternative to IPv4. That is a real problem. If a large number of clients would follow your proposed strategy, ever server that announces an IPv6 address gets hit by twice the amount of connection requests, half of them being killed prenatal or during infancy. We have tcp syn cookies actually to protect against the impact of state generation on connect. As long as you as a client reply only to one syn/ack, everything is cool. If it was the TCP stack that generated both original SYNs to decide then this might work. But it is some app code several layers higher with a non-negligible latency. Originally, there were two choices for the app: multi-threaded blocking connect()s or asynchronous non-blocking. In the blocking variant, it becomes pretty difficult to prevent TCP from completing the handshake. If the IETF really thinks that there is value in going down that path, then it should define parallel IPv4IPv6 connects at the network level, so that either connection knows about the other one. This should be accompanied by a hint in DNS indicating that a node (a) technically supports and (b) does not mind parallel connect()s. When it is part of the network stack, it could work with any existing app. My knowledge about the TCP, IP and NAT stuff is pretty limitited. While the TCP SYN cookies might help to protect the server apps, how much resources do a single SYN/ACK use at the kernel/TCP stack layer and how much resources do they use on the NATs in between? Without FIN/ACK or RST only the closing client knows that the resource can be freed. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 00.59, Thomson, Martin wrote:
It seems that Section 7 has an old example in it. Did you previously use
NAPTR with a D flag?
Actually, no. If you do know what protocol you look for, you can use the URI RR
directly. The idea with the NAPTR and the D flag was that it would list what
URI records exists in the zone.
Let me expand a bit also including the caldav example:
$ORIGIN example.com.
IN NAPTR 200 10 D EM:protA ( ; service
; regexp
example.com. ) ; replacement
IN NAPTR 200 10 D caldav:caldav ( ; service
; regexp
example.com. ) ; replacement
IN NAPTR 200 10 D caldav:carddav ( ; service
; regexp
example.com. ) ; replacement
_protA._EM IN URI prota://somehost.example.com/
_carddav._caldav IN URI http://somehost.example.com/whateveruri;
_caldav._caldav IN URI http://somehost.example.com/someotheruri;
I.e. if you know you want the carddav/caldav URI, you just look up the
{IN,URI,_carddav._caldav.example.com} RRSET, if you want to know the services
example.com has, you look up {IN,NAPTR,example.com} and then with flag D you
see what you can find using lookup of URI RR.
So, the NAPTR and flag D is not really needed for the resolution. It is a
list the services feature.
But, I will remove that part because it is not really a piece of the URI
definition.
For security considerations, I have one to add. RFC 3958 (S-NAPTR) has this
nasty little authentication hitch, that you should really consider in this
draft. The reference identifier (see draft-saintandre-tls-server-id-check)
that you are required to use for authenticating the host is the one that is
input to the resolution process...not the product of the process.
Basically, if you search for _http._web.example.net and get
http://www.example.com/ , then you are expected to authenticate against
_http._web.example.net (or maybe example.net, I'm not sure - NAPTR doesn't
use the '_' prefix).
I thought you should authenticate against example.net?
I.e. you want caldav/caldav for example.com and get back
http://www.calendarserverfoobar.com/caldav/example.com/caldav; (for a
PROPFIND), what is the best to require for authentication? example.com or
www.calendarserverfoobar.com? I presume example.com (the domain name used
_before_ the URI lookup happens.
Patrik
I'm happy to expand on the problems that I faced with this little security
tangle. The problem doesn't end there.
PGP.sig
Description: This is a digitally signed message part
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: The IPv6 Transitional Preference Problem
On Jun 23, 2010, at 15:06, Martin Rex wrote: optimizing for their own interest alone I don't know about you, but when I set up a server, I have a strong interest that my clients get their data fast. So whatever it takes to do that, is in my interest. BTW, initial analyses of iOS 4 (iPhone OS) show that they are always v6 enabled: http://isc.sans.edu/diary.html?storyid=9058rss It would be interesting to know how their v6/v4 preference goes. They also appear to be using MAC-based addresses (as opposed to RFC4941/RFC3041 privacy-enhanced). If that is indeed true, that will be a *great* incentive for server operators to switch on NAT-free IPv6, once they start to understand the implications (no need for cookies any more :-). Gruesse, Carsten ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-00
Spencer, As I read http://www.rfc-editor.org/rfc/rfc5741.txt, Experimental RFCs would be Category: Experimental on the first page, and I'd expect them to be revised when they are reclassified, if only to make this say Category: Standards Track. So that's at least a small barrier to reclassification in place. Yes, though that is something which could be handled by setting the tracker intended status and perhaps an RFC Editor note correctly to PS. The last call notice would say the correct thing after this, for instance. Its really very similar to what we've been doing for some documents already. RFC such and such for Draft and at that time such and such is still a PS, and a new RFC # will be allocated for the DS RFC. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-00
I'm with Ran and others who stated that best is the enemy of good in this case. I think Russ' draft is a step in the right direction and will reduce complexity and effort. An incremental improvement. We should adopt it in Maastricht. And lets avoid too much fine-tuning or fragmentation of the proposals... Having said that, I did have a couple of other observations. First, it has been repeatedly noted the IETF community has given up on advancing documents on the standards ladder. In some sense this is true. Out of the 122 documents currently in the RFC Editor queue, 0 are for Full Standard, 1 document (0.8%) is for Draft Standard, 8 (6%) are for Experimental, 28 (23%) are for Informational, and 83 (68%) are for Proposed Standard. However, 13 (11%) are bis documents of various sorts. And that's not a special occurrence, we do produce overall quite many revisions of existing RFCs. My interpretation is that while overall the community is not that interested in the standards levels, the IETF is still very interested in keeping our specifications up to date, correcting bugs and maybe in some cases even removing or adding some features. I think it is valuable work and needs to continue. And here is where in my opinion the possible value of the two-step ladder lies. The implementation reports may help in directing the bis draft to become simplified, and based on actual experience. But I would also be OK with a one step model. You can draw running code support for that model from the above data. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-01
Dave: This observation was based on many hallway discussions with many people over many years. You are correct to observe that there are many factors at play, and many of them were discussed at the mic in plenary. The draft changes process in many different places. I've attempted to balance many differnt things in this proposal. Only community discussion will determine if the balance is acceptable. There is always risk in process changes. The goal is to make changes where the benefits outweigh the risk. Russ On 6/23/2010 5:25 AM, Dave CROCKER wrote: Russ, In reading the latest version of your proposal, I finally realized that a motivating premise: o Since many documents are published as Proposed Standard and never advances to a higher maturity level, the initial publication receives much more scrutiny that is call for by RFC 2026 [1]. is well-intentioned, sounds reasonable, but is actually without any practical foundation. In other words, we do not know that the premise is valid. There are many likely reasons that the process of getting through the IESG, for Proposed, has become such a high burden. (Perhaps you did not mean to limit the reference to mean only IESG scrutiny, but in formal terms, it really is the only one that matters, in terms of 'scrutiny'.) I think that a detached and thorough exploration of those possible reasons is likely to show that the problem pre-dates the move towards leaving documents at Proposed and, in fact, well might have contributed to it. By virtue of having Proposed be so difficult to attain, there is a disincentive for going through the process again, for the same protocol. A tendency for all of us in this kind of topic is to make simple assertions of cause or of likely behavioral change that sound reasonable but have little empirical basis. We need to be careful to avoid falling into that trap, because the changes being discussed are strategic, and could well be impossible to reverse completely... d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels-01
Russ, In reading the latest version of your proposal, I finally realized that a motivating premise: o Since many documents are published as Proposed Standard and never advances to a higher maturity level, the initial publication receives much more scrutiny that is call for by RFC 2026 [1]. is well-intentioned, sounds reasonable, but is actually without any practical foundation. In other words, we do not know that the premise is valid. There are many likely reasons that the process of getting through the IESG, for Proposed, has become such a high burden. (Perhaps you did not mean to limit the reference to mean only IESG scrutiny, but in formal terms, it really is the only one that matters, in terms of 'scrutiny'.) I think that a detached and thorough exploration of those possible reasons is likely to show that the problem pre-dates the move towards leaving documents at Proposed and, in fact, well might have contributed to it. By virtue of having Proposed be so difficult to attain, there is a disincentive for going through the process again, for the same protocol. A tendency for all of us in this kind of topic is to make simple assertions of cause or of likely behavioral change that sound reasonable but have little empirical basis. We need to be careful to avoid falling into that trap, because the changes being discussed are strategic, and could well be impossible to reverse completely... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: motivations (was: Re: draft-housley-two-maturity-levels-00)
On 23 Jun 2010, at 08:45 , Eliot Lear wrote: And now as to your specifics, you have placed a lot of weight on one example, seemingly extrapolating from it, the Joint Interoperability Test Command. I have no experience working with them, and defer to yours. However, when you say, Again, you setup an incorrect strawman, and then knock it down. In the quote (below), I also mentioned the various IPv6 Profile documents around the world, which you ignore, apparently in order to incorrectly characterise my note as using a single example. There are a number of cases where a large customer's requirements (in RFPs or Tender opportunities) have driven feature priorities. The TIC and JITC are merely examples. Numerous other examples exist, including a large bank in central Europe and several ISPs. As examples, the JITC and TIC requirements pay a great deal of attention to whether some technology is past PS. Various IPv6 Profile documents around the world also pay much attention to whether a particular specification is past PS. It leads to the following questions: * Would the vendors have implemented the functionality ANYWAY? Specifically, would other RFPs have already driven vendors in this direction? Can you cite a counter example, where that was not the case? Yes. There are certainly numerous cases where vendor implementation timing and new feature prioritisation were directly impacted by a profile document cited in some RFP, and where that profile document's contents were directly impacted by whether a particular technology was at Proposed Standard or some more advanced stage in the IETF processes. The most obvious examples come from the various IPv6 Profiles around the world. There are some number of these in Japan, in Europe, in the USA, and in other countries. Various examples also exist outside the IPv6 Profile universe, including but not limited to large customers (e.g. the JITC and TIC). * Is the defense industry at all representative of the broader market? My own experience leads to an answer of, “barely at all”, and this has been assuredly the case with the Internet where a huge portion has run on on PS, Internet-Drafts, and proprietary standards, and not waited for advancement. Examples have included BGP, MPLS-VPNs, HTTP, SSL, and Netflow, just to name a few. I provided non-defense examples in both my original note (which examples you have ignored for some reason) and also in my response above. The IETF already has a tendency to be very vendor-focused vendor-driven. It is best, however, if the IETF keeps the interests of both communities balanced (rather than tilting towards commercial vendors). While this is a perhaps laudable idea, someone has to do the work to get specifications to the next standards level. The whole point of my questions is to determine what motivations that someone might have for actually performing that work. I was quite detailed on that front, although you seem to have selectively ignored that part of my note. There's no need to be rude or snarky with me, even if you disagree. I wasn't rude, and can't find snarky in the OED. You are looking at this from the angle of the customers, and that's perfectly reasonable. I'm looking at it from the developers' point of view, and from the supply side of your equation. I've been both customer/user/operator and vendor/implementer at various points in time. So I look at it from both points of view, and my earlier note included discussion of both vendor advantages and user/operator/customer advantages. It seems quite odd that you seem to have ignored my note so selectively. B) whether that signal has a feedback loop to implementers/ vendors that still works. The answer to this is also clearly YES. Technologies that appear in RFPs or Tender Requirements have a stronger business case for vendors/implementers, hence are more likely to be widely implemented. Certainly so, but I don't understand how you made the leap of logic from your question to your answer. Do we have situations, for instance, where a proposed standard is compared to a draft standard, or a draft standard is compared to a full standard, and one is chosen over the other? Yes, we do. If so, are they the norm, and are they likely to drive implementation? Such decisions in various IPv6 Profiles around the world, in large customer requirements documents around the world (e.g. JITC, TIC) regularly have driven implementation priorities and new feature timetables in the past. Folks at many vendors have experienced this. I witnessed it at every vendor I've ever worked for. It isn't a surprise that a business case would drive these things NOR is it a surprise that standards status would drive an RFP (and hence drive the business case). Also, if all this gets you is
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 16.33, Richard L. Barnes wrote: In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems. Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com. So, the connect the dots is to: - Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS - Secure that announcement in DNS with DNSSEC - Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches - Do application layer authentication etc over the then encrypted connection Sounds ok? Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Basically, yeah, as long as you have DNSSEC. In fact, if you've got DNSSEC, you don't really even need the application-specific bit at the end. The goal of the XMPP DNA work (and other analogous things) is to work around not having DNSSEC in the mean time. In that solution, the parallel path is: - Announce the fact that example.com is hosted at clendarserverfoobar.com in DNS - Connect to calendarserverfoobar.com over TLS and check that the name in the cert is indeed calendarfoobar.com - Obtain an attribute cert for calendarfoobar.com signed by example.com - Valid signature and certificate for example.com implies that delegation is OK The third of these steps of course require some application-specific magic. --Richard On Jun 23, 2010, at 2:52 PM, Patrik Fältström wrote: On 23 jun 2010, at 16.33, Richard L. Barnes wrote: In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems. Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com. So, the connect the dots is to: - Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS - Secure that announcement in DNS with DNSSEC - Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches - Do application layer authentication etc over the then encrypted connection Sounds ok? Patrik ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 23, 2010 8:52:45 PM +0200 Patrik Fältström p...@cisco.com wrote: In principle, example.com is the proper domain to authenticate, but in practice, that causes a lot of problems. Consider the case where the target of the redirection is a separate entity from the origin; this could arise, for example, in a situation whereexample.com has outsourced its calendaring services to calendardserverfoobar.com. So, the connect the dots is to: - Announce the fact example.com is hosted at calendarserverfoobar.com (with some URL) in DNS - Secure that announcement in DNS with DNSSEC - Verify the SSL (for example) cert for the connection to calendarserverfoobar.com matches So the srv-caldav (and srv-email) drafts reference Section 3 of draft-saintandre-tls-server-id-check which describes how clients can go about verifying a server identity when using TLS under various circumstances, including an initial discovery via SRV records. - Do application layer authentication etc over the then encrypted connection Sounds ok? Well the key here is DNSSEC of course! -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 22, 2010 8:54:22 AM +0200 Patrik Fältström p...@cisco.com wrote: I have together with Olaf Kolkman suggested a new RR type that I call URI that work similarly to what is described in this draft (regarding the owner of the RRSET), but a URI in the RDATA. It has been posted to the namedroppers list a few times...but maybe that has been wrong. Maybe Apps Area should have been notified about the work a bit more... Cyrus has asked a few questions about it, and maybe it is me that have not reached out to the Caldav people enough? I have tried to push it through via the DNS people in the IETF, but there have not been enough traction. I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 21.20, Cyrus Daboo wrote: I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle unknown DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998. Regarding (3), I think it is sad people move redirects and lookups and functionality to be on top of HTTP instead of IP. And I do not understand in the absence of DNS...that is an interesting situation ;-) Specifically to use that as the foundation for the architecture to use for calendaring, that is -- I hope -- one of the more fundamental applications on the Internet. A new version of my draft I promised today, but due to this security consideration discussion, it is now delayed yet another day. And yes, I will do the job of releasing a new version although there will continue to not be any interest of using it. :-) Or maybe I should just push it through, although for calendaring draft-daboo-srv-caldav will be used. Hmm... I do not want to be problematic here. Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
Hi Patrik, --On June 23, 2010 10:07:44 PM +0200 Patrik Fältström p...@cisco.com wrote: I did chat with a few server implementors about this and the feeling was SRV + .well-known is a good solution that can quickly be deployed. Some points: 1) SRV's are very deployable today - a new RR will be harder to deploy. 2) There is a push to support SRV's with other protocols (e.g. draft-daboo-srv-email for IMAP, POP3, and Submission) so from an operational standpoint its likely to be more common. 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle unknown DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998. I am thinking more of client APIs. Regarding (3), I think it is sad people move redirects and lookups and functionality to be on top of HTTP instead of IP. And I do not understand in the absence of DNS...that is an interesting situation ;-) Specifically to use that as the foundation for the architecture to use for calendaring, that is -- I hope -- one of the more fundamental applications on the Internet. Sorry - bad wording on my part. What I meant was in the absence of a service-type to hostname mapping in the DNS. -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
At 3:20 PM -0400 6/23/10, Cyrus Daboo wrote: 3) .well-known is useful in the absence of any DNS records. i.e. if no SRV/URI were available, a client can still try auto-discovery by attempting an HTTP connection to the host (derived from user input) and the .well-known path. This sounds weird to me. The tradeoff is using two different protocols (DNS and HTTP) versus one (DNS). For schemes that are not being run over HTTP, that means that the client needs to add an HTTP client stack just to find the right server. Is this really a good idea? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
By any chance does anyone know who is the SIP guy/gal at Apple?
Aka FaceTime? Some of us in the RAI directorate would like to extend a welcoming hand. J Plus see what the SDP looks like etc , interop options, naming, where is the rendezvous server, etal. Small stuff. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-daboo-srv-caldav (Use of SRV records for locating CalDAV and CardDAV services) to Proposed Standard
On 23 jun 2010, at 23.05, Cyrus Daboo wrote: Hmm...regarding the new RR, the only thing I can think of today is the need for some changes in the provisioning system from which one create the DNS zones. I do not know of any DNS code today that can not handle unknown DNS RR Types, but maybe I am wrong? I am though confused over (1) as this is 2010 and not 1998. I am thinking more of client APIs. Sure, but, support for unknown RR Types is said to be needed since long time back. And what API do not handle the ability to request an RR with a specific RRTYPE? int res_query(const char *dname, int class, int type, u_char *answer, int anslen); Anyway...this discussion has been held in the IETF I do not know how many times. Instead of writing another 10 lines of code (or whatever is needed) people fall back to existing RR Types, and not only that, define future protocols because of lack of #define for new RRTYPES. I know people have different views here, and I have one specific view ;-) Patrik PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 5922 on Domain Certificates in the Session Initiation Protocol (SIP)
A new Request for Comments is now available in online RFC libraries. RFC 5922 Title: Domain Certificates in the Session Initiation Protocol (SIP) Author: V. Gurbani, S. Lawrence, A. Jeffrey Status: Standards Track Stream: IETF Date: June 2010 Mailbox:v...@alcatel-lucent.com, scott-i...@skrb.org, ajeff...@alcatel-lucent.com Pages: 17 Characters: 37667 Updates:RFC3261 I-D Tag:draft-ietf-sip-domain-certs-07.txt URL:http://www.rfc-editor.org/rfc/rfc5922.txt This document describes how to construct and interpret certain information in a PKIX-compliant (Public Key Infrastructure using X.509) certificate for use in a Session Initiation Protocol (SIP) over Transport Layer Security (TLS) connection. More specifically, this document describes how to encode and extract the identity of a SIP domain in a certificate and how to use that identity for SIP domain authentication. As such, this document is relevant both to implementors of SIP and to issuers of certificates. [STANDARDS TRACK] This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5923 on Connection Reuse in the Session Initiation Protocol (SIP)
A new Request for Comments is now available in online RFC libraries. RFC 5923 Title: Connection Reuse in the Session Initiation Protocol (SIP) Author: V. Gurbani, Ed., R. Mahy, B. Tate Status: Standards Track Stream: IETF Date: June 2010 Mailbox:v...@alcatel-lucent.com, ro...@ekabal.com, br...@broadsoft.com Pages: 19 Characters: 41905 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sip-connect-reuse-14.txt URL:http://www.rfc-editor.org/rfc/rfc5923.txt This document enables a pair of communicating proxies to reuse a congestion-controlled connection between themselves for sending requests in the forwards and backwards direction. Because the connection is essentially aliased for requests going in the backwards direction, reuse is predicated upon both the communicating endpoints authenticating themselves using X.509 certificates through Transport Layer Security (TLS). For this reason, we only consider connection reuse for TLS over TCP and TLS over Stream Control Transmission Protocol (SCTP). This document also provides guidelines on connection reuse and virtual SIP servers and the interaction of connection reuse and DNS SRV lookups in SIP. [STANDARDS TRACK] This document is a product of the Reliable Multicast Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5924 on Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates
A new Request for Comments is now available in online RFC libraries. RFC 5924 Title: Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates Author: S. Lawrence, V. Gurbani Status: Experimental Stream: IETF Date: June 2010 Mailbox:scott-i...@skrb.org, v...@bell-labs.com Pages: 8 Characters: 16868 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-sip-eku-08.txt URL:http://www.rfc-editor.org/rfc/rfc5924.txt This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. This document defines an Experimental Protocol for the Internet community. This document is a product of the Session Initiation Protocol Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
