Re: Deployment of standards compliant nameservers
Keith asked for a ID. Filename:draft-andrews-dns-no-response-issue Revision:00 Title: A Common Operational Problem in DNS Servers - Failure To Respond. Creation date: 2013-05-21 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-andrews-dns-no-response-issue-00.txt Status: http://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue Htmlized: http://tools.ietf.org/html/draft-andrews-dns-no-response-issue-00 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/20/13 6:42 PM, Brian E Carpenter wrote: On 21/05/2013 13:06, John C Klensin wrote: --On Monday, May 20, 2013 19:49 -0400 Rob Austein s...@hactrn.net wrote: At Mon, 20 May 2013 10:18:21 -0400, John C. Klensin wrote: This is not my primary (or even secondary) area of expertise but, given that the RR space is not unlimited even though it is large, wouldn't it be better to have a single RRtype for IEEE-based EUIs with a flag or other indicator in the DATA field as to whether a 48 bit or 64 bit identifier was present? Short answer: Probably not, but it depends on the application. Longer answer: See RFC 5507. Rob, I've reread 5507 and did so again before writing my second note today. I don't see that it helps. I haven't heard anyone proposing use of TXT (or any existing RRTYPE) instead, so that is presumably a non-issue. The discussion in 3.1 clearly applies to relatively complex schemes like NAPTR, but it is not clear that it has anything to do with this case. In particular, if I correctly understand the IEEE's allocation scheme for longer identifiers (and I may not) than a given device gets only one -- this is not analogous to a dual-stack IPv4/IPv6 arrangement -- and an application gets back whatever it gets back (whether the query is addressed to the DNS, read off a label on the device and entered manually, or something else). If so, then one RRTYPE with the appropriate identifier in the data is the right answer. If not... if, for example, different types of applications will look for only one type-length of identifier and will either find it or give up (not try falling back to the other because that would make no sense), then the use of two RRTYPEs is entirely reasonable. But, if that is the case and this is going to be standards track, I expect to see an explanation in the document. That explanation could be as simple as a statement to that effect and an example or two of the types of applications that would use each identifier and/or a reference to IEEE materials that describe the circumstances under which one example or the other is used. I'm not opposed to having two separate RRTYPEs -- I just want to see the rationale. And what passes for use cases in the draft appears to me to be completely silent on that issue. Especially since there is an IEEE-defined method for representing a 48-bit address in the 64-bit format. Now you mention it, why can't that be used in all cases? two observations If you have an iab range the eui label would get inserted in the middle of the IAB base value iirc. that sounds sort of appauling to read/decode. Second it's not just a representation it's an encapsulation (you could if you so choose use a mac-48 on an eui-64 supporting link layer legitimately using the encapsulation). I'm sure some ugly bridge device that I want nothing to do with will do that some time in the future, it does therefore seem slightly desirable to render them as they are rather than in some canonical form that is both. Brian
IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Dan and John, Thanks for the exchange last week. As chair of ICANN's Board of Directors and an active participant in ICANN's current effort to take a fresh look at the Whois architecture and operation, your notes catch my attention in multiple ways. But first, for the benefit of under forty crowd, let me briefly introduce myself. In the late 1960s I chaired the ARPANET's Network Working Group, which eventually morphed into today's IETF. I created the RFC series and I was one of the architects of the three facets of openness that are the foundation of the Internet protocol process, viz open architecture, open participation and open publication. In the late 1980s and early 1990s I served as the first area director for security and later on the IAB. I also co-chaired the POSIED Working Group that revised the standardization process, moving the authority from the IAB to the IESG, and in the mid 2000s I served on the ISOC board and participated in the formation and initial operation of the IETF Administrative Support Activity (IASA) and I served on its IAOC. For the past 11 years I've been active in ICANN, serving for several years as the chair of the Security and Stability Advisory Committee and also on the board of ICANN, and about two years ago I was elected chair of the ICANN board. And despite having spent a great deal of time in management and political roles in this environment, I remain fundamentally a technical person. I want to share two thoughts, one about the role of the IETF, ICANN and other organizations within the Internet ecosystem, and one about Whois. The great strength of the IETF is it's a forum for technical people to come together, work out the details of protocols, and publish consensus documents. The IETF does not have any formal powers granted by legal authorities. IETF standards are effective because they're accepted and they work, not because they're imposed on anyone. IETF standards are respected around the world because they embody the wisdom and experience of the technical community. No one is obliged to use the protocols created within the IETF, but, of course, a huge portion of the world does use these protocols. ICANN was created in 1998 to operate the IANA function and to expand and organize the marketplace in domain names. The IANA function is fundamentally a clerical service. It records the assignment of unique identifiers that are used throughout the Internet, and it does so in accordance with the values and policies established by the community. The IANA service includes publication of the IETF's protocol parameters, allocation of blocks of AS numbers, IPv6 address blocks, and, until recently, IPv4 blocks to RIRs, and administration of the top level of the domain name hierarchy. Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. As I write this, I am at a retreat for the ICANN Board focusing on strategic planning. One of the seats on the Board is allocated to a liaison from the IETF, and thus I am actually sitting at the time I drafted this note in between Thomas Narten and Jonne Soininen, the outgoing and incoming IETF liaisons to the ICANN Board. One of the large and often time-consuming activities within ICANN is the development of policies that pertain to the domain name system. John Curran wrote: To be abundantly clear, you are hypothesizing a difference of opinion between the IETF/IESG and the ICANN/RIR communities, wherein the technical guidance of the IETF was considered during the ICANN/RIR decision process, but in the end the outcome was contrary to IETF expectations. This would be an unfortunate (but not impossible) situation, as many folks in the combined community would likely have been involved during the process trying to figure out why there is such a significant difference in views and facilitating sharing of the beliefs and thought processes that underlie the situation. I agree completely with John. It is indeed possible for ICANN to adopt policies that are not perfectly aligned with IETF recommendations. Possible, but not usual. Over here at ICANN we pay a LOT of attention to the IETF. We depend heavily on the IETF's work and we never seek to duplicate or ignore it. (I sometimes have to explain to my colleagues at ICANN who have not had the benefit of the IETF experience that let's send it over to the IETF doesn't work. The IETF isn't a standing army ready to do ours or anyone else's work. Rather, I say, it's a place where the relevant people can get together to get their work done. And, indeed, a number of ICANN people actively participate in various
Re: Deployment of standards compliant nameservers
On Tue, May 21, 2013 at 10:26:39AM +1000, Mark Andrews ma...@isc.org wrote a message of 52 lines which said: I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period Let's not reinvent the wheel: I suggest to first study the experience of the TLD which did exactly that. .fr had mandatory technical tests of the name servers almost from its inception, until december 2012. The tool used for the tests was Zonecheck http://www.zonecheck.fr/ Although these tests certainly contributed to the good technical quality of the name servers, they were removed both for commercial reasons (a registry has to make money to pay its employees) and because it was easier to have the same rules for ccTLDs and gTLDs (and ICANN forbids these technical tests in gTLDs).
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
dear emperor, despite the braggadocio, there seems to be a shortage of attire. icann is notorious for pretending to be open but being effectively closed. it solicits public comment and ignores it. i could go on and on, but i am far less wordy. randy
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 21/05/2013 10:42, Steve Crocker wrote: As I said above, I invite anyone who is interested to participate. The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have all arisen within the ecosystem that accompanies the growth and prevalence of the Internet. It is natural for there to be some tension, competition and rivalry among our institutions, but we have all been part of the same grand enterprise, we all share the same core values, and we all work toward the same goal of an open, innovative, expanding Internet. +1 to everything Steve has said. And I take this opportunity to remind you that you can directly influence the outcome of *all* the work at ICANN by taking part in it. There are several avenues for this. One of them is through the ALAC: the At-Large Advisory Committee's (ALAC) role is to facilitate input from Internet users into the ICANN policy processes. It does not purport to represent Internet users, but it tries as much as it can to act in the *best interests* of Internet users. But without your input and particularly on technical issues where we need as much help as we can get, the ALAC cannot issue Statements that adhere to the general point of view of Internet users. How can you take part? The North American region allows for individual membership. Other regions require that you are part of an At-Large Structure (ALS) to participate - but if you see the list, you'll notice there are a LOT of ALSes, many of which are ISOC Chapters. And you do NOT need to be part of an At-Large Structure to participate in the At-Large Working Groups. Membership is only needed for matters of voting - and since we operate by consensus, that's a rare occurrence, usually only kept to selection of leadership. A few links: ALAC Correspondence: http://www.atlarge.icann.org/correspondence ALAC Policy Development: https://community.icann.org/x/bwFO ALAC Working Groups: https://community.icann.org/x/loIi I know this is a shameless plug but in the face of the threat posed by non-multi-stakeholder systems of governance, I felt a follow-up on Steve's post was necessary. As Steve says so eloquently, we need to all work toward the goal of an open, innovative, expanding Internet. Warm regards, Olivier MJ Crépin-Leblond ALAC Chair https://community.icann.org/x/ppEi
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Dear Randy, On 21/05/2013 11:58, Randy Bush wrote: dear emperor, despite the braggadocio, there seems to be a shortage of attire. icann is notorious for pretending to be open but being effectively closed. it solicits public comment and ignores it. i could go on and on, but i am far less wordy. randy Quite frankly, I used to have the same feeling... until very recently. With Steve at the wheel, things have improved a lot. Whilst as recently as 3 years ago, we often used to feel that ALAC advice was tossed over the wall and we'd never hear any feedback be blatantly ignored, things have improved and we are heard and more importantly listened to a lot more. Credit for this is due to the new Leadership Teams, both on the volunteer Staff parts of ICANN. Today, it's still not perfect, but you cannot fix a bus by shooting it - work on it instead, to fix it. I believe it's fixable. Start here: http://www.icann.org/en/news/public-comment/atrt2-02apr13-en.htm Kind regards, Olivier (not wearing any hat) -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html
Re: Deployment of standards compliant nameservers
In message 20130521090727.gb17...@nic.fr, Stephane Bortzmeyer writes: On Tue, May 21, 2013 at 10:26:39AM +1000, Mark Andrews ma...@isc.org wrote a message of 52 lines which said: I'm not sure what the solution should be but regular audits of delegated nameservers by infrastructure operator and removal of delegations after a grace period Let's not reinvent the wheel: I suggest to first study the experience of the TLD which did exactly that. .fr had mandatory technical tests of the name servers almost from its inception, until december 2012. The tool used for the tests was Zonecheck http://www.zonecheck.fr/ Although these tests certainly contributed to the good technical quality of the name servers, they were removed both for commercial reasons (a registry has to make money to pay its employees) and because it was easier to have the same rules for ccTLDs and gTLDs (and ICANN forbids these technical tests in gTLDs). Which is one of the reasons I wanted to IESG to bring ICANN into the discussions. It need to be a level playing field applied to everyone. Not also this is not checking the delegation. It is checking to nameserver implementation. All ICANN documents I have read presume that a RFC compliant nameservers are being deployed. Nameservers that fail to respond are not RFC compliant. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/20/2013 04:08 PM, Brian E Carpenter wrote: Publication of EUI-48 or EUI-64 addresses in the global DNS may result in privacy issues in the form of unique trackable identities. This might also result in such MAC addresses being spoofed, thereby allowing some sort of direct attack. So it isn't just a privacy concern. ... These potential concerns can be mitigated through restricting access to zones containing EUI48 or EUI64 RRs or storing such information under a domain name whose construction requires that the querier already know some other permanent identifier. This can be seems too weak. Shouldn't we have a MUST here? Also, I doubt that the second option (a shared secret) is sufficient. And yet, multifaced DNS is also a bad idea, and probably not the sort of thing that IETF should encourage with a MUST. Publishing EUI-XX addresses in the DNS is a bad idea. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 2013-05-21, at 09:36, Keith Moore mo...@network-heretics.com wrote: Publishing EUI-XX addresses in the DNS is a bad idea. With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call. There has been very little review of the actual specification in this thread to date. RRType assignments are made based on expert review, not IETF consensus, document published, or any other criteria. In this case, the RRTypes have been assigned and are known to have three independent implementations. I'm not sure how the Internet benefits from not publishing a specification in a sensible place (and the RFC series is surely the most sensible place). *I* think it's a good idea for this specification to be published as an RFC. The topics of whether the current RRType assignment process is appropriate, or whether storing these IEEE addresses in the DNS is a good or bad idea or whether sub-typing would be useful in any as-yet unknown future use case seem entirely tangential. This is not to say they are not useful topics, but I don't see how they relate to this document. Whether or not this document proceeds has nothing to do with any of that. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more. Joe
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 10:04 AM, Joe Abley wrote: On 2013-05-21, at 09:36, Keith Moore mo...@network-heretics.com wrote: Publishing EUI-XX addresses in the DNS is a bad idea. With respect, *my* question as the author of this document is simply whether the specification provided is unambiguous and sufficient. It was my understanding that this was the question before the community in this last call. The criteria for Proposed Standard are quite a bit higher than that. See RFC 2026 section 4.1.1. TThe topics of whether the current RRType assignment process is appropriate, or whether storing these IEEE addresses in the DNS is a good or bad idea or whether sub-typing would be useful in any as-yet unknown future use case seem entirely tangential. Assignment of the RR types (though IMO unfortunate) is a separate issue.Granting Proposed Standard status would essentially be an endorsement of this practice by IETF. This is not to say they are not useful topics, but I don't see how they relate to this document. Whether or not this document proceeds has nothing to do with any of that. I get the impression that we're bending over backwards to try to create new security risks with this document, and people are trying to justify it by citing freedom to innovate. IMO, that's not the kind of innovation that IETF should be endorsing. I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more. Perhaps Informational or Experimental would be a better label for this document, then. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 2013-05-21, at 10:18, Keith Moore mo...@network-heretics.com wrote: Perhaps Informational or Experimental would be a better label for this document, then. Informational was my original plan; I was persuaded by Some People that the standards track was more appropriate. As I mentioned, my objective is simply to publish the specification. If the community is more comfortable with the publication objective being met with informational rather than standards track, I'm fine with that. Joe
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 21, 2013 10:04 -0400 Joe Abley jab...@hopcount.ca wrote: ... There has been very little review of the actual specification in this thread to date. RRType assignments are made based on expert review, not IETF consensus, document published, or any other criteria. In this case, the RRTypes have been assigned and are known to have three independent implementations. I'm not sure how the Internet benefits from not publishing a specification in a sensible place (and the RFC series is surely the most sensible place). *I* think it's a good idea for this specification to be published as an RFC. Joe, as the person with the dubious distinction of having started this thread when the Last Call was announced, I'm not questioning the desirability of good documentation of any RRTYPE, nor do I doubt the fact that these were properly assigned and are deployed. I also agree with you that questions about the expert review process belong elsewhere (and I don't know that I'd want to change it in any formal way). Had you written this document as a this is how it is -- this is to tell the community about what is deployed informational one that described the RRTYPEs and asked that it be published as Informational, I wouldn't have been likely to raise any objections. Had the Security Considerations section or privacy discussion described the risks, possibly explained how they might be mitigated, but basically said if those are a big enough problem for you, don't use this facility, that wouldn't have been a problem for me: I can't speak for Keith, but you might have not heard from him either. But the document has been Last Called as an Proposed Standard, not that type of informational document. That, at least to me, makes both discussions of your design decisions and the relevant security and privacy mechanisms entirely appropriate because Proposed Standard requires IETF consensus approval of the whole package, quite independently of your ability to register a new RRTYPE (or two or three). All I'm asking for is that, if you want this as a Proposed Standard you carefully and convincingly describe your design rationale. I want that both because it seems generally appropriate in this case and because, if someone comes along and wants to register the EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and there is pushback because EUI48 and EUI64 are already registered, I think it is important that pushback be based on documented and well-reasoned design choices, not an appeal to the supposed authority of the IETF. You wrote a bit later: Informational was my original plan; I was persuaded by Some People that the standards track was more appropriate. As I mentioned, my objective is simply to publish the specification. It might be that no one could know before this discussion started but, at least in retrospect, those Some People may have steered you in the wrong direction if your goal and theirs was to get something published without putting various design decisions into the spotlight. To say what Keith may be saying in different language, there is lots of stuff floating around the Internet of which the IETF might not approve. Publishing Informational RFCs containing descriptions of them so they can be understood is still a good thing. If someone wants to follow those RFCs with considered harmful or at least disgusting commentary and try to get it published, that is a separate issue. But asking for Proposed Standard is a rather different matter because it requires an IETF consensus assertion that the criteria of RFC 2026 have been satisfied. If you don't think that level of scrutiny is appropriate for this situation, ask that the document be pulled from Last Call, review it to make it as descriptive and declarative as possible rather than even implicitly normative (I'd have to reread, but I think it is at least close on that criterion), and then resubmit it as an individual or independent submission for Informational publication. I have no real idea where you get that impression. The goal of this document is to document the use of RRTypes that have already been assigned, to provide a more structured option for encoding data that is already published in the DNS using non-interoperable and clumsy encoding schemes. Nothing more. Ok. That, to me, is a perfect recipe for an Informational document. It may, separately, be a call for a much more aggressive denunciation and deprecation of overloaded and trickily-encoded TXT RRs than RFC 5507 provides, maybe as a BCP rather than IAB-Informational but that is also a separate issue and problem. best, john
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
joe, i have read the draft. if published, i would prefer it as a proposed standard as it does specify protocol data objects. where you goin' with that gun in your hand? i am not at all sanguine about the issues raised in the in sec cons. i accept that NTRE038D may have asked that these be in the dns, but seems to me that it is ill advised and some other means to meet their actual needs might be found. e.g. what's the matter with logs? nits you are welcome to ignore. 1 - intro - do we have a standard way to refer to the dns specs as tuned in 42 subsequent rfcs since 1035? 3.2 and 4.2 the presentation format specs might be simpler if the examples in 5 were moved there 6 - the example use case is as much or more a motivation as an example randy
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Not related to the draft as such (whose publication, incidentally, I support): On Tue, May 21, 2013 at 10:23:03PM +0700, Randy Bush wrote: 1 - intro - do we have a standard way to refer to the dns specs as tuned in 42 subsequent rfcs since 1035? Alas, no. Some time ago, DNSEXT was re-vivified in an effort to write a protocol profile that would have been a nice roll-up document to do this. But there was no energy to get the work done and the drafts languished for months without any changes. It still seems a worthwhile project, but there is no evidence that we have a population interested enough to do the work. Best, A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/21/13 8:06 AM, John C Klensin wrote: All I'm asking for is that, if you want this as a Proposed Standard you carefully and convincingly describe your design rationale. I want that both because it seems generally appropriate in this case and because, if someone comes along and wants to register the EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and there is pushback because EUI48 and EUI64 are already registered, It seems like we're still re-arguing the assignment of the rr-types. It doesn't seem like future assignments are likely to have anymore pushback than present. With respect to the question of proposed standard. What changes if the requested status is informational?
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. Given that the RR types have already been assigned, documenting them seems entirely appropriate. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability. I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document? Joe
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 11:52 AM, Joe Abley wrote: On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability. I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document? 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:52 AM, Joe Abley wrote: On 2013-05-21, at 11:50, Keith Moore mo...@network-heretics.com wrote: On 05/21/2013 11:46 AM, joel jaeggli wrote: With respect to the question of proposed standard. What changes if the requested status is informational? I think just get rid of the normative language - SHOULDs, MUSTs, etc. From the perspective of giving guidance to people implementing these RRTypes, it seems to me that the normative language is useful, perhaps even necessary, to ensure interoperability. I admit I have not done my homework here; is the suggestion that the 2119 normative language cannot (MUST NOT? :-) appear in an informational document? 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Joe
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that. Keith
Re: Deployment of standards compliant nameservers
On 21 May 2013, at 02:44, Keith Moore mo...@network-heretics.com wrote: p.s. I wonder if the problem you describe might at least partially be caused by DNS proxies and interception proxies, including but not limited to those incorporated in consumer-grade routers. Those are already addressed in RFC 5625. kind regards, Ray
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
Keith == Keith Moore mo...@network-heretics.com writes: Keith 2119 language is intended to describe requirements of Keith standards-track documents. Informational documents cannot Keith impose requirements. i think using 2119 language in informational documents is often appropriate and there are certainly plenty of examples of informational documents that use 2119 language.
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On May 21, 2013, at 8:56 AM, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents. Can you support that statement with a reference to an RFC or an IESG statement that supports it? Informational documents cannot impose requirements. Same request. I don't find either statement supported by RFC 2119 or 2026, or any updates to the latter, but I may have missed it. --Paul Hoffman
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 2013-05-21, at 12:02, Keith Moore mo...@network-heretics.com wrote: Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that. I'd be quite happy to work on such a document if there were others keen to contribute, review, etc, but I don't see it as anything specific to the specifications under discussion here. What am I missing? How is EUI48 more dangerous to the world than (say) TXT or NSAP? Joe
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Hi Steve, At 01:42 21-05-2013, Steve Crocker wrote: I want to share two thoughts, one about the role of the IETF, ICANN and other organizations within the Internet ecosystem, and one about Whois. The great strength of the IETF is it's a forum for technical people to come together, work out the details of protocols, and publish consensus documents. The IETF does not have any formal powers granted by legal authorities. IETF standards are effective because they're accepted and they work, not because they're imposed on anyone. IETF standards are respected around the world because they embody the wisdom and experience of the technical community. No one is obliged to use the protocols created within the IETF, but, of course, a huge portion of the world does use these protocols. IETF standards are de facto standards. It is doubtful whether some of the RFCs embody the wisdom and experience of the IETF community. Nobody may be obliged to use these standards. However, do people have a choice? How would I contact the IETF if my mail server uses another standard? Like the IETF, ICANN is also an open organization. ICANN meetings are free, and a veritable ocean of documents are published regularly, many in multiple languages to increase availability. I note that IETF meetings are not free. Everyone can claim to be open. ICANN is purposefully organized to include participation from a range of communities, e.g. business, civil society, governments, and the technical community. As I write this, I am at a retreat for the ICANN Board focusing on strategic planning. One of the seats on the Board is allocated to a liaison from the IETF, and thus I am actually sitting at the time I drafted this note in between Thomas Narten and Jonne Soininen, the outgoing and incoming IETF liaisons to the ICANN Board. There are currently three comments about the proposed Whois Information Status Policy ( http://www.icann.org/en/news/public-comment/wisp-10may13-en.htm ). There's more comments than that for some IETF Last Calls (e.g. http://www.ietf.org/mail-archive/web/ietf/current/msg79366.html ). The IETF Chair posted an article on his blog. There is a long thread about it ( http://www.ietf.org/mail-archive/web/ietf/current/msg78984.html ). The ICANN range of communities seem to be having problems sending mail as I don't see any trace of their participation. If I want to know what the IESG is up to, I read a web page and I find: abstract: the draft does stuff, it doesn't 'set out to' do stuff, at least not anymore of the IETF experience that let's send it over to the IETF doesn't work. The IETF isn't a standing army ready to do ours or anyone else's work. Rather, I say, it's a place where the relevant people can get together to get their work done. And, indeed, a number of ICANN people Agreed. actively participate in various IETF working groups.) I do not see ICANN people participating in an IETF Last Call. I would not call it active participation. The roster of topics active within ICANN at any given time is fully documented and publicized, and I invite anyone who is interested to participate. We listen to everyone, and we publish tentative results, tentative policies, etc. for everyone to critique. I am curious about where the ICANN process is documented. I could not find anything that looks like RFC 2026. within the generic top level domains. The country code top level domains are roughly the same number, and their Whois structures and policies are each controlled by the individual ccTLD operator and their communities. With all due respect I find it hard to believe that Whois structures and policies are controlled by the respective communities. and think through whether we might be better served by a revised system. An expert working group was assembled and is currently working through these issues. Its output will be a consideration of the issues and recommendations for further work. It is not yet clear whether the result of this effort will lead to a large change, a small change, or no change at all. What is clear is that the results of this working group will become fully public, and any decisions will come through our usual policy development process. The output of that working group was lacking. If an IETF working group cannot produce useful results it should be shut down. It seems that ICANN's measure is public and process instead of a results-oriented approach. The IETF, ICANN, the RIRs, ISOC, W3C and other organizations have all arisen within the ecosystem that accompanies the growth and prevalence of the Internet. It is natural for there to be some tension, competition and rivalry among our institutions, but we have all been part of the same grand enterprise, we all share the same core values, and we all work toward the same goal of an open, innovative, expanding Internet. Please note that I can
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Hi Olivier, At 03:00 21-05-2013, Olivier MJ Crepin-Leblond wrote: And you do NOT need to be part of an At-Large Structure to participate in the At-Large Working Groups. Membership is only needed for matters of voting - and since we operate by consensus, that's a rare occurrence, usually only kept to selection of leadership. The voting and consensus part reminds me of the ITU. The vote that happened last year has been the subject of numerous comments. I know this is a shameless plug but in the face of the threat posed by non-multi-stakeholder systems of governance, I felt a follow-up on Steve's post was necessary. As Steve says so eloquently, we need to all work toward the goal of an open, innovative, expanding Internet. I don't see any threat. What I see are words defined or redefined to suit the interests of the day. Regards, -sm
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
The scope of RFC 2119 is clearly standards-track documents. Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. Sent from my iPhone On May 21, 2013, at 12:08 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: On May 21, 2013, at 8:56 AM, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents. Can you support that statement with a reference to an RFC or an IESG statement that supports it? Informational documents cannot impose requirements. Same request. I don't find either statement supported by RFC 2119 or 2026, or any updates to the latter, but I may have missed it. --Paul Hoffman
Re: Gen-ART LC Review of draft-ietf-forces-interop-07
I agree with the modification points of the draft from Evangelos and Weiming. Regards, Kentaro Ogawa Original Message Hi Ben, Thank you very much for the review comments. Please see inline responses from authors of the document on the comments. Hi Sherpherd and AD, we will update a version very soon. thanks a lot. Weiming - Original Message - From: Ben Campbell b...@nostrum.com I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-forces-interop-07 Reviewer: Ben Campbell Review Date: 2013-05-13 IETF LC End Date: 2013-05-13 IESG Telechat date: Summary: This draft is almost ready for publication as an informational RFC. I have a few minor questions and editorial comments that may be worth considering prior to publication. *** Major issues: None. *** Minor issues: -- The draft mentions a couple of instances of tests that failed because of an incorrect implementation or differing encapsulation formats. Does this suggest that the specifications should be clarified? In particular, in the case of encapsulation format mismatch, should the specs include stronger requirements to be able to receive all encapsulation formats? Or should the number of options be reduced? [Re. by ΕΗ] The protocol provides a number of different approaches [Re. by Weiming] The key issue is still from the deep understanding of the protocol from implementations. I still have not seen need for any urgent change for the protocol. -- I have a mild concern that the use of origin country names for each implementation could confuse readers into thinking that the countries themselves officially participated, rather than organizations from each country. [Re by EH]Makes sense. We should possibly change this. In the beginning of section 2.2.1 where it says: The University of Patras implementation joined remotely from Greece Change to: The University of Patras (UoP) implementation joined remotely from Greece And then use UoP after that for us. [Re. by Weiming] I agree with Evangelos on this. If possible (key issue might be the text space for some figures) we may change the G to UoP, the J to NTT, the C to ZJSU ? Other authors, please show your views. Thanks. -- section 4.4, last paragraph: The text says that since the mentioned failures were likely the result of bugs, it doesn't indicate an interoperability problem in the specs. I have to point out that, it also doesn't prove interoperability in both directions for the particular test. It would also be worth commenting on whether the probably bugs were programming errors rather than misunderstandings of the specification. [Re. by Weiming] to change the whole paragraph to: t The two test items failed. Note that Test #7 and #8 were identical to the tests, only with CE and FE implementers were exchanged. Moreover, test #12 and #13 showed that the redirect channel worked well. Therefore, it can be reasonably inferred that the problem caused the failure was from the implementations, rather than from the ForCES protocol itself or from misunderstanding of implementations on the protocol specification. Although the failure made the OSPF interoperability test incomplete, it did not show interoperability problem. More test work is needed to verify the OSPF interoperability./t *** Nits/editorial comments: -- The draft uses inconsistent verb tense throughout. I found this a bit confusing, as I assume the draft talks entirely about tests that have already occurred. [Re. by ΕΗ] We will stick with the past tense. -- IDNits points out that you have several references without explicit citations. I see that you called the references out by name in the text, but it would be better to include the citations. [Re. by Weiming]We will try to fix this as much as possible. -- Section 1, paragraph 6: Please expand abbreviations on first mention. [Re. by Weiming] Yes. -- Section 1.1: Please expand FE on first mention. [Re. by Weiming] Yes. -- section 2.2.2, paragraph 1: ... from China and Japan implementations... Missing the. Is it possible to add a reference for details on the Smartbits testing machine? -- Figure 2: Do you really want to publish the IP addresses used in an RFC? RFCs live forever... -- Section 2.2.2, paragraph after figure 2: First sentence does not parse. [Re. by Weiming] In Figure 2, changed the '124.90.146.218 (ADSL)' to ' (ADSL)'. In Figure 3, changed the '150.140.254.110(VPN)' to '(VPN)' to avoid personal IP address in public. Section 2.2.2, paragraph after figure 2, first sentence is changed to: tCE and FE from the Greece implementation were located within the University of Patras, Greece, and were connected together using LAN as shown in xref target=Figure-3/. Connetion to the Internet
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On May 21, 2013, at 9:23 AM, Keith Moore mo...@network-heretics.com wrote: The scope of RFC 2119 is clearly standards-track documents. I'll take that as a no. The scope is mentioned exactly once, in the abstract but not in the body of the document. Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. I'm pretty sure that you as AD approved Informational RFCs that used 2119 language, and that this was discussed during your tenure on the IESG. The fact that there none of the updates to RFC 2026 even mention this suggests that there was not IETF consensus to the opinion. --Paul Hoffman
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
--On Tuesday, May 21, 2013 08:46 -0700 joel jaeggli joe...@bogus.com wrote: On 5/21/13 8:06 AM, John C Klensin wrote: All I'm asking for is that, if you want this as a Proposed Standard you carefully and convincingly describe your design rationale. I want that both because it seems generally appropriate in this case and because, if someone comes along and wants to register the EUI64-with-embedding or EUI-with-48-64-switch RRTYPEs and there is pushback because EUI48 and EUI64 are already registered, It seems like we're still re-arguing the assignment of the rr-types. I, at least, am not. It doesn't seem like future assignments are likely to have anymore pushback than present. Unless you are going to join the group that says it is perfectly ok to have multiple IETF standards-track documents that specify conflicting ways to do almost the same thing, it seems to me that pushback against other ways to handle EUI data is inherent in the standards track designation. The last time the IETF had the argument about conflicting standards, I think there was rough consensus that it was generally a bad idea even if some of us thought that exceptions might occasionally be desirable. With respect to the question of proposed standard. What changes if the requested status is informational? I don't agree with Keith that the removal of the keywords specified in 2119 is either necessary or sufficient (nor with the generalization that such language should never appear in Informational documents). Like Sam, I think that such language may sometimes be entirely appropriate to an informational/descriptive document although I also believe that it should be used with care. Since I don't have such an easy solution, answering your question would require a paragraph-by-paragraph review of the document, not the more overview-level reading I gave it before participating in this thread. Having made that proposal, I feel obligated to do that reading --essentially an editing pass-- but only if (i) you and Joe are inclined to process the document as Informational if the edit is satisfactory and (ii) it is understood that those edits will almost certainly not resolve the security and privacy concerns that have been raised, notably by Keith and Brian if the simple change to Informational does not do so. Note that (i) is not a request for a promise or decision, only a good-faith willingness to move in that direction. If I am going to do this, I'd prefer to make a pass and then sort out residual editorial details off list with Joe and anyone else who is significantly interested rather than trying to do editing on this list. If that seems reasonable and appropriate, I can commit to getting this done within the next week, maybe sooner, but not today. best, john
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
On 5/21/2013 8:50 AM, SM wrote: I gather that everyone is aware that civil society has been somewhat uncivil lately. That society has not made any significant negative comments about the IETF. Actually it has. Since he's such a long-active figure in those circles, check out Milton Mueller's Ruling the Root, from 10 years ago. He was quite critical and dismissive of the technical community, including the IETF: http://bbiw.net/musings.html#rootreviewl d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Deployment of standards compliant nameservers
On Mon, May 20, 2013 at 6:44 PM, Keith Moore mo...@network-heretics.comwrote: p.s. I wonder if the problem you describe might at least partially be caused by DNS proxies and interception proxies, including but not limited to those incorporated in consumer-grade routers. Given the funny things some firewalls used to do to SMTP sessions, I suggest tossing firewalls into that list.
Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
(Changing Subject lines -- this is about a set of general principles that might affect this document, not about the document) --On Tuesday, May 21, 2013 22:23 +0700 Randy Bush ra...@psg.com wrote: joe, i have read the draft. if published, i would prefer it as a proposed standard as it does specify protocol data objects. I would generally have that preference too. But it seems to me that the combination of -- RRTYPEs (and a bunch of other protocol data objects associated with different protocols) are allocated on expert review -- The fact that those protocol data objects have already been allocated is used to preempt IETF consideration of issues that normally go into Standards Track documents, including the criteria for Proposed Standards in 2026. is fundamentally bad news for reasons that have little to do with this document or RRTYPEs specifically. If the combination is allowed, it provides an attack vector on the standards process itself because someone can get a parameter approved on the basis of ability to fill out a template and then insist that the IETF approve and standardize it simply because it is registered and in use.That would turn allocation of parameters by expert review (and some related issues connected to deployed therefore it is ok -- watch for another note) into a rather large back door for standardization that could bypass the 2026 and other less formal criteria, the IETF's historically-strong position on change control, and so on. These are not new issues and we have historically dealt with them in a number of ways that don't require moving away from liberal allocation policies and toward the IETF is in charge of the Internet and has to approve everything. For example, we have decided that media types don't have to be standardized although certain types of names do. People then get to choose between easy and quick registration and standardization, but don't get to use the first to leverage the second. One could argue that the pre-IETF (and very early) division between system and user port numbers reflects the same sort of distinction between a high standard for justification and documentation and much lower ones. It is possible (although I'm not convinced) that this discussion should suggest some tuning of the allocation model for RRTYPEs. Probably that model is ok and we just need to figure out clearer ways to say if you want standards track, don't get an allocation first and try to use that as justification because you will get a real Last Call anyway and everyone will end up a little irritated. Or something else may be appropriate. But it seems to me that, as soon as one wants to say all protocol parameters or other data values should be standardized then allocation models based on expert review are inappropriate. For the RRTYPE case, that issue should, IMO, have been pushed with the relevant WG when the decision to allow expert review was made (and, again, IMO, that cure would be worse than the disease because it would indirectly drive more folks toward overloading of TXT and other existing types). best, john where you goin' with that gun in your hand? i am not at all sanguine about the issues raised in the in sec cons. i accept that NTRE038D may have asked that these be in the dns, but seems to me that it is ill advised and some other means to meet their actual needs might be found. e.g. what's the matter with logs?
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 5/21/13 9:02 AM, Keith Moore wrote: On 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. The basically rules out every internal split horizon use of DNS in existence. scope matters for this application just as it does for any zone you shouldn't be exposing to the outside world. Neither the DNS protocol nor DNS implementations are designed to meet the security requirements of such applications, and DNS is too widely deployed to change that. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 01:35 PM, joel jaeggli wrote: On 5/21/13 9:02 AM, Keith Moore wrote: On 05/21/2013 11:57 AM, Joe Abley wrote: On 2013-05-21, at 11:56, Keith Moore mo...@network-heretics.com wrote: 2119 language is intended to describe requirements of standards-track documents.Informational documents cannot impose requirements. Then I think we've just identified a reason why this document should be on the standards track. Actually I think that what we need is a BCP that says that DNS is not intended, not designed, and SHOULD NOT be used for dissemination of any information that is not deemed acceptable for widespread public distribution. The basically rules out every internal split horizon use of DNS in existence. Indeed. Things have gotten way too far out of hand. Again, DNS was not engineered for this purpose, and the hacks that people have employed like split-horizon DNS do not and cannot fix the underlying problems. Keith
Re: Last Call: draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard
On 05/21/2013 12:30 PM, Paul Hoffman wrote: Documents that aren't standards should not be worded as if they were; this is likely to cause confusion about the status of the document. I'm pretty sure that you as AD approved Informational RFCs that used 2119 language, and that this was discussed during your tenure on the IESG. My recollection is that other ADs were the ones who insisted that 2119 language not be used for Informational documents. I was more concerned about other things, but I could see their point. If the document is going to be published as Informational, rewording the document to remove 2119 language is my recommendation. But it's not something I feel like making a huge fuss over. If the document is still being considered as Proposed Standard, 2119 language would be appropriate. But I believe that this RRtype is fundamentally inappropriate for the standards track. Keith
Re: Proposed Standards and Expert Review
Without responding in detail to John's note, I'll say that I agree substantially with the notion that the fact that someone manages to get a protocol name or number registered, should not be any kind of justification for standardization of a document that describes use of that name or number. (For that matter, just because a document describes protocol data objects is also not a justification for standardization of that document.) More generally, IETF standardization should not be a rubber stamp. And to the extent that people have that notion, we would do well to discourage it. Keith
Re: Proposed Standards and Expert Review
On 2013-05-21, at 15:08, Keith Moore mo...@network-heretics.com wrote: Without responding in detail to John's note, I'll say that I agree substantially with the notion that the fact that someone manages to get a protocol name or number registered, should not be any kind of justification for standardization of a document that describes use of that name or number. If such a justification was inferred in my document, the problem is presumably my unclear language because no such justification was intended. (I am very happy for my document to be re-pointed at informational, incidentally, for which wheels are in motion. I will likely leave the normative language in, in the interests of improved interop, and see how far I get.) Code-points in the RRType registry are assigned by expert review (not simply by filling out a template as someone suggested earlier). If the suggestion is that the standards track is not available for any work that involves a code point that was assigned early, then I wonder what process is imagined for any future DNS work which aims at the standards track. Joe
Re: Proposed Standards and Expert Review
On 05/21/2013 12:08 PM, Keith Moore wrote: Without responding in detail to John's note, I'll say that I agree substantially with the notion that the fact that someone manages to get a protocol name or number registered, should not be any kind of justification for standardization of a document that describes use of that name or number. (For that matter, just because a document describes protocol data objects is also not a justification for standardization of that document.) More generally, IETF standardization should not be a rubber stamp. And to the extent that people have that notion, we would do well to discourage it. John has raised some excellent points. I tried to raise similar concerns on dnsext, albeit much more clumsily, and was told the code points are already assigned, so go away. There needs to be a happy medium, where getting new RRtypes assigned is not as difficult as it used to be, but some thought is given to whether or not the proposed solution is the best one, or even a good idea at all. It's a hard problem to solve, and I don't claim to know the right answer. Doug
Re: Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
On May 21, 2013, at 1:32 PM, John C Klensin john-i...@jck.com wrote: (Changing Subject lines -- this is about a set of general principles that might affect this document, not about the document) --On Tuesday, May 21, 2013 22:23 +0700 Randy Bush ra...@psg.com wrote: joe, i have read the draft. if published, i would prefer it as a proposed standard as it does specify protocol data objects. I would generally have that preference too. But it seems to me that the combination of -- RRTYPEs (and a bunch of other protocol data objects associated with different protocols) are allocated on expert review -- The fact that those protocol data objects have already been allocated is used to preempt IETF consideration of issues that normally go into Standards Track documents, including the criteria for Proposed Standards in 2026. is fundamentally bad news for reasons that have little to do with this document or RRTYPEs specifically. If the combination is allowed, it provides an attack vector on the standards process itself because someone can get a parameter approved on the basis of ability to fill out a template and then insist that the IETF approve and standardize it simply because it is registered and in use.That would turn allocation of parameters by expert review (and some related issues connected to deployed therefore it is ok -- watch for another note) into a rather large back door for standardization that could bypass the 2026 and other less formal criteria, the IETF's historically-strong position on change control, and so on. John, There are basically 3 different kinds of DNS RRtypes, - types that affect the behavior of the DNS protocol and are cached by resolvers, - types that have DATA and are cached by resolvers - meta Types that may affect processing but are not cached. DNSEXT in its wisdom has deemed the second group to be harmless as far as DNS is concerned and getting code to store data in DNS is a good thing, thus it is easy to get it. Getting code for the other classes requires IETF standards action. Documents that describe the DATA types use are encouraged to be published as Informational or some other stable reference. These are not new issues and we have historically dealt with them in a number of ways that don't require moving away from liberal allocation policies and toward the IETF is in charge of the Internet and has to approve everything. For example, we have decided that media types don't have to be standardized although certain types of names do. People then get to choose between easy and quick registration and standardization, but don't get to use the first to leverage the second. One could argue that the pre-IETF (and very early) division between system and user port numbers reflects the same sort of distinction between a high standard for justification and documentation and much lower ones. As I explained DNS RRtype allocation has this separation. It is possible (although I'm not convinced) that this discussion should suggest some tuning of the allocation model for RRTYPEs. Probably that model is ok and we just need to figure out clearer ways to say if you want standards track, don't get an allocation first and try to use that as justification because you will get a real Last Call anyway and everyone will end up a little irritated. Or something else may be appropriate. But it seems to me that, as soon as one wants to say all protocol parameters or other data values should be standardized then allocation models based on expert review are inappropriate. For the RRTYPE case, that issue should, IMO, have been pushed with the relevant WG when the decision to allow expert review was made (and, again, IMO, that cure would be worse than the disease because it would indirectly drive more folks toward overloading of TXT and other existing types). If the expert thinks an application crosses from DATA space to Control space he is expected to reject the application and ask for clarification. So far nothing has shown up that crosses this boundary, so there is no problem. I will go as far as saying why should there be higher bar for getting a DNS RRTYPE than MIME media type ? Olafur
Re: IETF, ICANN and Whois (Was Re: Last Call: draft-housley-rfc2050bis-01.txt (The Internet Numbers Registry System) to Informational RFC)
Hi Dave, At 10:03 21-05-2013, Dave Crocker wrote: Actually it has. Since he's such a long-active figure in those circles, check out Milton Mueller's Ruling the Root, from 10 years ago. He was quite critical and dismissive of the technical community, including the IETF: Thanks for the reference. I have read some messages [1][2] from the person. I don't recall reading the book. As the subject line mentions Whois I found something to read [3]. Regards, -sm 1. http://lists.arin.net/pipermail/arin-ppml/2012-April/024498.html 2. http://lists.ripe.net/pipermail/address-policy-wg/2012-April/006888.html 3. http://www.mendeley.com/download/public/777611/2362103122/da394283f86f68aa168abaf59d919f78d7c8f2b8/dl.pdf
Re: Gen-ART LC Review of draft-ietf-forces-interop-07
Thanks for the response. Comments inline. I removed sections for which I have no further comment. Thanks! Ben. On May 16, 2013, at 10:19 PM, Wang,Weiming wmwang2...@hotmail.com wrote: [...] -- The draft mentions a couple of instances of tests that failed because of an incorrect implementation or differing encapsulation formats. Does this suggest that the specifications should be clarified? In particular, in the case of encapsulation format mismatch, should the specs include stronger requirements to be able to receive all encapsulation formats? Or should the number of options be reduced? [Re. by ΕΗ] The protocol provides a number of different approaches [Re. by Weiming] The key issue is still from the deep understanding of the protocol from implementations. I still have not seen need for any urgent change for the protocol. I don't have enough knowledge of the protocol to form a specific opinion, but it's been my experience in other areas that when implementors interpret things differently, there's often room for clarification, even if the text is formally correct. I agree it doesn't imply an urgent need, but would it be worth one or more errata? [...] -- section 4.4, last paragraph: The text says that since the mentioned failures were likely the result of bugs, it doesn't indicate an interoperability problem in the specs. I have to point out that, it also doesn't prove interoperability in both directions for the particular test. It would also be worth commenting on whether the probably bugs were programming errors rather than misunderstandings of the specification. [Re. by Weiming] to change the whole paragraph to: t The two test items failed. Note that Test #7 and #8 were identical to the tests, only with CE and FE implementers were exchanged. Moreover, test #12 and #13 showed that the redirect channel worked well. Therefore, it can be reasonably inferred that the problem caused the failure was from the implementations, rather than from the ForCES protocol itself or from misunderstanding of implementations on the protocol specification. Although the failure made the OSPF interoperability test incomplete, it did not show interoperability problem. More test work is needed to verify the OSPF interoperability./t Works for me, thanks! [...] [Re. by Weiming] The section 3.2 para.3 has been changed to: t... Because there came unfortunately a problem with the test system in Greece to deploy IPSec over TML during the test process, this test only took place between test systems in China and Japan./t The sentence is still hard to parse. Do you mean the following? Because an unfortunate problem with the test system in Greece prevented the deployment of IPSec over TML, this test only took place between the test systems in China and Japan. [...]
Re: Proposed Standards and Expert Review
Without responding in detail to John's note, I'll say that I agree substantially with the notion that the fact that someone manages to get a protocol name or number registered, should not be any kind of justification for standardization of a document that describes use of that name or number. (For that matter, just because a document describes protocol data objects is also not a justification for standardization of that document.) More generally, IETF standardization should not be a rubber stamp. And to the extent that people have that notion, we would do well to discourage it. please leave me off the cc:s of your deep discussions of process and who has the prerogative to do what. i am merely reviewing the draft for content, not drm and ietf sausage. randy
Re: Proposed Standards and Expert Review (was: Re: Last Call draft-jabley-dnsext-eui48-eui64-rrtypes-03.txt (Resource Records for EUI-48 and EUI-64 Addresses in the DNS) to Proposed Standard))
--On Tuesday, May 21, 2013 15:42 -0400 Olafur Gudmundsson o...@ogud.com wrote: ... John, There are basically 3 different kinds of DNS RRtypes, - types that affect the behavior of the DNS protocol and are cached by resolvers, - types that have DATA and are cached by resolvers - meta Types that may affect processing but are not cached. DNSEXT in its wisdom has deemed the second group to be harmless as far as DNS is concerned and getting code to store data in DNS is a good thing, thus it is easy to get it. Getting code for the other classes requires IETF standards action. Seems perfectly reasonable Documents that describe the DATA types use are encouraged to be published as Informational or some other stable reference. Reasonable too. My problem here, which I hope was clear from the note from which you quoted, is that a request/document in the second category was proposed for Standards Track and then that comments that would be entirely appropriate for a Last Call on a Standards Track document were essentially rejected on the grounds that they would require changes to already-registered RRTYPEs. These are not new issues and we have historically dealt with them in a number of ways that don't require moving away from liberal allocation policies and toward the IETF is in charge of the Internet and has to approve everything. For example, we have decided that media types don't have to be standardized although certain types of names do. People then get to choose between easy and quick registration and standardization, but don't get to use the first to leverage the second. One could argue that the pre-IETF (and very early) division between system and user port numbers reflects the same sort of distinction between a high standard for justification and documentation and much lower ones. As I explained DNS RRtype allocation has this separation. But the request for publication in the Standards Track violates it. It is possible (although I'm not convinced) that this discussion should suggest some tuning of the allocation model for RRTYPEs. Probably that model is ok and we just need to figure out clearer ways to say if you want standards track, don't get an allocation first and try to use that as justification because you will get a real Last Call anyway and everyone will end up a little irritated. Or something else may be appropriate. But it seems to me that, as soon as one wants to say all protocol parameters or other data values should be standardized then allocation models based on expert review are inappropriate. For the RRTYPE case, that issue should, IMO, have been pushed with the relevant WG when the decision to allow expert review was made (and, again, IMO, that cure would be worse than the disease because it would indirectly drive more folks toward overloading of TXT and other existing types). If the expert thinks an application crosses from DATA space to Control space he is expected to reject the application and ask for clarification. We are agreed that isn't an issue here. So far nothing has shown up that crosses this boundary, so there is no problem. I will go as far as saying why should there be higher bar for getting a DNS RRTYPE than MIME media type ? With the understanding that I don't think it has anything to do with this situation, one could justify a different (and maybe higher) bar in two ways. First, the media type names are structured so that, a few historical exceptions aside, one can tell what category they are in by looking at the names. To get that effect with RRTYPEs, one would have to take the categories you spell out about and create (as a silly example) type names starting in 1 for the first category, 2 for the second, and so on, or otherwise lexically distinguish the second category from the other two. Second, the potential code space for media types may be a tad larger than the potential RRTYPE code space. But, again, I think the question is irrelevant here -- I've not advocating changing the allocation rules, only keeping the relationship between already-allocated RRTYPEs and the Standards Track into the categories you have described above. --On Tuesday, May 21, 2013 15:24 -0400 Joe Abley jab...@hopcount.ca wrote: Code-points in the RRType registry are assigned by expert review (not simply by filling out a template as someone suggested earlier). I was the one who said filling out a template and that reflects a bad attitude toward many expert reviews. That attitude and what underlies it has nothing to do with this situation. If the suggestion is that the standards track is not available for any work that involves a code point that was assigned early, then I wonder what process is imagined for any future DNS work which aims at the standards track. Presumably the same mechanism that has now been used for other registrations that are normally expert review (or less) but
NomCom 2012: Feedback Request - IAB
The IETF Nominating Committee (NomCom) is currently working to fill the IAB mid-term vacancy created by the resignation of Spencer Dawkins. The NomCom is requesting feedback from the community to help us fill this position. However, the NomCom needs to move quickly to fill this vacancy. Therefore, to be useful, the NomCom would greatly appreciate feedback received on or before Monday, June 3rd. We appreciate the responses to our previous call for nominations. The individuals we are currently considering for the IAB mid-term vacancy are: -- Hago Dafalla -- Jon Hudson -- Kathleen Moriarty -- Erik Nordmark -- Dimitri Papadimitriou -- Simon Pietro Romano -- Robert Sparks -- Margaret Wasserman The NomCom would greatly appreciate input from the community on general considerations that should be taken into account in filling the IAB vacancy. The NomCom would additionally appreciate community input related to particular individuals. The NomCom is happy to accept community input either via email to nomco...@ietf.org, or via the NomCom web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Note that use of the NomCom web feedback tool requires an ietf.org account. Anyone can acquire an ietf.org account at: https://datatracker.ietf.org/accounts/ Thanks you for your help, - Matt Lepinski nomcom-ch...@ietf.org
