Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 20 aug 2013, at 07:21, Dave Crocker d...@dcrocker.net wrote: The first is that there now a number of other apps using TXT records, with no problems, because they are stored under scoping nodes (underscore-prefaced names). This approach might be aesthetically displeasing, but it works just fine. That can not be said generally. Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without. This implies that two records with the same owner and different RRType MUST be in the same zone, while a name without and one with prefix MIGHT NOT, where also one of the zones is signed and the other is not. Patrik
Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Hi, When relying on S-NAPTR (RFC3958), redirection is only possible inside sub-domains of the original domain name. I don't think that's true. RFC3958 has exactly this use case in it's first example section (2.2): a domain example.com redirects service EM:protA to another domain, namely someisp.example - with the non-terminal flag, as I described in my original mail. This is absolutely a different domain name. This is a restriction compared to the use of normal NAPTR and REGEXP. While making my own experiences with NAPTR, I learned that there is no normal use of NAPTR. NAPTR records are not allowed to be used in the wild without a valid DDDS specification defining its exact semantics. That is precisely the reason why RFC3588 had to be revised in that regard. RFC3958 provides that semantics, so it was a natural choice to re-base Diameter's usage in an S-NAPTR. The following recommendations can be also found in the RFC6733: The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. Actually, I don't even understand the SHOULD here without any clarification on what to do if not... but it is another debate. I now see that RFC6733 has put this IMHO arbitrary restriction in place. It really serves no particular purpose; if there was some thinking behind it, then that really should have been explained in the document. I would tend to ignore that SHOULD if I were implementing Diameter (I'm not :-) ). Different domain names are perfectly in scope for S-NAPTRs, and you would have to consciously lobotomise libraries or code snippets to *not* permit redirections to other domains. We are also regularly using s-flag S-NAPTRs in eduroam and RADIUS Dynamic Discovery to point to a delegate RADIUS server residing in a different domain. It's just normal operations. This limitation in RFC6733 is at best funny IMHO. Therefore, my understanding is that the use of S-NAPTR is not suitable for redirection when the target domain name is different from the original one. And the current draft proposes to allow any kind of redirection without any impact on existing DNS infra. I would rather take a very good look at the section in RFC6733 that discourages other domain names in the replacement. It's more like an erratum for me; and if that restriction were away you would have a working solution to your redirection problem with zero effort. And anyway, it's a SHOULD without considerations or consequences attached. Which makes it more of a DONTCARE anyway ;-) But as I said, it is only based on my understanding and I'm not an expert on DNS. I don't think DNS is the problem here. It's more that Diameter butchers its NAPTR usage unnecessarily. Greetings, Stefan Winter Regards, Lionel -Message d'origine- De : dime-boun...@ietf.org [mailto:dime-boun...@ietf.org] De la part de Stefan Winter Envoyé : lundi 19 août 2013 10:16 À : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard Hello, The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Realm-Based Redirection In Diameter' draft-ietf-dime-realm-based-redirect-11.txt as Proposed Standard Sorry for bringing this up so late, but as I was writing my own dynamic discovery draft for RADIUS, it occured to me that the usage of S-NAPTR for Diameter brings a built-in support to signal realm-based redirect *if* S-NAPTR discovery is used. That only affects this document periphally; it describes realm-based redirect for agent-based redirects, not for DNS-based; but still, the wording in section 2 implies that using a realm-based-redirect-aware Diameter agent is the only choice, and I think that should be rectified. The mechanism for S-NAPTR realm-based redirect is built into the S-NAPTR spec by allowing for non-terminal lookups; this is signalled by having neither an s flag (for SRV targets) nor an a flag (for A/ targets); but instead an (empty) flag. The replacement string in the NAPTR record is then the label of /another/ NAPTR lookup; that lookup is then to be performed with the same service/protocol tag. That makes the whole realm-based redirect problem very easy protocol-wise. Consider a realm foo.example who wants to tell its Diameter peers that its realm's application ID 123 is from now on served from example.com. It puts into DNS foo.example. 43200 IN NAPTR 100 10 aaa+ap123:diameter.tls example.com A client who got this answer would then query for example.com NAPTR aaa+ap123:diameter.tls and would get example.com's servers via SRV or A/ records as configured by the admins of example.com. This is described in section 2.2.3 of RFC3958. Now for the wording in the draft: Sction 2: the first para needs a bit of a
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 8/19/2013 11:33 PM, Patrik Fältström wrote: Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without. Patrik, Please clarify. I don't know what you mean by the 'with' and 'without' references. And as long as I'm asking for more explanation, given the number of years of use the construct has had and for the number of different applications, where has the problem (whatever you mean specifically) been seen? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 20 aug 2013, at 09:14, Dave Crocker d...@dcrocker.net wrote: On 8/19/2013 11:33 PM, Patrik Fältström wrote: Reason for this is that the RR with an underscored prefix MIGHT end up in a different zone than the record without. Patrik, Please clarify. I don't know what you mean by the 'with' and 'without' references. The two following records MUST be in the same zone: foo.example. IN X RDATAX foo.example. IN Y RDATAY The two following MIGHT NOT be in the same zone: foo.example. IN X RDATAX _bar.foo.example. IN TXT RDATAY And as long as I'm asking for more explanation, given the number of years of use the construct has had and for the number of different applications, where has the problem (whatever you mean specifically) been seen? When using DNSSEC if the _bar.foo.example record in the 2nd example above is unsigned, while the foo.example in the first example is. Patrik
Re: Academic and open source rate
On Mon, Aug 19, 2013 at 11:48 AM, SM s...@resistor.net wrote: Hola Arturo, At 07:34 19-08-2013, Arturo Servin wrote: Academic might work. Open source not so much as other mentioned. Does Big Corporation doing Open Source apply? I was tempted to propose non-profit, but also there are organizations with large budgets. And profit driven ones with not much money. Open source is difficult. As people pointed out open source does not necessarily mean free. open source does not necessarily mean non-profit. I used the term loosely. If hypothetically speaking, there was formal action, a clearer term might be needed. Irrespective of my views, big corporation is what helps the IETF operate. If big corporation doing open source applies it will become a problem for the IETF. The main issue is why should the IETF subsidize a particular group. It can also be argued that it is not fair to subsidize a particular group. If getting open source implementations is a desirable goal then the way to address that goal is for ISOC or other parties with funds to provide bursaries to the developers. Isn't that the reason they got the $$$ .org money? -- Website: http://hallambaker.com/
Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Hi, Thank you for quick feedback. I agree with your analysis. I think that we should provide more info on the possible use of S-NAPTR for realm-based redirection. Taking into account your proposal, what do you think of the following proposed changes: The new text reads pretty well. One thing worth considering is maybe: this draft already updates RFC6733. It may be worth making explicit that the RFC6733 SHOULD regarding same-domain targets is being made obsolete in by this draft. One more sentence in the section 2 text below should do the trick: NEW: Using the S-NAPTR DDDS application [RFC3958], the DNS-based dynamic peer discovery mechanism defined in the Diameter base protocol [RFC6733] provides a simple mechanism for realm-based redirection. When S-NAPTR is used for peer discovery, redirection of Diameter request from the original realm to a new realm may be performed by updating the existing NAPTR resource records for the original realm as follow: the NAPTR RR for the desired application(s) and supported application protocol(s) provided by the new realm will have an empty FLAG field and the REPLACEMENT field will contain the new realm to use for the next DNS lookup. ADD: The new realm can be arbitrary; the restriction in RFC6733 that the NAPTR replacement field SHOULD match the domain of the original query does not apply for realm-based redirect purposes. All the rest of the text is fine. Greetings, Stefan Winter However, the use of DNS-based dynamic peer discovery is optional for Diameter implementations. For deployments which do not make use of S-NAPTR peer discovery, support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. In this way, support of the considered Diameter application (discovered during capabilities exchange procedures as defined in Diameter base protocol [RFC6733]) indicates implicit support of the realm-based redirection mechanism. Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document. The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node (Diameter server or proxy) (hereafter called a Realm-based Redirect Server). An application can specify that realm-based redirection operates only on complete sessions beginning with the initial message, or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated. In the former case, existing sessions will not be disrupted by the deployment of realm- based redirection. In the latter case, existing sessions will be disrupted if they are stateful. Regards, Lionel -Message d'origine- De : Stefan Winter [mailto:stefan.win...@restena.lu] Envoyé : mardi 20 août 2013 08:37 À : MORAND Lionel OLNC/OLN Cc : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard Hi, When relying on S-NAPTR (RFC3958), redirection is only possible inside sub-domains of the original domain name. I don't think that's true. RFC3958 has exactly this use case in it's first example section (2.2): a domain example.com redirects service EM:protA to another domain, namely someisp.example - with the non-terminal flag, as I described in my original mail. This is absolutely a different domain name. This is a restriction compared to the use of normal NAPTR and REGEXP. While making my own experiences with NAPTR, I learned that there is no normal use of NAPTR. NAPTR records are not allowed to be used in the wild without a valid DDDS specification defining its exact semantics. That is precisely the reason why RFC3588 had to be revised in that regard. RFC3958 provides that semantics, so it was a natural choice to re-base Diameter's usage in an S-NAPTR. The following recommendations can be also found in the RFC6733: The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. Actually, I don't even understand the SHOULD here without any clarification on what to do if not... but it is another debate. I now see that RFC6733 has put this IMHO arbitrary restriction in place. It really serves no particular purpose; if there was some thinking behind it, then that really should have been explained in the document. I would tend to ignore that SHOULD if I were implementing Diameter (I'm not :-) ). Different domain names are perfectly in scope for S-NAPTRs, and you would
Re: TCPMUX (RFC 1078) status
On 16/08/13 20:07, Joe Touch wrote: On 8/15/2013 10:38 PM, Martin Sustrik wrote: On 16/08/13 03:23, Wesley Eddy wrote: There are semantics issues to; see draft-touch-tcp-portnames-00 for information (this is being revised for resubmission shortly, FWIW). I totally agree. In fact, in the update to the TCP roadmap [1], we added TCPMUX to the section on Historic and Undeployed Extensions, though it definitely bears further discussion than is currently in the roadmap. I think we should add a reference to your portnames doc to explain why this should be Historic plus check a bit more to see if the code that's out there is really being used or whether it's just hanging out like a vestigal limb in the various inetd packages. If it's fair to ask Martin ... I'm kind of curious why you might want to be using it or think it sounds useful? I think a lot of admins would be concerned that it could be used to get around port-based firewall rules, etc. Ok, let me explain. I am coming from enterprise messaging world (think of IBM MQ series, JMS, ActiveMQ, RabbitMQ et c.) Once I was participating on AMQP protocol development (now at OASIS). So, what AMQP and other enterprise messaging products do is exposing a message broker on a single TCP port, which then forwards messages to any connected services. As can be seen, single open firewall port can be used to access any internal service. I don't understand that statement. Services are currently indicated by the destination port. If there is only one destination port available, there is only one service provided - because very few services can be identified solely by in-band information. service here is used in very generic manner; it means some functionality that can be executed remotely. That being obviously the *wrong* way to do things, I've written ZeroMQ later which takes the strict approach: If you want to expose a new service, you have to use a separate TCP port number. Since then it turned out that this as a limitation that people are most complaining about. It would be useful if you could be more specific about the problem you are trying to solve. So far I hear people want one port that serves multiple services. I'd like a pony ;-) I.e., just because they want it, doesn't mean it either makes sense or should get it. It's about cutting the corporate process out of the deployment loop. If every update to your system require opening/closing ports in the firewall, the corporate process kicks in and each iteration is going to take months if not years. Now, the reason seems to be that ZeroMQ requires you to use different TCP connections for doing different kinds of stuff to avoid head-of-line blocking et c. (think of SCTP channels simulated via TCP) Different connections don't have anything to do with the use of a single port. A single port can serve multiple connections, and yes - that's a useful way to avoid HOL blocking. Ack. What that means is that you have a lot of fine-grained services and as the development of your application proceeds you add more of them, remove them and so on. That in turn requires admins (and the corporate approval process!) to get into the deployment cycle and open the TCP ports as appropriate. The result is that the development basically grinds to halt. That sounds a lot like the desires of admins is in conflict with the desires of your users. I.e., an admin that wants to block anything they don't explicitly allow WANTS to block this sort of mechanism too. Yes. That's the pretty common case. There's a internal conflict at your customer's site that you cannot solve. However, despite the conflick, you still need to deploy, otherwise you'll go bankrupt. The solution IMO is to preserve the port-based services functionality for those that truly care about security and -- optionally -- support some kind of multiplexer such as TCPMUX for those that care more about short deployment cycle. TCPMUX won't do what you're asking - if you're asking to block based on the service type. If it did, then the sysadmin would just block TCPMUX connections to services they didn't know, and you'd be right back where you are now (i.e., without TCPMUX). Again, what is the goal? Admins are concerned about ports, not TCPMUX services because that's what they corporate process requires. Yes, it isn't sane, but don't expect things to be sane in corporate environment. (note: the goal of the portnames approach is NOT to provide a single multiplexing port; it's to decouple the dest port's two uses - demux info and service identifier. the primary reason for portnames is to allow more than 65K concurrent/timewait connections to a single service; The proposal looks good. Once it is widely deployed, I'll be happy to drop the TCPMUX idea. Till then though... FWIW, I cited it because of its description of the limitations of TCPMUX, not because the approach there was relevant here). Yes. TCPMUX can support max
Re: [spfbis] SPF TYPE support
On 8/19/2013 7:42 PM, S Moonesamy wrote: At 14:10 19-08-2013, Hector Santos wrote: I'm having a hard time with both sides of the argument, especially the supposed existence of an interop problem which seems to only highlight how to procedurally stump the SPF type advocates with a error correction standpoint. What is that error by the way? In a message dated February 27, 2012, the SPFBIS Chairs commented that the discussion about Issue #9 (SPF RRTYPE) has revealed an interoperability concern in the existing RFC (4408). From RFC 6686: RFC 4408 itself included a faulty transition plan, likely because of the late addition of a requirement to develop one -- it said: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. which means both can claim to be fully compliant while failing utterly to interoperate. The consensus of the SPFBIS WG was that this is an interoperability issue and it would have to be corrected. That is what was considered as an error correction. I have a few questions and points: May I ask why was the above was not an area for clarification as oppose as the presumed stated technical reason for removal? There was adequate information for the expected and original optimal migration plan but it could of been further codified and clarified. It would of been on par with BIS level of work. Issue #9 should not have been a reason for removal. I reported issue #25 [1] regarding the complexity of the recommended parallel processing approach. I believe most folks agreed the ideal and optimal migration approach was: Query SPF type first, Fallback to TXT secord. It was common sense, at least to me. Second, I was under the impression interop reports (RFC 6686) were not making any conclusions or recommendations? Is that a correct basic understanding of interop reports? They were observations, collection of available data and while it might be eventually used to rethink a protocol design, I don't think the above RFC 4408 statement is a serious error in the functional description to justify removal. There are other parts of 4408 which helped clarify the migration path. But overall, a correction (not removal) would of suffice. It would of been on par for BIS-like corrections and protocol updates. Third, I believe removal required a more deeper IETF discussion about the initial presumed engineering expectation that DNS servers (all top DNS servers, including and especially Microsoft DNS servers) would eventually directly support a new registered SPF type or at the very least support RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type) [2]. If this is no longer the expectation, then it would make sense to remove the SPF type but also be aware that in general, this will also nix (not help) any future idea for successfully adopting new RR types. It would be added statement that TXT based applications are acceptable. I think the DNS community continues to have a problem with this. I don't believe there was an adequate answer from the advocates of removing the SPF RR type and the repeated assertion that its been discussed at length has not been convincing it was appropriately addressed. It all seem to be a Shut up approach to the problem (always suggest that its been discussed already). This seems to be one of the reasons why the issue will not go away. I personally do not think that it is appropriate to ask any working group participant to shut up. I welcome hearing arguments and I expect a working group to carefully consider them. Regards, S. Moonesamy (as document shepherd) SM, Pete, thank you for the opportunity to clarify my point. For the record, there was no intent to imply it occurred but quite frankly when it is repeatedly stated, this deeply divided issue has not be resolved at any point, it does have an intimidation factor. As Mr. Crocker stated, the burden is on the those who oppose the removal. But my question was always why was the decision made to remove in the first place done when in fact it was quite obvious it would not have industry wide endorsement. The burden should of been to justify removal. Now it has become difficult to effectively add it back. This is why I posed the question in two forums to get community input over the last few years. It was quite obvious to me that the DNS community would be against this removal. So in this vain, it was prematurely removed in the WG without early IETF/IESG/DNS concerns adequately dealt with. Unfortunately, we were advise to raise the issue again in LC, but by that point, all the IETF procedural moves were made making it it a very high burden to add something that should not been removed in the first place. The only reason our own early adoption package did not support the SPF type was because we could not; the Microsoft DNS server
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 8/20/2013 1:12 AM, S Moonesamy wrote: There is a message from the Responsible Area Director at http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html which might shine some light about that part of the charter. Both RR Type 16 and RR Type 99 are in use on the Internet. Tony Hansen mentioned during the IETF 83 session that: when you write a protocol, there is definite harm if there is a choice in what you publish and what you look for. He is of the view that there is a definite bug in RFC 4408. Fixing that bug falls within the scope of the SPFBIS charter, specifically: Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language. This doesn't seem to be correct. My apology if I don't follow or see the logic. The only real issue as it was since day zero in MARID was the infrastructure support for recursive passthru queries which is what RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type). Without this, which allows for servers to delay/plan direct new RR type support yet still not error out on an unnamed type, there COULD NOT be any reasonable expectation to even only suggest a dual query migration approach, either in serial or parallel. It is very important to consider the mindset when it was first considered and written for RFC 4408 because to me, that is the mindset that has changed. If we don't think the infrastructure, the DNS vendors primarily, will support RFC 3497, then it seems proper to me to finally forget the idea. But if we still think its desirable and possible, then I would prefer to keep the protocol feature/option, corrected of course, and allow implementers the design choice to support it. The way I see it, if more implementations did begin to add support of a clarified BIS specification, that doesn't mean they may enabled it (default ON) out of the box. I would want to initially offer the lowest overheard operational setup out of the box. It will still be a long term migration path, shorter if we can encourage the major DNS vendors to add at least RFC 3597 support. Without, no new RR type will work across the board. The fourth paragraph (see quoted text) states that the conclusions from that where RFC 6866 were flawed and rushed. The explanation given is because the working group declared failure too soon. The SPFBIS WG discovered a bug during the review of the SPF specification. One of the main considerations for the decision was to fix the bug. The working group had to choose one RRTYPE as the conclusion was that it was the appropriate way to fix the bug and ensure interoperability. The comments posted up to now for the Last Call points to a disagreement about the choice of RRTYPE. I hope I am reading this incorrectly. It may be too procedural oriented to me at this point. I would like to see a simple just distinctive consensus on what the entire IETF/DNS community believes is the future of DNS servers offering unnamed RR type processing because that is the main barrier for any kind success. We knew this as far back as MARID. I don't quite understand why this key point seems to be left out, instead MARID was deemed off topic. That was an error because if there is no future in unnamed RR type support, then it really doesn't matter and the problem is solved. TXT only will be the only fast entry point for new DNS DOMAIN policy applications. If the community still believes it possible, then clarifying and codifying the SPF/TYPE lookup procedure seems to me to be the only real correction to make here. Thanks -- HLS [1] http://tools.ietf.org/html/rfc3597
Re: [spfbis] prefixed names, was Last Call: draft-ietf-spfbis-4408bis-19.txt
Newsgroups: iecc.lists.ietf.ietf From: John Levine jo...@iecc.com Subject: Re: [spfbis] prefixed names, was Last Call: draft-ietf-spfbis-4408bis-19.txt Summary: Expires: References: 5212fcef.80...@dcrocker.net 55459829-933f-4157-893a-f90552d44...@frobbit.se 5213174d.7080...@dcrocker.net d2148a40-2673-40c7-8349-0a65d0d01...@frobbit.se Sender: Followup-To: Distribution: Organization: Keywords: Cc: Cleverness: some The two following MIGHT NOT be in the same zone: foo.example. IN X RDATAX _bar.foo.example. IN TXT RDATAY Since prefixed names have never been used for anything other than providing information about the unprefixed name, what conceivable operational reason could there be to put a zone cut at the prefix? This impresses me as one of those problems where the solution is don't do that. R's, John
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Tue, Aug 20, 2013 at 12:14:21AM -0700, Dave Crocker wrote: And as long as I'm asking for more explanation, given the number of years of use the construct has had and for the number of different applications, where has the problem (whatever you mean specifically) been seen? Quite apart from the DNSSEC example that Patrik sent, underscore labels also cause problems and confusion when aliases are involved. The alias stuff is a corner case, of course, but it's still a basic problem with the approach of specifying policy for a target name at a different name than the target itself. This trade-off might be a legitimate one (I certainly think it's preferable to the strategy SPF adopted, of stepping all over the TXT RRTYPE at a given name), but it won't do to dismiss the problem with a point-and-laugh argument. Best, A -- Andrew Sullivan a...@anvilwalrusden.com
Re: TCPMUX (RFC 1078) status
On 8/20/2013 5:35 AM, Martin Sustrik wrote: If you want a multiplexer to serve different connections from a single service port, you need a multiplexer server (tcpmux daemon, websockets, whatever you want to call it). Ack. The web server is a problem though, because you typically don't have control of it. I.e. you cannot randomly plug-in your code into it. You have control over a web server you install. Yes, that would eat one IP address, but there are a lot more IP addresses than port numbers (i.e., using a port to avoid using a separate IP address consumes the wrong resource). However, see my other message - it's hard to recommend an approach when we don't understand the problem you're trying to solve. Joe
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
The issue Måns Nilsson raises was discussed extensively on the SPFbis list prior to as well as during last call on the list and I believe the appropriate decision was reached by the working group. If there is any doubt in the minds of the IESG regarding whether the working group reached the correct decision, I would urge those IESG members to review the threads in the archives related to this issue. Several related issues, including a race condition, were identified and the solution to go with TXT only records is IMHO the correct one under the circumstances. The relatively small uptake of Type 99 records in the wild (both on the publishing side AND on the validation side) in comparison to the implementation for TXT records made a compelling case for the decision of the working group. With regard to the limitations of the working group charter, some significant change was required to eliminate the race condition regardless of what that change would be. The decision of the working group (IMHO - I do not want to put words into anyones mouth) was to go with the approach which had the least impact on what is arguably a very large installed existing base on both the sender AND the validator sides of implementation. Based on this I would ask that tehe IESG move draft-ietf-spfbis-4408bis-19.txt to Proposed Standard. Michael Hammer On Mon, Aug 19, 2013 at 11:05 AM, Måns Nilsson mansa...@besserwisser.org wrote: Subject: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard Date: Mon, Aug 19, 2013 at 06:19:16AM -0700 Quoting The IESG (iesg-secret...@ietf.org) The IESG has received a request from the SPF Update WG (spfbis) to consider the following document: - 'Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1' draft-ietf-spfbis-4408bis-19.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-09-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. I strongly OPPOSE draft-ietf-spfbis-4408bis-19.txt being published as RFC unless substantial parts are reworked. * The charter disallows major protocol changes -- removing the SPF RR type is a direct charter violation; since SPF is being used on the Internet. * The overloading of the TXT record is a hack at best, aimed at circumventing DNS management systems vendors that fail to ship support. Breaking the DNS model with specific resource records is not the way to get better application support. (besides, the major argument at the time was it's so hard and takes ages to get a RR type, which isn't true anymore and also, the RRtype is allocated, what's the fuss? ) * The empirical data that was gathered and the conclusions from which that where published as RFC 6686 are IMNSHO flawed and rushed in that they set far too optimistic deadlines for adaptation before declaring failure. The IESG should send draft-ietf-spfbis-4408bis-19 back to spfbis wg and tell the wg that instead of deprecating SPF it should be algorithmically preferred while maintaining support for TXT. Thanks, -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 It was a JOKE!! Get it?? I was receiving messages from DAVID LETTERMAN!! YOW!! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlISNDEACgkQ02/pMZDM1cXK+gCfYQ1Mv1CHjy9DDn7sA7DC7dF3 b48An1b49Zqf/du3dvN6pmj6in+CEujB =soFG -END PGP SIGNATURE- ___ spfbis mailing list spf...@ietf.org https://www.ietf.org/mailman/listinfo/spfbis
RE: Protocol Action: 'RADIUS Option for DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-radius-opt-14.txt)
Could anyone tell me how to remove my email from this distrubution? -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, August 19, 2013 6:07 PM To: IETF-Announce Cc: dhc mailing list; dhc chair; RFC Editor Subject: Protocol Action: 'RADIUS Option for DHCPv6 Relay Agent' to Proposed Standard (draft-ietf-dhc-dhcpv6-radius-opt-14.txt) The IESG has approved the following document: - 'RADIUS Option for DHCPv6 Relay Agent' (draft-ietf-dhc-dhcpv6-radius-opt-14.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/ Technical Summary: This document defines RADIUS DHCPv6 option that is similar to its DHCPv4 counter-part that was defined in RFC4014. The DHCPv6 RADIUS option provides a mechanism to exchange authorization and identification information between the DHCPv6 relay agent and the DHCPv6 server. This mechanism is meant for the centralized DHCPv6 server to select the right configuration for the requesting DHCPv6 client based on the authorization information received from the RADIUS server, which is not co-located with the DHCPv6 server. The Network Access Server (NAS) acts as DHCPv6 relay agent and RADIUS client simultaneously in this document. Working Group Summary: This document was called draft-yeh-dhc-dhcpv6-authorization-opt prior to its adoption. There was unanimous support for it (9 people in favor of adoption and none against), so this document was adopted in May 2012. There was quite high interest in this work - 55 posts since its adoption. There was never any opposition for this work. Document Quality: I'm not aware of any existing implementations, but the level of support from both DHCP vendors (Nominum, Weird Solutions, Cisco, ISC), hardware vendors (Huawei, Cisco) and operators (Orange, Telecom Italia) suggests that this will be implemented and deployed shortly after option code is assigned by IANA. There was no single lead reviewer and many people contributed to the draft (55 posts about it to DHC list, 41 posts to RADEXT during its WG life). This document went through rapid updates (10 revisions 10 months), because its lead author - Leaf Yeh - was eager to address any comments as soon as they appeared. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Tomek Mrugalski is the document shepherd. Ted Lemon is the responsible AD.
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Mon, Aug 19, 2013 at 10:52 PM, The IESG iesg-secret...@ietf.org wrote: This document specifies an IPv6 profile for 3GPP mobile devices. It lists the set of features a 3GPP mobile device is to be compliant with to connect to an IPv6-only or dual-stack wireless network (including 3GPP cellular network and IEEE 802.11 network). I object to this document on the grounds that it is little more than a list of (34!) features with little technical justification. I see this as a problem because: 1. It is out of the IETF's mandate. It is not the IETF's job to specify which features or protocols should or should not be implemented in hosts. Even the hosts requirements RFCs are careful and sparing in their language. The IETF is certainly not in the business of rubberstamping feature wishlists without good technical reasons. I would challenge the authors to find a precedent RFC containing such broad requirements. 2. It is over-broad. The vast majority of the features are in no way necessary to build a mobile device that works well over IPv6. Today, the overwhelming majority of mobile device traffic comes from devices that implement only a handful of these requirements. More specifically, requirements #3, #9, #10, #11, #12, #13, #14, #15, #16, #17, #18, #19, #20, #21, #22, #23, #24, #25, #26, #27 (a whole RFC!), #28, #29, #31, #32 (which cover all applications running on the device - yes, all of them), and #34, are not necessary to connect to IPv6 mobile networks. 3. It is so daunting as to act as a deterrent to IPv6 deployment. I would challenge the authors to find a single product today that implements all, or even a substantial majority, of these requirements. It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. 4. The document has few technical contributions of its own. Most of the requirements are simply listed one after another. I'm all for IPv6 deployment in mobile networks, but making a list of what seems like all the features that the IETF has ever developed, and then saying that they all need to be implemented, is not the way to get there. The way to do it is to document use cases and working scenarios gleaned from operational experience. Regards, Lorenzo
RE: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Hi Stephan, When relying on S-NAPTR (RFC3958), redirection is only possible inside sub-domains of the original domain name. This is a restriction compared to the use of normal NAPTR and REGEXP. The following recommendations can be also found in the RFC6733: The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. Actually, I don't even understand the SHOULD here without any clarification on what to do if not... but it is another debate. Therefore, my understanding is that the use of S-NAPTR is not suitable for redirection when the target domain name is different from the original one. And the current draft proposes to allow any kind of redirection without any impact on existing DNS infra. But as I said, it is only based on my understanding and I'm not an expert on DNS. Regards, Lionel -Message d'origine- De : dime-boun...@ietf.org [mailto:dime-boun...@ietf.org] De la part de Stefan Winter Envoyé : lundi 19 août 2013 10:16 À : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard Hello, The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Realm-Based Redirection In Diameter' draft-ietf-dime-realm-based-redirect-11.txt as Proposed Standard Sorry for bringing this up so late, but as I was writing my own dynamic discovery draft for RADIUS, it occured to me that the usage of S-NAPTR for Diameter brings a built-in support to signal realm-based redirect *if* S-NAPTR discovery is used. That only affects this document periphally; it describes realm-based redirect for agent-based redirects, not for DNS-based; but still, the wording in section 2 implies that using a realm-based-redirect-aware Diameter agent is the only choice, and I think that should be rectified. The mechanism for S-NAPTR realm-based redirect is built into the S-NAPTR spec by allowing for non-terminal lookups; this is signalled by having neither an s flag (for SRV targets) nor an a flag (for A/ targets); but instead an (empty) flag. The replacement string in the NAPTR record is then the label of /another/ NAPTR lookup; that lookup is then to be performed with the same service/protocol tag. That makes the whole realm-based redirect problem very easy protocol-wise. Consider a realm foo.example who wants to tell its Diameter peers that its realm's application ID 123 is from now on served from example.com. It puts into DNS foo.example. 43200 IN NAPTR 100 10 aaa+ap123:diameter.tls example.com A client who got this answer would then query for example.com NAPTR aaa+ap123:diameter.tls and would get example.com's servers via SRV or A/ records as configured by the admins of example.com. This is described in section 2.2.3 of RFC3958. Now for the wording in the draft: Sction 2: the first para needs a bit of a rewrite to factor in S-NAPTR's capabilities. I suggest something along the lines of: Realm-based redirection is implicitly a part of the Diameter base protocol, but only where peer discovery using S-NAPTR is used (section 5.2 of [RFC6733], by using the non-terminal S-NAPTR flag). This allows for both application-specific realm-based redirects, and for application-agnostic (unconditional) realm-based redirects, and does not require any Diameter agents. For deployments which do not make use of S-NAPTR peer discovery, support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. (... continue with the rest of the section ...) Greetings, Stefan Winter 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-08-27. 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 Message redirection is a basic capability provided by the Diameter base protocol. In its conventional form, message redirection is performed by an application-independent redirect agent, which returns one or more individual hosts to the message sender as possible destinations of the redirected message. However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which that can be achieved. New applications may incorporate this capability by reference to the present document. Because the redirection mechanism is application-specific, it must be performed by a Diameter server or proxy rather than a basic redirect agent as defined in the Diameter base protocol. A new term, Realm- based
RE: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Works for me. Regards, Lionel -Message d'origine- De : Stefan Winter [mailto:stefan.win...@restena.lu] Envoyé : mardi 20 août 2013 13:37 À : MORAND Lionel OLNC/OLN Cc : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard Hi, Thank you for quick feedback. I agree with your analysis. I think that we should provide more info on the possible use of S-NAPTR for realm-based redirection. Taking into account your proposal, what do you think of the following proposed changes: The new text reads pretty well. One thing worth considering is maybe: this draft already updates RFC6733. It may be worth making explicit that the RFC6733 SHOULD regarding same-domain targets is being made obsolete in by this draft. One more sentence in the section 2 text below should do the trick: NEW: Using the S-NAPTR DDDS application [RFC3958], the DNS-based dynamic peer discovery mechanism defined in the Diameter base protocol [RFC6733] provides a simple mechanism for realm-based redirection. When S-NAPTR is used for peer discovery, redirection of Diameter request from the original realm to a new realm may be performed by updating the existing NAPTR resource records for the original realm as follow: the NAPTR RR for the desired application(s) and supported application protocol(s) provided by the new realm will have an empty FLAG field and the REPLACEMENT field will contain the new realm to use for the next DNS lookup. ADD: The new realm can be arbitrary; the restriction in RFC6733 that the NAPTR replacement field SHOULD match the domain of the original query does not apply for realm-based redirect purposes. All the rest of the text is fine. Greetings, Stefan Winter However, the use of DNS-based dynamic peer discovery is optional for Diameter implementations. For deployments which do not make use of S-NAPTR peer discovery, support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. In this way, support of the considered Diameter application (discovered during capabilities exchange procedures as defined in Diameter base protocol [RFC6733]) indicates implicit support of the realm-based redirection mechanism. Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document. The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node (Diameter server or proxy) (hereafter called a Realm-based Redirect Server). An application can specify that realm-based redirection operates only on complete sessions beginning with the initial message, or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated. In the former case, existing sessions will not be disrupted by the deployment of realm- based redirection. In the latter case, existing sessions will be disrupted if they are stateful. Regards, Lionel -Message d'origine- De : Stefan Winter [mailto:stefan.win...@restena.lu] Envoyé : mardi 20 août 2013 08:37 À : MORAND Lionel OLNC/OLN Cc : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard Hi, When relying on S-NAPTR (RFC3958), redirection is only possible inside sub-domains of the original domain name. I don't think that's true. RFC3958 has exactly this use case in it's first example section (2.2): a domain example.com redirects service EM:protA to another domain, namely someisp.example - with the non-terminal flag, as I described in my original mail. This is absolutely a different domain name. This is a restriction compared to the use of normal NAPTR and REGEXP. While making my own experiences with NAPTR, I learned that there is no normal use of NAPTR. NAPTR records are not allowed to be used in the wild without a valid DDDS specification defining its exact semantics. That is precisely the reason why RFC3588 had to be revised in that regard. RFC3958 provides that semantics, so it was a natural choice to re-base Diameter's usage in an S-NAPTR. The following recommendations can be also found in the RFC6733: The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. Actually, I don't even understand the SHOULD here without any clarification on what to do if not... but it is another debate. I now see
RE: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed Standard
Hi Stephan, Thank you for quick feedback. I agree with your analysis. I think that we should provide more info on the possible use of S-NAPTR for realm-based redirection. Taking into account your proposal, what do you think of the following proposed changes: Abstract: OLD: However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which that can be achieved. New applications may incorporate this capability by reference to the present document. NEW: However, in some circumstances an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which that can be achieved when S-NAPTR is not used for dynamic peer discovery. New applications may incorporate this capability by reference to the present document. Section 2: OLD: Because realm-based redirection is not part of the Diameter base protocol [RFC6733], support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. In this way, support of the considered Diameter application (discovered during capabilities exchange procedures as defined in Diameter base protocol [RFC6733]) indicates implicit support of the realm-based redirection mechanism. Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document. The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node (Diameter server or proxy) (hereafter called a Realm-based Redirect Server). An application can specify that realm-based redirection operates only on complete sessions beginning with the initial message, or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated. In the former case, existing sessions will not be disrupted by the deployment of realm- based redirection. In the latter case, existing sessions will be disrupted if they are stateful. NEW: Using the S-NAPTR DDDS application [RFC3958], the DNS-based dynamic peer discovery mechanism defined in the Diameter base protocol [RFC6733] provides a simple mechanism for realm-based redirection. When S-NAPTR is used for peer discovery, redirection of Diameter request from the original realm to a new realm may be performed by updating the existing NAPTR resource records for the original realm as follow: the NAPTR RR for the desired application(s) and supported application protocol(s) provided by the new realm will have an empty FLAG field and the REPLACEMENT field will contain the new realm to use for the next DNS lookup. However, the use of DNS-based dynamic peer discovery is optional for Diameter implementations. For deployments which do not make use of S-NAPTR peer discovery, support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. In this way, support of the considered Diameter application (discovered during capabilities exchange procedures as defined in Diameter base protocol [RFC6733]) indicates implicit support of the realm-based redirection mechanism. Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document. The result of making realm-based redirection an application-specific behaviour is that it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node (Diameter server or proxy) (hereafter called a Realm-based Redirect Server). An application can specify that realm-based redirection operates only on complete sessions beginning with the initial message, or on every message within the application, even if earlier messages of the same session were not redirected. This distinction matters only when realm-based redirection is first initiated. In the former case, existing sessions will not be disrupted by the deployment of realm- based redirection. In the latter case, existing sessions will be disrupted if they are stateful. Regards, Lionel -Message d'origine- De : Stefan Winter [mailto:stefan.win...@restena.lu] Envoyé : mardi 20 août 2013 08:37 À : MORAND Lionel OLNC/OLN Cc : d...@ietf.org; 'IETF Discussion Mailing List' Objet : Re: [Dime] Last Call: draft-ietf-dime-realm-based-redirect-11.txt (Realm-Based Redirection In Diameter) to Proposed
Re: [spfbis] prefixed names, was Last Call: draft-ietf-spfbis-4408bis-19.txt
In message 20130820144548.73129.qm...@joyce.lan, John Levine writes: Newsgroups: iecc.lists.ietf.ietf From: John Levine jo...@iecc.com Subject: Re: [spfbis] prefixed names, was Last Call: draft-ietf-spfbis-4408b is-19.txt Summary: Expires: References: 5212fcef.80...@dcrocker.net 55459829-933F-4157-893A-F90552D444 1...@frobbit.se 5213174d.7080...@dcrocker.net D2148A40-2673-40C7-8349-0A65D 0d01...@frobbit.se Sender: Followup-To: Distribution: Organization: Keywords: Cc: Cleverness: some The two following MIGHT NOT be in the same zone: foo.example. IN X RDATAX _bar.foo.example. IN TXT RDATAY Since prefixed names have never been used for anything other than providing information about the unprefixed name, what conceivable operational reason could there be to put a zone cut at the prefix? When you have _users and you want to move the users out of the hosts namespace and have whom ever deals with people manage that part of the namespace. This impresses me as one of those problems where the solution is don't do that. There are good reasons to split off administrative control. don't do that isn't a answer. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: [spfbis] prefixed names, was Last Call: draft-ietf-spfbis-4408bis-19.txt
On 8/20/2013 8:12 AM, Mark Andrews wrote: In message 20130820144548.73129.qm...@joyce.lan, John Levine writes: ... The two following MIGHT NOT be in the same zone: foo.example. IN X RDATAX _bar.foo.example. IN TXT RDATAY Since prefixed names have never been used for anything other than providing information about the unprefixed name, what conceivable operational reason could there be to put a zone cut at the prefix? When you have _users and you want to move the users out of the hosts namespace and have whom ever deals with people manage that part of the namespace. This impresses me as one of those problems where the solution is don't do that. There are good reasons to split off administrative control. don't do that isn't a answer. Exactly right. For some of the 'underscore' uses, maintenance of the information in that subordinate node is best performed by a team that is separate from the regular DNS operations people. DKIM is an easy example, since the records often are better handled by the email operations folk. So I'm continuing to miss the 'problem' here. Being able to separate administration of the underscore-based attribute information is a feature, not a bug. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On Tue, Aug 20, 2013 at 08:54:02AM -0700, Dave Crocker wrote: In other words, the specific technical limitations being noted are unfortunate but (so far) not serious. You should explain that to my employer's support department. In any case, I don't think this topic is directly relevant to the SPFBIS discussion, so I'll not comment on it further. A -- Andrew Sullivan a...@anvilwalrusden.com
Re: [spfbis] SPF TYPE support
Hi Hector, At 06:30 20-08-2013, Hector Santos wrote: I have a few questions and points: May I ask why was the above was not an area for clarification as oppose as the presumed stated technical reason for removal? The SPFBIS WG had a session at IETF 83. The minutes for that session is at http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt Item C on the agenda is about SPF RR Type and TXT RR (issue #9). Andrew Sullivan, as SPFBIS Chair, explained that: 'The were people on the mailing list in favor of using the TXT RR appeared to be a modest majority and there were people who argued for SPF RR Type on the grounds of DNS hygiene. The Chair explained that it appears as an empirical matter, overwhelmingly, the TXT RR is used but RRTYPE 99 does not qualify under the unused provision of the SPFBIS charter.' Pete Resnick, as Area Director, commented that: 'the deal with the IESG, as a general statement, the working can removed what is unused and put in what is widely deployed. He pointed out that saying that TXT RR is part of an experiment is contrary to the agreement made with the IESG. His opinion is that either way, the proposal is stuck with TXT RR and that it is not an issue. The only issue is whether the proposal can remove the SPF RRTYPE as unused.' On February 26, 2012, Barry Leiba, as a participant, posted a message ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00654.html ) which I will quote: These two statements make a pretty compelling case that there is, indeed, an error in RFC4408. There are, of course, multiple ways to resolve it, and I have no immediate opinion on which is best. My opinion, as one of the SPFBIS WG Chairs, was that there was an error. As Barry Leiba mentioned, there were several possible ways to fix that. The SPFBIS Chair stated at the meeting that: The conclusion reached by the Chair was that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99. That statement was posted to the SPFBIS mailing list ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html ). Nobody disagreed. There was adequate information for the expected and original optimal migration plan but it could of been further codified and clarified. It would of been on par with BIS level of work. Issue #9 should not have been a reason for removal. I reported issue #25 [1] regarding the complexity of the recommended parallel processing approach. I believe most folks agreed the ideal and optimal migration approach was: Query SPF type first, Fallback to TXT secord. It was common sense, at least to me. Both Issue #9 and Issue #25 (see SPFBIS tracker) were well-discussed. Was every technical point carefully considered? I don't think so as it is possible that a technical point may have been missed. There is an opportunity for anyone to comment during the Last Call if the person believes that a technical point has been missed or was not addressed appropriately by the working group. In my opinion the SPFBIS WG carefully considered all the comments which were made in reaching its decision. Second, I was under the impression interop reports (RFC 6686) were not making any conclusions or recommendations? Is that a correct basic understanding of interop reports? They were observations, collection of available data and while it might be eventually used to rethink a protocol design, I don't think the above RFC 4408 statement is a serious error in the functional description to justify removal. There are other parts of 4408 which helped clarify the migration path. From the Introduction Section of RFC 6686: In line with the IESG's request to evaluate after a period of time, this document concludes the experiments by presenting evidence regarding both deployment and comparative effect of the two protocols. At the end, it presents conclusions based on the data collected. In my opinion RFC 6686 does make conclusions (see Section 6 of RFC 6686). There is some background information about the RRTYPE issue in Appendix A. But overall, a correction (not removal) would of suffice. It would of been on par for BIS-like corrections and protocol updates. Andrew Sullivan, as SPFBIS WG Chair, mentioned that We have to do _something_, though any action would introduce a backward incompatibility ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03595.html ). Third, I believe removal required a more deeper IETF discussion about the initial presumed engineering expectation that DNS servers (all top DNS servers, including and especially Microsoft DNS servers) would eventually directly support a new registered SPF type or at the very least support RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type) [2]. There were comments about RFC 3567 during the working group discussions (see
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
Hi Hector, At 07:16 20-08-2013, Hector Santos wrote: This doesn't seem to be correct. My apology if I don't follow or see the logic. The only real issue as it was since day zero in MARID was the infrastructure support for recursive passthru queries which is what RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type). Without this, which allows for servers to delay/plan direct new RR type support yet still not error out on an unnamed type, there COULD NOT be any reasonable expectation to even only suggest a dual query migration approach, either in serial or parallel. It is very important to consider the mindset when it was first considered and written for RFC 4408 because to me, that is the mindset that has changed. This would be a process issue then as the SPFBIS Chairs determination was made on the basic of the text from the SPFBIS Charter which was cited. A person can raise an objection (I am okay with that as that's part of the work) with substantive comments to support the objection. I hope I am reading this incorrectly. It may be too procedural oriented to me at this point. I would like to see a simple just distinctive consensus on what the entire IETF/DNS community believes is the future of DNS servers offering unnamed RR type processing because that is the main barrier for any kind success. We knew this as far back as MARID. I don't quite understand why this key point seems to be left out, instead MARID was deemed off topic. That was an error because if there is no future in unnamed RR type support, then it really doesn't matter and the problem is solved. TXT only will be the only fast entry point for new DNS DOMAIN policy applications. If the community still believes it possible, then clarifying and codifying the SPF/TYPE lookup procedure seems to me to be the only real correction to make here. My reading of the SPFBIS Charter is that the working group was not tasked to work on the future of DNS servers. That does not mean that arguments about the future of DNS servers are not relevant. There are several questions: (a) Was there an error in RFC 4408? (b) What was the error in RFC 4408? (c) Why was there an error in RFC 4408? (d) What should be done about the error? There isn't anything that can be done about question (c) except not to repeat the same mistake. Is there disagreement on the answers to questions (a) and (b)? Regards, S. Moonesamy (as document shepherd)
Re: [dnsext] Deprecating SPF
Hi Patrik, I am copying the message to ieft@ as there is an ongoing Last Call. At 08:28 20-08-2013, Patrik Fältström wrote: The consensus related to how to fix RFC 4408 will be very rough. That is clear. And I feel sorry for responsible AD and IESG to be forced to make a decision that such a large rough part of the rough consensus will not be happy with. Regardless of what the decision will be. An architectural correct solution is to change: OLD: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. NEW: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at type SPF, code 99. Lookup MUST first be of type SPF and SHOULD if no response is received be of type TXT. Reasoning: The use of the TXT record for SPF is not sounds for a number of reasons: 1. The TXT record already can have multiple fields, and it is very unfortunate that the SPF use of TXT records do not use that feature. Instead the SPF specification do say that the first field should be used, and if there are more than one they should be concatenated. After one have one and only one field, that field should be parsed and divided in fields. 2. It is even (compared to some other TXT related documents) pointed out in RFC 4408 that collisions as described in RFC 5507 might happen. 3. It is also pointed out that there might be size issues with the records, and experience from use of NAPTR show that selecting a preferred mechanism that potentially blows the size of the RRSet is not very wise. This is btw why the URI RR Type do not use a prefixed length text field in the RDATA but do set the string the URI is to the full length of the RDATA, i.e. without any 255 byte limitation. 4. DNS is by design (as pointed out in RFC 5507) created with a tuple consisting of owner, type and class for selection by the client what record set to be retrieved. This RRSet architecture is something that comes back not only in the query/response architecture of the DNS protocol, but also in the DNSSEC architecture where RRSets are the units that are signed. Not explicitly ensuring an RRSet is used for SPF (and nothing more) is an architectural choice I strongly am against. Because of these reasons, I do believe the choice is wrong to say that TXT MUST be implemented and instead I am in favor of having type SPF be mandatory for interoperability with fallback to lookup of TXT. From Section 3.1 of draft-ietf-spfbis-4408bis-19: SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase, but has been discontinued. There is a message from Pete Resnick about RFC 2119 usage ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html ). The interpretation of SHOULD and MUST in that part of RFC 4408 was an issue which the SPFBIS WG discussed about. It would be better to have the discussion on the ietf@ mailing list as that's the venue which the IESG identified for last Call comments. Regards, S. Moonesamy
Re: [dnsext] Deprecating SPF
On 20 aug 2013, at 20:36, S Moonesamy sm+i...@elandsys.com wrote: It would be better to have the discussion on the ietf@ mailing list as that's the venue which the IESG identified for last Call comments. Understood, and thanks. The reason why I did not post there at first was that a) I did not feel I had followed the rules laid out for discussions [read all messages in the mailing list archives] and b) the discussion on the dnsext list was more general on overload of TXT records [something DNS people have always been against -- see IAB document on DNS choices]. But, when having that discussion on the dnsext mailing list, to which I cc:ed Pete as responsible AD for full disclosure, Pete did ask me for a complete explanation of my view, which I posted. Once again, without re-reading the mailing list archives. Patrik
RE: [CCAMP] Last Call: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt (Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Contr
As sponsoring AD I have the following last call comments I hope you will take on board. Thanks, Adrian Please fix the two lines that are too long (see idnits) --- Please expand OTN on first use in the main text. Please expand TS on its first use. --- 6.2 The ingress node of an LSP MAY include Label ERO (Explicit Route Object) to indicate the label in each hops along the path. Missing subobject. --- 6.2.1 When an upstream node receives a Resv message containing an GENERALIZED_LABEL object s/an/a/ --- Please consider and note what updates to GMPLS management tools are needed. Are there any changes to the Alarms that might arise? We have a document for that. Are there any changes to the way OAM is controlled? We have a document for that. Should the new G-PIDs show in the TC MIB managed by IANA at https://www.iana.org/assignments/ianagmplstc-mib/ianagmplstc-mib.xhtml This should happen automgically when the feeding registries are updated but it is probably best to add a specific request for IANA. Will other MIB work be needed (in the future) to make it possible to read new information (labels, tspecs) from network devices? --- Please fix so that you have three sections: Authors' Addresses (only those people on the front page) Contributors (other people who made significant text contributions to the document) Acknowledgements (other people who helped with the work) --- [OTN-OSPF] should be a normative reference for its use to define the value of the switching type used in signaling.
Last call of draft-ietf-spfbis-4408bis-19
As the bottle is opened, I hereby state my objection to Section 3.1 of draft-ietf-spfbis-4408bis-19 for the reasons explained below. I do agree (as stated below) that the section of RFC 4408 that specify how to use both SPF and TXT resource record types include an error as it does not lead to interoperability. As the intention with use of both TXT and SPF originally was to migrate from TXT to SPF I instead of what is outlined in the draft suggest that a proper migration strategy is laid out (look up mandatory to implement SPF and fall back to TXT). This instead of deprecation of the SPF record. In general I do believe, for example when looking at IPv6 and DNSSEC and similar technologies, that the lifetime of RFC 4408 is too short to deprecate any of the proposed records that are in use, specifically as RFC 4408 explicitly do allow use of both. Patrik On 20 aug 2013, at 20:36, S Moonesamy sm+i...@elandsys.com wrote: Hi Patrik, I am copying the message to ieft@ as there is an ongoing Last Call. At 08:28 20-08-2013, Patrik Fältström wrote: The consensus related to how to fix RFC 4408 will be very rough. That is clear. And I feel sorry for responsible AD and IESG to be forced to make a decision that such a large rough part of the rough consensus will not be happy with. Regardless of what the decision will be. An architectural correct solution is to change: OLD: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. NEW: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at type SPF, code 99. Lookup MUST first be of type SPF and SHOULD if no response is received be of type TXT. Reasoning: The use of the TXT record for SPF is not sounds for a number of reasons: 1. The TXT record already can have multiple fields, and it is very unfortunate that the SPF use of TXT records do not use that feature. Instead the SPF specification do say that the first field should be used, and if there are more than one they should be concatenated. After one have one and only one field, that field should be parsed and divided in fields. 2. It is even (compared to some other TXT related documents) pointed out in RFC 4408 that collisions as described in RFC 5507 might happen. 3. It is also pointed out that there might be size issues with the records, and experience from use of NAPTR show that selecting a preferred mechanism that potentially blows the size of the RRSet is not very wise. This is btw why the URI RR Type do not use a prefixed length text field in the RDATA but do set the string the URI is to the full length of the RDATA, i.e. without any 255 byte limitation. 4. DNS is by design (as pointed out in RFC 5507) created with a tuple consisting of owner, type and class for selection by the client what record set to be retrieved. This RRSet architecture is something that comes back not only in the query/response architecture of the DNS protocol, but also in the DNSSEC architecture where RRSets are the units that are signed. Not explicitly ensuring an RRSet is used for SPF (and nothing more) is an architectural choice I strongly am against. Because of these reasons, I do believe the choice is wrong to say that TXT MUST be implemented and instead I am in favor of having type SPF be mandatory for interoperability with fallback to lookup of TXT. From Section 3.1 of draft-ietf-spfbis-4408bis-19: SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase, but has been discontinued. There is a message from Pete Resnick about RFC 2119 usage ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03642.html ). The interpretation of SHOULD and MUST in that part of RFC 4408 was an issue which the SPFBIS WG discussed about. It would be better to have the discussion on the ietf@ mailing list as that's the venue which the IESG identified for last Call comments. Regards, S. Moonesamy
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
On 8/15/13 2:06 PM, SM wrote: At 11:48 14-08-2013, IAB Chair wrote: This is a call for review of List of Internet Official Protocol Standards: Replaced by an Online Database prior to potential approval as an IAB stream RFC. My guess is that draft-rfced-rfcxx00-retired cannot update RFC 2026. Does the IAB have any objection if I do something about that? [...] The document argues that STD 1 is historic as there is an online list now. The IESG and the IAB had an email exchange about these two points. Moving a document from Standard to Historic is really an IETF thing to do. And it would be quite simple for the IETF to say, We are no longer asking for the 'Official Protocol Standards' RFC to be maintained by updating (well, effectively removing) the one paragraph in 2026 that asks for it, and requesting the move from Standard to Historic. So I prepared a *very* short document to do that: http://datatracker.ietf.org/doc/draft-resnick-retire-std1/ I'm asking Jari to Last Call it along with a status change for STD 1 (RFC 5000) to Historic. If the RFC Editor wants to explain more of the history and whatever else they're going to do in a separate document, that's up to the IAB. But declaring Standards to be Historic is something the RFC Editor or IAB shouldn't be doing. The above document solves the problem by making it clear that the IETF isn't interested in the document being updated anymore. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: [dnsext] Deprecating SPF
Hi Patrik, At 11:45 20-08-2013, Patrik Fältström wrote: The reason why I did not post there at first was that a) I did not feel I had followed the rules laid out for discussions [read all messages in the mailing list archives] and b) the discussion on the dnsext list was more general on overload of TXT records [something DNS people have always been against -- see IAB document on DNS choices]. But, when having that discussion on the dnsext mailing list, to which I cc:ed Pete as responsible AD for full disclosure, Pete did ask me for a complete explanation of my view, which I posted. Once again, without re-reading the mailing list archives. First of all, I apologize for copying the message to ietf@. The advice given was to read the comments in the SPFBIS mailing list archives. It is not a rule. If a person did not read all the messages and the person raises a point or provides arguments which were not discussed previously I will ask the SPFBIS WG to address them. I don't know whether to process your comments or the other comments posted on dnsext@ as part of the Last Call or not. It is unclear to me as to whether I should only consider messages with the appropriate Last Call subject line. My sense is that I should listen to your concerns. Regards, S. Moonesamy
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
I am having trouble understanding this discussion. If the data is in a database then surely the production of RFC xx00 standards series is simply running an automated query on the database and emitting the result as an RFC?
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
--On Tuesday, August 20, 2013 14:01 -0500 Pete Resnick presn...@qti.qualcomm.com wrote: On 8/15/13 2:06 PM, SM wrote: At 11:48 14-08-2013, IAB Chair wrote: This is a call for review of List of Internet Official Protocol Standards: Replaced by an Online Database prior to potential approval as an IAB stream RFC. My guess is that draft-rfced-rfcxx00-retired cannot update RFC 2026. Does the IAB have any objection if I do something about that? [...] The document argues that STD 1 is historic as there is an online list now. The IESG and the IAB had an email exchange about these two points. Moving a document from Standard to Historic is really an IETF thing to do. And it would be quite simple for the IETF to say, We are no longer asking for the 'Official Protocol Standards' RFC to be maintained by updating (well, effectively removing) the one paragraph in 2026 that asks for it, and requesting the move from Standard to Historic. So I prepared a *very* short document to do that: http://datatracker.ietf.org/doc/draft-resnick-retire-std1/ FWIW, I've reviewed your draft and have three comments: (1) You are to be complemented on its length and complexity. (2) I agree that the core issue belongs to the IETF, and IETF Stream, issue, not the RFC Editor and/or IAB. (3) I far prefer this approach to the more complex and convoluted RFC Editor draft. If we really need to do something formally here (about which I still have some small doubts), then let's make it short, focused, and to the point. Your draft appears to accomplish those goals admirably. john
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
Hi Pete, At 12:01 20-08-2013, Pete Resnick wrote: The IESG and the IAB had an email exchange about these two points. Moving a document from Standard to Historic is really an IETF thing to do. And it would be quite simple for the IETF to say, We are no longer asking for the 'Official Protocol Standards' RFC to be maintained by updating (well, effectively removing) the one paragraph in 2026 that asks for it, and requesting the move from Standard to Historic. So I prepared a *very* short document to do that: http://datatracker.ietf.org/doc/draft-resnick-retire-std1/ I read the draft. I agree with what is written above. I'm asking Jari to Last Call it along with a status change for STD 1 (RFC 5000) to Historic. If the RFC Editor wants to explain more of the history and whatever else they're going to do in a separate document, that's up to the IAB. But declaring Standards to be Historic is something the RFC Editor or IAB shouldn't be doing. The above document solves the problem by making it clear that the IETF isn't interested in the document being updated anymore. I support moving the draft to Last Call as it solves the problem. Regards, -sm
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
On 8/20/13 3:26 PM, Phillip Hallam-Baker wrote: If the data is in a database then surely the production of RFC xx00 standards series is simply running an automated query on the database and emitting the result as an RFC? I'm sure that such a tool could be created. To date, I believe the document was being built by hand. However, the document hasn't been produced in over 5 years and nobody seems to miss it. The RFC Editor has indicated that they're not enthusiastic about keeping the document up to date given that there's a web page with that information that is getting good use. So the thinking behind the document I submitted was, Let the RFC Editor off the hook. We, the IETF, don't need the RFC published separately anymore, so we should just say that. I suppose if there's a real resurgence of sentiment that the RFC Editor should keep producing that document, we can tell the IAB that the IETF still really wants that document produced and send them off to write a tool that queries their database and auto-creates the RFC. In the absence of such sentiment, I think we should just use the web-based database and clean up the STD series as stated. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
From a pure protocol point of view the SPF record does have one major advantage over TXT and that is in the use of wildcard records. In short a wildcard on a TXT record for SPF is going to have impact on every other scheme that overloads TXT, of which there are many. SPF does have a mechanism to resolve the ambiguity but that does not stop the record sets from getting to be larger than will fit in DNS UDP responses. This has not been much of a problem because most of the other TXT overloads don't have a use for a wildcard. There is not much point in a wildcard DANE record. But it could be an issue. So keeping SPF records does actually have a utility since it allows wildcarded records to be isolated from other protocols and avoiding the wildcard record set bloat issue. The criteria to use to decide is not the proportion of SPF records published as TXT vs SPF but what the validators look for. If at this point there is little to no takeup by the validators for the SPF RR then it is time to call time on a failed experiment. If there was a significant support base for SPF RR validation then it is a harder call.
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
On 8/20/2013 3:01 PM, Pete Resnick wrote: On 8/15/13 2:06 PM, SM wrote: At 11:48 14-08-2013, IAB Chair wrote: This is a call for review of List of Internet Official Protocol Standards: Replaced by an Online Database prior to potential approval as an IAB stream RFC. My guess is that draft-rfced-rfcxx00-retired cannot update RFC 2026. Does the IAB have any objection if I do something about that? [...] The document argues that STD 1 is historic as there is an online list now. The IESG and the IAB had an email exchange about these two points. Moving a document from Standard to Historic is really an IETF thing to do. And it would be quite simple for the IETF to say, We are no longer asking for the 'Official Protocol Standards' RFC to be maintained by updating (well, effectively removing) the one paragraph in 2026 that asks for it, and requesting the move from Standard to Historic. So I prepared a *very* short document to do that: http://datatracker.ietf.org/doc/draft-resnick-retire-std1/ I'm asking Jari to Last Call it along with a status change for STD 1 (RFC 5000) to Historic. If the RFC Editor wants to explain more of the history and whatever else they're going to do in a separate document, that's up to the IAB. But declaring Standards to be Historic is something the RFC Editor or IAB shouldn't be doing. The above document solves the problem by making it clear that the IETF isn't interested in the document being updated anymore. pr I support this. But it also raises a couple other questions. What about rfcxx99 series, published along with the rfcxx00 series? Were they ever formally retired? After rfcxx00 is retired, can the RFC editor start using both xx99 and xx00 as normal RFC numbers? I'm not saying that Pete Tony Hansen
Re: Call for Review of draft-rfced-rfcxx00-retired, List of Internet Official Protocol Standards: Replaced by an Online Database
On 8/20/13 4:21 PM, Tony Hansen wrote: I support this. But it also raises a couple other questions. What about rfcxx99 series, published along with the rfcxx00 series? Were they ever formally retired? That's not an IETF matter. There's no STD on this. There's nothing (AFAICT) in a BCP about this. So nothing for the IETF to do. After rfcxx00 is retired, can the RFC editor start using both xx99 and xx00 as normal RFC numbers? Again, entirely up to the RFC Editor. The IETF never documented that particular numbers would be used for such purposes; that's entirely an RFC Editor convention (again, AFAICT). pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
On Aug 20, 2013, at 02:39 , Lorenzo Colitti lore...@google.com wrote: [...] It seems to me that the sheer length of the list, and the fact that is not prioritized, create a real risk that implementors will simply write it off as wishful thinking or even shy away in terror. [...] My views on the technical merits of this draft remain unchanged from the last time I offered them here, and I am basically in agreement with Lorenzo. This draft seems unnecessary to me. -- james woodyatt j...@apple.com core os networking
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
On 8/20/2013 9:08 AM, Andrew Sullivan wrote: On Tue, Aug 20, 2013 at 08:54:02AM -0700, Dave Crocker wrote: In other words, the specific technical limitations being noted are unfortunate but (so far) not serious. You should explain that to my employer's support department. In any case, I don't think this topic is directly relevant to the SPFBIS discussion, so I'll not comment on it further. The construct has been standardized multiple times, going back at least 13 years, is very widely deployed and very heavily used. In other words, it is very fully incorporated into Internet infrastructure services. In the face of that, any support group that spends its time complaining about the construct is ignoring pragmatics and is, instead, paying attention to other issues. For a support group, that means the issue is not technology or operations, but rather organizational management. I'd be glad to assist your employer in helping its support team to reassess its priorities. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
No hat. On Tue, Aug 20, 2013 at 05:16:56PM -0400, Phillip Hallam-Baker wrote: From a pure protocol point of view the SPF record does have one major advantage over TXT and that is in the use of wildcard records. This is an extremely interesting point, and I'm ashamed to admit I hadn't really thought about it from quite this perspective. I say that even though the draft contains some text that attempts to deal with wildcards and the WG discussed the issue from a slightly different perspective. I think it is worth considering. Note, however, that … This has not been much of a problem because most of the other TXT overloads don't have a use for a wildcard. There is not much point in a wildcard DANE record. But it could be an issue. …it wouldn't be an issue for most of the cases where TXT is overloaded, because (partly due to the mess that SPF caused) most of the TXT overloads we see are now scoped using underscore labels, where the wildcard at a superordinate place in the FQDN isn't going to matter. Phill's is still a valuable observation, and one I think the WG actually didn't consider in every dimension. The criteria to use to decide is not the proportion of SPF records published as TXT vs SPF but what the validators look for. The WG had a hard time coming up with really good data about what validators look for, but to the extent we were able to draw conclusions about that the evidence was that virtually nobody is looking for SPF records. This is mentioned at the end of section 3.1 of RFC 6686. If someone else with some busy nameservers wants to provide different evidence now, it wouldn't hurt. We were unable to find anyone among the participating validators in the SPFBIS WG who was willing to argue in public that they felt the SPF lookup was more valuable to them, but we did have some large participants who said they did _not_ do the TYPE99 lookup except under unusual circumstances (the draft author, who is also the maintainer of an important SPF library, has already made this point elsewhere in this thread). Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Martin Further to our conversation on this topic in Berlin I now respond formerly on the list. 3GPP has defined the mobile terminal as performing the UA role since the very beginning of IMS. Therefore the mapping between the terminal and the instance ID in IMS is a one to one relationship. Andrew - Original Message - From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Monday, July 22, 2013 12:57 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On 20 July 2013 15:34, Andrew Allen aal...@blackberry.com wrote: There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message? I think that reading this thread should provide you with ample reasons. The instance ID in outbound has certain stability requirements that do not strictly correspond to the lifetime of the hardware in use. The other use cases answer very different questions, which include: is this a stolen device, is this device authorized to use the networks, etc... I'm certain those questions can be answered without a device identifier traversing the network. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Last Call: draft-ietf-mediactrl-call-flows-13.txt (Media Control Channel Framework (CFW) Call Flow Examples) to Informational RFC
The IESG has received a request from the Media Server Control WG (mediactrl) to consider the following document: - 'Media Control Channel Framework (CFW) Call Flow Examples' draft-ietf-mediactrl-call-flows-13.txt as 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 i...@ietf.org mailing lists by 2013-09-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 a list of typical Media Control Channel Framework call flows. It aims at being a simple guide to the use of the interface between Application Servers and MEDIACTRL-based Media Servers, as well as a base reference documentation for both implementors and protocol researchers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mediactrl-call-flows/ballot/ No IPR declarations have been submitted directly on this I-D.
