RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Friday, December 02, 2011 3:59 PM To: SM Cc: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC On 11/30/2011 12:34 PM, SM wrote: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. Arguably, they already are: the text says should and that's a normative term in the document... (but no, I doubt Murray, really intended it and for some odd reason, I agree both docs /should/ be normative...) Yes, I've already changed my working copy. In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. +1 [...] The working copy now uses ADMD. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? +1 on the concern about using the correct term. The document needs to be much more clear and precise about this, since it is the essential semantic behind the spec and I think the current text is a bit confusing in that regard. SM and I agreed that changing it to authorized and also making reference to Section 1.5.2 of RFC5451 for a bit of further explanation should make it clearer, so that's done in the working copy. Does a signature by this on behalf of signer mean something different from a regular DKIM signature? It appears the current text means the answer to be yes. Correct, inasmuch as there are some people in the community who think author domain signatures might be more important or valuable than others. This memo doesn't make such an assertion, but merely acknowledges that perception. It should say this explicitly. If it is not redefining the existing, core DKIM semantic, it should say so. If it /is/ changing basic DKIM semantics, then this is more than an extension to DKIM. It is not. Section 1 of this draft reiterates that DKIM's core semantics don't extend to any kind of binding of the delivered, validated domain name to any part of the message. However, there are some people who believe that such a binding is valid and useful. This draft is meant for those people, without altering DKIM's base semantics. I suggest that the incremental semantic should merely be that the signature by an authorized signer should be interpreted as if the signature had been by the authorizing domain. It's a simple semantic and is, frankly, what I think is intended, based on the discussions surrounding this mechanism that I've heard. This is stated in Sections 5 and 6. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. +1 The definition used for Updates, as I understand it, is that we say X updates Y if someone implementing X really needs also to read Y in order to implement X completely. I don't think that's true here. In this case, RFC5617 stands on its own just fine without this addition. If I should be using some other criteria for doing the Updates, please let me know. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM- Signature Tag Specification Registry for the tags as they will appear on the Internet. +1 The working copy already has this change; specifically, Section 8.1 is still the template for a future registry creation, but the remaining subsections are now actionable by IANA. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
--On Saturday, December 03, 2011 08:43 +1300 Brian E Carpenter brian.e.carpen...@gmail.com wrote: ... We should ask a specific concrete question to a litigator who understands antitrust law: are there any significant gaps in the IETF process rules, including the formal Note Well warning given to all participants, that expose us (the IETF officers, the IETF Trust, the ISOC) to civil or criminal action in any jurisdiction? If the answer is no we're done. If yes, we'll know what to do. We amateur lawyers should shut up until we hear back from a professional. I'd like to agree, and do agree with the amateur part, but let me repeat an observation that others have made and suggest one other question. Observation: Just as we can almost always find a piece of a protocol description that can be tightened or clarified a bit, an experienced litigator can almost always find gaps that could be filled better if it were worth the trouble and one didn't care about the costs of filling them. An old adage comes to mind that one can make a computer 100% secure by isolating it from all power sources and external connections and then encasing it in a large block of concrete, opening or removing any covers before pouring the concrete. That makes your supposedly concrete (sic) and simple question hinge on significant and, as others have pointed out, attorneys (and anyone else good at their work) who are asked and paid to find potential problems will almost always do so. That other question: To the extent to which it is possible to conduct a meaningful conversation about antitrust-specific policies in the IETF (as distinct from other politics that may have useful or detrimental antitrust effects), is it possible to have that conversation in terms of our only individuals participate model, rather than doing so in terms of companies and other organizations who are expected to compete with each other. That is a harder question to ask and answer. But it seems to me to be crucial to, in your terms, knowing what to do. My own greatest concern about trying to develop an antitrust policy, or even to discuss whether one is needed, is that either the process or the results will lead us, backwards and unintentionally, into a membership model that is bound to companies, not individuals. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv6 not operational (was Re: Consensus Call: draft-weil-shared-transition-space-request)
Daryl Tanner wrote: The IPv6 chickens and eggs discussion could (and probably will) go on forever: service provider - no content IPv6 is the right answer, Wrong. IPv6 is not operational, which is partly why most service providers refuse it. For example, to purposelessly enable multicast PMTUD, RFC2463 (ICMPv6) mandates routers generate ICMPv6 packet too big against multicast packets, which causes ICMPv6 packet implosions, which is not operational. For further details, see my presentation at the last APNIC: How Path MTU Discovery Doesn't work http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Mark Andrews wrote: 224/10 could be made to work with new equipement provided there was also signaling that the equipment supported it. That doesn't help ISP that have new customers with old equipment and no addresses. Yes, it takes time. However, 224/4 (or most of it) and 240/4 (except for 255.255.255.255) should be released for unicast uses to reduce market price on IPv4 addresses. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gregorio-uritemplate-07.txt (URI Template)
- Original Message - From: Murray S. Kucherawy m...@cloudmark.com To: IETF Discussion ietf@ietf.org Sent: Saturday, December 03, 2011 1:50 AM -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Thursday, December 01, 2011 2:51 AM To: Mark Nottingham Cc: IETF Discussion Subject: Re: Last Call: draft-gregorio-uritemplate-07.txt (URI Template) The examples are rather complicated. If I have a month to spare, I will work my way through them by which time, were I to find anything, doubtless it would be erratum time and no longer LC time. (How simple life was in the days of -00). Perhaps, but very valuable when testing my implementation of what this specification contains. If they are right:-). I grew up at a time when, famously, all worked examples in school textbooks contained errors, which we delighted in finding. I occasionally do the same with the manuals of leading manufacturers:-( Tom Petch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gregorio-uritemplate-07.txt (URI Template)
- Original Message - From: Mark Nottingham m...@mnot.net To: t.petch daedu...@btconnect.com Cc: IETF Discussion ietf@ietf.org; draft-gregorio-uritempl...@tools.ietf.org Sent: Saturday, December 03, 2011 1:47 AM On 01/12/2011, at 9:50 PM, t.petch wrote: 2.3 Is undefined formally defined? This section suggests that 'undef' or 'null', inter alia, may be used to undefine a variable while 3.2 uses 'null'. I see no more formal definition of how to undefine a variable, as opposed to it having a value or having an empty value. Based on previous feedback, we're making a forward reference to 3.2.1 to clarify this. 1.2 worth pointing out that 'reserved' and 'unreserved' are formally defined in 1.5, to stop people reaching for RFC3986. If this is an issue, I'd actually prefer to place the notational conventions section higher in the document. Thoughts? tp No, I would not. I think that this I-D, unlike many, gets the sequence right, of explanation, formal definition and then the nitty-gritty. Moving 1.5 higher up would impair that. Rather, I would insert 'reserved and unreserved are formally defined in section 1.5 using the same definitions as appear in [RFC3986]' after the first paragraph of 1.2. Tom Petch The examples are rather complicated. If I have a month to spare, I will work my way through them by which time, were I to find anything, doubtless it would be erratum time and no longer LC time. (How simple life was in the days of -00). Thanks for the feedback, -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Hi, Murray, having read the draft I support its publication as experimental RFC. One suggestion: under 'Security Considerations' add a reference to what is said about DNSSEC in RFC6376 par. 8.5. In my opinion, the same consideration applies for this ATPS document. /rolf On 12/3/11 9:32 AM, Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Friday, December 02, 2011 3:59 PM To: SM Cc: ietf@ietf.org Subject: Re: Last Call:draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC On 11/30/2011 12:34 PM, SM wrote: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. Arguably, they already are: the text says should and that's a normative term in the document... (but no, I doubt Murray, really intended it and for some odd reason, I agree both docs /should/ be normative...) Yes, I've already changed my working copy. In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. +1 [...] The working copy now uses ADMD. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? +1 on the concern about using the correct term. The document needs to be much more clear and precise about this, since it is the essential semantic behind the spec and I think the current text is a bit confusing in that regard. SM and I agreed that changing it to authorized and also making reference to Section 1.5.2 of RFC5451 for a bit of further explanation should make it clearer, so that's done in the working copy. Does a signature by this on behalf of signer mean something different from a regular DKIM signature? It appears the current text means the answer to be yes. Correct, inasmuch as there are some people in the community who think author domain signatures might be more important or valuable than others. This memo doesn't make such an assertion, but merely acknowledges that perception. It should say this explicitly. If it is not redefining the existing, core DKIM semantic, it should say so. If it /is/ changing basic DKIM semantics, then this is more than an extension to DKIM. It is not. Section 1 of this draft reiterates that DKIM's core semantics don't extend to any kind of binding of the delivered, validated domain name to any part of the message. However, there are some people who believe that such a binding is valid and useful. This draft is meant for those people, without altering DKIM's base semantics. I suggest that the incremental semantic should merely be that the signature by an authorized signer should be interpreted as if the signature had been by the authorizing domain. It's a simple semantic and is, frankly, what I think is intended, based on the discussions surrounding this mechanism that I've heard. This is stated in Sections 5 and 6. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. +1 The definition used for Updates, as I understand it, is that we say X updates Y if someone implementing X really needs also to read Y in order to implement X completely. I don't think that's true here. In this case, RFC5617 stands on its own just fine without this addition. If I should be using some other criteria for doing the Updates, please let me know. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM- Signature Tag Specification Registry for the tags as they will appear on the Internet. +1 The working copy already has this change; specifically, Section 8.1 is still the template for a future registry creation, but the remaining subsections are now actionable by IANA. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 11-12-03 7:25 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Mark Andrews wrote: 224/10 could be made to work with new equipement provided there was also signaling that the equipment supported it. That doesn't help ISP that have new customers with old equipment and no addresses. Yes, it takes time. However, 224/4 (or most of it) and 240/4 (except for 255.255.255.255) should be released for unicast uses to reduce market price on IPv4 addresses. I have not objection to this. But anything that requires replacement of equipment only will have longer term benefit. (Built it, Ship it, Stock it, Sell it, put it in). I would also hope that when we have an opportunity to change out a box, it's with a IPv6 capable one (although it does not help that many boxes on the retail shelf are still IPv4-only - where we are). I wish to spend most of our time on IPv6 deployment (and only do what is necessary for IPv4 to keep the lights on). Activity working on getting equipment to utilize 240/4 seems like a lot of effort. I am not contending that the space will not have some influence on IPv4 prices, but I am not sure if the IETF is the right place to attempt and control market forces and the IPv4 Futures Market. Victor K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
Hi, I fully support Stewart! G.8113.1 proposes a OAM solution for MPLS-TP networks. It uses the MPLS EtherType (when transmitted inband and getting the same treatment as the data traffic). The document is built on G.8110.1 (MPLS-TP architecture) which refers to G.8110 (MPLS architecture), and G.8110.1 refers to G.8113.1 back... This makes it part of MPLS and MPLS-TP. And it should be reviewed by the MPLS WG. Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Stewart Bryant Sent: Friday, December 02, 2011 1:55 PM To: Adrian Farrel Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org; Ietf@ietf.org Subject: Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt Adrian It is the opinion of the document shepherd that discussion of this document on the working group lists would be a distraction from the technical protocol work that the working groups need to do. I disagree with the document shepherd in his evaluation. The draft clearly sets out to enable the standardization of an additional OAM for MPLS, and as such the MPLS WG need to review the document and its references to determine the consequences of the technology being deployed. Furthermore, all MPLS documents that have so far requested ACH codepoints have I believe been standards track. Why is this not also a standards track document? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
Based on my points in my mail below, please note that the proposed protocol is subject to the provisions of RFC4929 (MPLS Change Process) and must be reviewed by the MPLS WG using RFC4929. Please redirect it to the MPLS WG and follow the MPLS Change Process. Best regards, Nurit P.S. please note that the proposed solution is the same as draft-bhh-mpls-tp-oam-y1731-07 that was discussed in the MPLS WG. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon) Sent: Saturday, December 03, 2011 6:07 PM To: stbry...@cisco.com; Adrian Farrel Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org; Ietf@ietf.org Subject: RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt Hi, I fully support Stewart! G.8113.1 proposes a OAM solution for MPLS-TP networks. It uses the MPLS EtherType (when transmitted inband and getting the same treatment as the data traffic). The document is built on G.8110.1 (MPLS-TP architecture) which refers to G.8110 (MPLS architecture), and G.8110.1 refers to G.8113.1 back... This makes it part of MPLS and MPLS-TP. And it should be reviewed by the MPLS WG. Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Stewart Bryant Sent: Friday, December 02, 2011 1:55 PM To: Adrian Farrel Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org; Ietf@ietf.org Subject: Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt Adrian It is the opinion of the document shepherd that discussion of this document on the working group lists would be a distraction from the technical protocol work that the working groups need to do. I disagree with the document shepherd in his evaluation. The draft clearly sets out to enable the standardization of an additional OAM for MPLS, and as such the MPLS WG need to review the document and its references to determine the consequences of the technology being deployed. Furthermore, all MPLS documents that have so far requested ACH codepoints have I believe been standards track. Why is this not also a standards track document? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
On Nov 28, 2011, at 11:03 AM, Margaret Wasserman wrote: I don't know what an antitrust policy is... Could you explain? Is this something like a conflict of interest policy? Or is it a policy to avoid situations where we might be engaging in some sort of collusion? I'm not Russ, but I'll try. http://www.thefreedictionary.com/trusts: A combination of firms or corporations for the purpose of reducing competition and controlling prices throughout a business or an industry. http://www.thefreedictionary.com/antitrust: Opposing or intended to regulate business monopolies, such as trusts or cartels, especially in the interest of promoting competition While the EU doesn't use the word antitrust or trust - that is indeed US - it promotes competition. I would understand that the US and EU intent is largely similar, although it is stated from the opposite direction. In the IETF, I would expect that an antitrust policy would prevent individual companies or blocks of companies from controlling decisions or processes that might have the effect of preventing or discriminating against competition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: An Antitrust Policy for the IETF
On 12/3/2011 9:22 AM, Fred Baker wrote: In the IETF, I would expect that an antitrust policy would prevent individual companies or blocks of companies from controlling decisions or processes that might have the effect of preventing or discriminating against competition. That language looks pretty solid to me. Seems simple, clear, on point and reasonable. (I intend that as a hint to whoever winds up formulating IETF text on the topic, should that happen...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
Hi Huub and authors of draft-betts-itu-oam-ach-code-point, Thanks for issuing a publication request and supplying the Secretariat with a write-up. The document is entered in the datatracker and you can see its status at http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/ You suggested me as the sponsoring AD, so I will do the first steps to see how we should progress the draft. My process is from here on is as follows: - Review draft and shepherd write-up - Ask any questions and request a draft update if necessary - Consult the MPLS WG chairs and IESG about whether this needs to be run through the MPLS WG and whether RFC 4929 applies - Issue IETF last call if applicable Please note that I am travelling for the next two weeks at the ITU-T SG15 meeting, so my ability to process this work will be reduced: I also have to continue to do normal AD work-load, and the output of IETF working groups takes precedence over AD sponsored documents. Thanks, Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub helvoort Sent: 01 December 2011 21:17 To: Adrian Farrel Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; The IESG; Ietf@ietf.org Subject: Request to publish draft-betts-itu-oam-ach-code-point-01.txt Document Writeup for draft-betts-itu-oam-ach-code-point-01.txt As required by RFC-to-be draft-iesg-sponsoring-guidelines, this is the current template for the Document Shepherd Write-Up for individual submissions via the IESG. Changes are expected over time. This version is dated February 5, 2007. -- (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Huub van Helvoort (huub.van.helvo...@huawei.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG to be published. (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document was first posted on 16th October; no discussion has taken place on any email lists. However, this draft is addressing a well know issue that was first brought to the attention of the IETF in a request from the director of the ITU-T in June 2010 requesting the assignment of an ACh code point that would be used to run Ethernet based OAM on MPLS-TP networks. The draft requests IANA to assign a code point from the registry of Pseudowire Associated Channel Types. It does not make any proposals to modify the MPLS data plane forwarding behaviour or of the any IETF defined protocols. Therefore, review by the MPLS WG is not required. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. The purpose of the document is clear and the scope is limited to the assignment of a code point for (restricted) use by the ITU-T. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The issue of supporting an alternative set of OAM mechanisms for MPLS-TP based on Ethernet OAM has been widely discussed without reaching any firm conclusion. Note that more than 350,000 nodes have now been deployed with Ethernet based OAM using a code point from the experimental range. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? This draft is requesting the assignment of an ACh code point that will be used to run Ethernet based OAM on MPLS-TP networks. This protocol has been defined in the ITU-T and should not be considered to be a MPLS protocol and therefore should not subject to the provisions of RFC 4929. This request is supported by a significant number of network operators. However, discussion on the IETF list during the last call of draft-sprecher-mpls-tp-oam-considerations indicates that other do not support the view that aa alternative
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 12/3/2011 12:32 AM, Murray S. Kucherawy wrote:
Does a signature by this on behalf of signer mean something different
from a regular DKIM signature? It appears the current text means the
answer to be yes.
Correct, inasmuch as there are some people in the community who think author
domain signatures might be more important or valuable than others. This memo
doesn't make such an assertion, but merely acknowledges that perception.
Understood. I meant the this as a writing question; the meaning wasn't clear to
me and I think it needs to be easily clear to the reader.
So I suggest for the Abstract:
This specification modifies Domain Keys
Identified Mail (DKIM) by allowing advertisement of third-party
signature authorizations that are to be interpreted as equivalent to a
signature by the administrative domain of a message's author. The supplement
initially has Experimental status.
(I think it's important for an Abstract to summarize the core semantic.)
Also, the original text said 'originator' and I think you don't mean that, since
that equates to the Sender: field and not the From: field, per RFC 5598.
I also suggest:
3. Discussion
...
o Signers, who send mail on behalf of Authors and apply [DKIM]
signatures using their own domains; and
-
o Signer, which applies a [DKIM] signature using its own domain,
but on behalf of the message's Author ADMD; and
{ Stylistically, I find that specification text is easier when things are
written in the singular. So I suggest author (ADMD), signer and verifier,
rather than their plural form. }
and
A Verifier participates in this protocol if it wishes to ensure that
a message bears one or more signatures from sources approved to sign
mail on behalf of the Author, and identify for special treatment mail
that meets (or does not meet) that criterion.
-
A Verifier participating in this protocol treats the signer's
authorization on behalf of the author's ADMD as meaning that the signer's
signature is equivalent to a signature by the author's ADMD.
That is, I'm pressing for having this semantic made clear more than once in the
document, even though it needs formal, normative assertion only once (of course).
On re-reading, I think this also warrants an enhanced statement in the
Introduction (roughly from the view that an Introduction expands on the Abstract.)
So:
Absent is a protocol by which an ADMD can announce that DKIM
signatures on its mail added by other ADMDs should also be considered
trustworthy by verifiers. This memo presents an experimental
mechanism for doing so.
-
Absent is a protocol by which an Author ADMD can announce that specific
DKIM signatures on its mail, which are added by other ADMDs, are to
treated the same as a signature by the Author ADMD itself. This memo
presents an experimental mechanism for doing so.
{BTW, the document should be sanitized of normative vocabulary that is not meant
to be normative. That is, replace should, must and may with synonyms. }
It should say this explicitly. If it is not redefining the existing,
core DKIM semantic, it should say so. If it /is/ changing basic DKIM
semantics, then this is more than an extension to DKIM.
It is not.
Thinking a bit more about this, actually, I think it is.
With a normal DKIM signature, the d= string is taken as the output to the
higher-level module that then makes whatever reputation (or the like) assessment
that is to be performed.
With ATPS, the requirement is to replace the d= string with the domain name from
the From: field. That replacement value is then passed to the assessment module.
In other words, DKIM provides it's own identifier to be used for assessment,
whereas ATPS dictates use of the From: field domain name for assessment.
That's a fundamental change in semantics.
Section 1 of this draft reiterates that DKIM's core semantics don't extend
toany kind of binding of the delivered, validated domain name to any part of the
message. However, there are some people who believe that such a binding is valid
and useful. This draft is meant for those people, without altering DKIM's base
semantics.
ack.
I suggest that the incremental semantic should merely be that the
signature by an authorized signer should be interpreted as if the
signature had been by the authorizing domain.
It's a simple semantic and is, frankly, what I think is intended, based
on the discussions surrounding this mechanism that I've heard.
This is stated in Sections 5 and 6.
Indeed, they do.
And while we're in Section 5 (DKIM): the SHOULD needs to be a MUST.
With respect to DKIM itself, this new mechanism has one simple semantic: Use
the domain name in the From: field as the output. That's not optional and
that's not modifiable. If the verifier is playing in the ATPS sandbox, that's
the single immutable requirement.
With respect to
Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
- Original Message - From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com To: stbry...@cisco.com; Adrian Farrel adr...@olddog.co.uk Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org; Ietf@ietf.org Sent: Saturday, December 03, 2011 5:06 PM Hi, I fully support Stewart! G.8113.1 proposes a OAM solution for MPLS-TP networks. It uses the MPLS EtherType (when transmitted inband and getting the same treatment as the data traffic). The document is built on G.8110.1 (MPLS-TP architecture) which refers to G.8110 (MPLS architecture), and G.8110.1 refers to G.8113.1 back... This makes it part of MPLS and MPLS-TP. Nurit and others, I would commend to you the e-mail that Russ posted here 30Nov2011 in which he says, to Malcolm Johnson, Director of the ITU Telecommunication Standardization Bureau, IETF consensus continues to be required to allocate the code point. My experience leads me to believe that careful clarity about the proposed content changes to G.8113.1, as well as specific clarity that G.8113.1 is not part of MPLS and MPLS-TP, will aid in achieving such a consensus. The current situation has engendered quite a bit of ambiguity in wording which, in my experience, will not produce IETF consensus. so claiming what is and is not part of MPLS-TP calls for some thought. My interpretation is that this is not part of MPLS-TP, but that the code point should be allocated in accordance with RFC4929 which, as I pointed out on the MPLS list, does not require a standards track RFC and requires review by what the IESG considers suitable, which could, or could not, include the MPLS list; but the starting point should be the prior art which Russ has provided us with. The deadline would appear to be 12Jan2012 which Malcolm and Huub would appear to have provided us with the wherewithall to meet. Tom Petch And it should be reviewed by the MPLS WG. Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Stewart Bryant Sent: Friday, December 02, 2011 1:55 PM To: Adrian Farrel Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org; Ietf@ietf.org Subject: Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt Adrian It is the opinion of the document shepherd that discussion of this document on the working group lists would be a distraction from the technical protocol work that the working groups need to do. I disagree with the document shepherd in his evaluation. The draft clearly sets out to enable the standardization of an additional OAM for MPLS, and as such the MPLS WG need to review the document and its references to determine the consequences of the technology being deployed. Furthermore, all MPLS documents that have so far requested ACH codepoints have I believe been standards track. Why is this not also a standards track document? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt
Tom hi, If this is Ethernet OAM delivered *transparently* over MPLS-TP networks, then there is *no* need for a code point, they can simply use PWs. If this is a solution aims to provide an alternative OAM solution for MPLS-TP networks, and it is based on G.8110.1 and G.8110, and uses the MPLS EtherType, then it is part of MPLS and MPLS-TP. I believe it is the second case, therefore it requires the MPLS review and a follow-up of the MPLS change process. Best regards, Nurit -Original Message- From: ext t.petch [mailto:daedu...@btconnect.com] Sent: Saturday, December 03, 2011 7:44 PM To: Sprecher, Nurit (NSN - IL/Hod HaSharon); stbry...@cisco.com; Adrian Farrel Cc: iesg; ietf Subject: Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt - Original Message - From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com To: stbry...@cisco.com; Adrian Farrel adr...@olddog.co.uk Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org; Ietf@ietf.org Sent: Saturday, December 03, 2011 5:06 PM Hi, I fully support Stewart! G.8113.1 proposes a OAM solution for MPLS-TP networks. It uses the MPLS EtherType (when transmitted inband and getting the same treatment as the data traffic). The document is built on G.8110.1 (MPLS-TP architecture) which refers to G.8110 (MPLS architecture), and G.8110.1 refers to G.8113.1 back... This makes it part of MPLS and MPLS-TP. Nurit and others, I would commend to you the e-mail that Russ posted here 30Nov2011 in which he says, to Malcolm Johnson, Director of the ITU Telecommunication Standardization Bureau, IETF consensus continues to be required to allocate the code point. My experience leads me to believe that careful clarity about the proposed content changes to G.8113.1, as well as specific clarity that G.8113.1 is not part of MPLS and MPLS-TP, will aid in achieving such a consensus. The current situation has engendered quite a bit of ambiguity in wording which, in my experience, will not produce IETF consensus. so claiming what is and is not part of MPLS-TP calls for some thought. My interpretation is that this is not part of MPLS-TP, but that the code point should be allocated in accordance with RFC4929 which, as I pointed out on the MPLS list, does not require a standards track RFC and requires review by what the IESG considers suitable, which could, or could not, include the MPLS list; but the starting point should be the prior art which Russ has provided us with. The deadline would appear to be 12Jan2012 which Malcolm and Huub would appear to have provided us with the wherewithall to meet. Tom Petch And it should be reviewed by the MPLS WG. Best regards, Nurit -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Stewart Bryant Sent: Friday, December 02, 2011 1:55 PM To: Adrian Farrel Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org; Ietf@ietf.org Subject: Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt Adrian It is the opinion of the document shepherd that discussion of this document on the working group lists would be a distraction from the technical protocol work that the working groups need to do. I disagree with the document shepherd in his evaluation. The draft clearly sets out to enable the standardization of an additional OAM for MPLS, and as such the MPLS WG need to review the document and its references to determine the consequences of the technology being deployed. Furthermore, all MPLS documents that have so far requested ACH codepoints have I believe been standards track. Why is this not also a standards track document? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Consensus Call (Update): draft-weil-shared-transition-space-request
Folks, On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because: - it is difficult. (We are choosing between the lesser of two evils.) - a lively discussion on this mailing list has not yet converged Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? - Can alternative /10s be used? By contrast, further discussion of the following topics would not help the IESG gauge consensus: - Does the assignment of the requested /10 enable or hinder the deployment of IPv6? - Is CGN a viable service model for IPv4? - Can the deployment of CGN be prevented by not assigning Shared CGN address space? - How many ISPs really want this assignment and how many don't care because they don't need it? Further discussion of these questions is not helpful to us because we are deliberating over an address allocation, not the deployment of CGN/NAT444. Operators have already announced their intention to deploy. At least for the purposes of the current deliberation, we must assume that CGN/NAT444 will be deployed and concentrate on whether to allocate a /10 to facilitate its deployment. Ron Speaking as AD, But not on behalf of the IESG -- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Ralph: Is there evidence that there are deployments today of devices that use addresses in 10.64.0.0/10? I have seen addresses in this space used. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/2/2011 8:50 PM, Ross Callon wrote: If a customer uses a CGN-specific allocation on the inside of their network as if it were RFC 1918 space, then, yes, they will have trouble if they ever use a provider that uses a CGN. Thanks. So my point is, this proposed allocation doesn't solve anything, it just kicks the can down the road a while. That's not enough benefit to justify the cost. This particular argument has been bothering me for a while. We write standards. Our RFCs that specify protocols or best current practices contain statements along the lines of MUST or MUST NOT (and yes other documents also may use this terminology). People who implement or who deploy products could at least in principle ignore some of these statements, and implement or deploy equipment in ways that violate the MUST and MUST NOT statements in our documents. When they do this, bad things may happen. This is not a valid reason for us to stop writing standards, nor to stop putting MUST statements in our standards. To a certain extent of course you're right. But that's not the question before us. This is a resource allocation question. More particularly, it's a scarce resource, and making that allocation will have costs. So it's incumbent on us to do a cost::benefit analysis to determine whether the benefits of doing the allocation justify the costs. (I'm not trying to talk down to anyone here, I'm just repeating what I think we all know in order to take the conversation out of the abstract world that you're describing and put it back into the concrete world of this particular question.) So in regards to this particular resource allocation in order to determine what should be on the benefit side of the ledger we ask ourselves the question, Will this allocation solve the problem that it attempts to solve? (Note, I'm purposely ignoring the preliminary questions, such as, Is this a problem we _want_ to solve?) The answer, for better or worse, is No. Doing the allocation will postpone the pain, until such time as those folks that we keep hearing have exhausted all of 1918 internally catch on, and then start using this block as 1918 space. So because the benefits of doing the allocation are spotty at best, and the cost is high, we shouldn't do it. Q.E.D. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
From: Doug Barton do...@dougbarton.us Doing the allocation will postpone the pain, until such time as those folks that we keep hearing have exhausted all of 1918 internally catch on, and then start using this block as 1918 space. But if any particular site uses this space for either i) 1918-type uses, or ii) the intended use, do we care? As long as having some sites use it for 1918 purposes doesn't harm the ability of _other_ sites to use it for the purposes for which it is intended, I don't see the harm (although maybe I'm missing something). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Victor Kuarsingh wrote: However, 224/4 (or most of it) and 240/4 (except for 255.255.255.255) should be released for unicast uses to reduce market price on IPv4 addresses. I have not objection to this. But anything that requires replacement of equipment only will have longer term benefit. (Built it, Ship it, Stock it, Sell it, put it in). Remember that the current IPv6 is not operational, because of implosions of ICMPv6 packet too big generated against multicast packets, which means it takes time to fix ICMPv6 operational before Built it, Ship it, Stock it, Sell it, put it in I would also hope that when we have an opportunity to change out a box, it's with a IPv6 capable one (although it does not help that many boxes on the retail shelf are still IPv4-only - where we are). Thus, it is easier to expand IPv4 address space using port numbers as specified in RFC3102: RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. or something like that, which is recently called port restricted IP. I wish to spend most of our time on IPv6 deployment (and only do what is necessary for IPv4 to keep the lights on). Activity working on getting equipment to utilize 240/4 seems like a lot of effort. The problem is that IPv6 is broken, which means its deployment is meaningless until it is fixed. The multicast PMTUD example above is just an example and there are other problems in IPv6 specification. but I am not sure if the IETF is the right place to attempt and control market forces and the IPv4 Futures Market. Instead, from my experience to fix the so obvious multicast PMTUD problem within IETF, I'm sure IETF is not the right place to attempt to fix IPv6, which means IPv6 is hopeless. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/3/2011 4:49 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us Doing the allocation will postpone the pain, until such time as those folks that we keep hearing have exhausted all of 1918 internally catch on, and then start using this block as 1918 space. But if any particular site uses this space for either i) 1918-type uses, or ii) the intended use, do we care? As long as having some sites use it for 1918 purposes doesn't harm the ability of _other_ sites to use it for the purposes for which it is intended, I don't see the harm (although maybe I'm missing something). Yes, you're missing something. :) The argument from the proponents goes something like this (refined way down, ignoring subtleties, etc.): We cannot use 1918 for CGN because some customers use it internally, and they have CPEs that break if the same block is used on both sides. Therefore, we need a new, !1918 block for our side of the CGN. The problem with that argument is that there is nothing to stop customers from using the new block internally (and everyone involved so far has recognized that they inevitably will do this). Therefore the stated purpose of allocating the block is not going to be effective. Or, put another way, because the pain of dealing with customers who are using your CGN block internally is going to exist anyway, why not just use the least popular 1918 block(s) for this purpose and deal with the conflicts when they arise? Doug (but you're in good company) -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
From: Doug Barton do...@dougbarton.us there is nothing to stop customers from using the new block internally ... because the pain of dealing with customers who are using your CGN block internally is going to exist anyway, why not just use the least popular 1918 block(s) for this purpose and deal with the conflicts when they arise? That's definitely something to think about. One point the other way is that in using 1918 space in their sites, customers are doing _nothing wrong_ - in fact, they are doing just what the spec says they should do. On the other hand, a customer using CGN space in their site _would_ be doing something that's counter to a spec. I'm not sure how much good that will be for an ISP dealing with an upset customer, but it might be of some value. Can ISP people chime in on this? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/3/2011 5:26 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us there is nothing to stop customers from using the new block internally ... because the pain of dealing with customers who are using your CGN block internally is going to exist anyway, why not just use the least popular 1918 block(s) for this purpose and deal with the conflicts when they arise? That's definitely something to think about. One point the other way is that in using 1918 space in their sites, customers are doing _nothing wrong_ - in fact, they are doing just what the spec says they should do. On the other hand, a customer using CGN space in their site _would_ be doing something that's counter to a spec. I'm not sure how much good that will be for an ISP dealing with an upset customer, but it might be of some value. This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Henning On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/3/2011 5:54 PM, Henning Schulzrinne wrote: Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I think you're right about that, however it's also true that almost all of those devices use 192.168.[01]/24. So for that market you can easily avoid the problem on the CGN side by using a different 1918 block. I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. Apples and cumquats. Hijacking space that is allocated on the public Internet is an entirely different situation than Using space that's not supposed to be public for a different purpose than it was intended for. Yes, I realize that both are technically wrong in the sense that they are against the rules, but I can easily predict the arguments of the sysadmin responsible for the latter ... We never thought we'd be behind a CGN, so we figured it was Ok to do it. Our old provider didn't use that range for CGN, so we thought it would be Ok if we did. Etc. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Actually I think your analysis is 100% accurate, it's just your conclusions that are faulty. :) This is a 90/10 problem. 90% of the problem can be addressed by simply using a 1918 block that is not one of 192.168.[01]/24. (Where 90% is a WAG of course, but you get the idea.) However, the enterprises that are the most likely to have exhausted, or nearly exhausted 1918 space already are, for that exact reason, the same ones who are most likely to (mis-)appropriate the new space for their own 1918'ish needs. So the vast majority of the problem can be solved easily with 1918 space. The rest of the problem is incredibly likely to cause pain no matter what block is chosen for CGN space. So, there's no point to doing the allocation. Doug -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
The same thought occurred to me. A very large enterprise will not utilize this /10 on a whim; they'd talk to their ISP first. A consumer is unlikely to modify the settings of their home router, except if they download malware that does it for them :) and a consumer router vendor has such a low margin that the last thing they want is to utilize this forbidden /10, generating thousands of tech support calls they can't afford to answer. On Dec 3, 2011, at 20:54, Henning Schulzrinne h...@cs.columbia.edu wrote: Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Henning On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Dec 3, 2011, at 5:18 PM, Doug Barton wrote: We cannot use 1918 for CGN because some customers use it internally, and they have CPEs that break if the same block is used on both sides. Therefore, we need a new, !1918 block for our side of the CGN. The problem with that argument is that there is nothing to stop customers from using the new block internally (and everyone involved so far has recognized that they inevitably will do this). Hmm. So you're saying a customer behind a CGN is going to reconfigure their CPE to use this new !1918 block in contravention to explicit statements in the specification and then complain to their ISP when said reconfiguration conflicts with the use of the CGN the customer is now behind? This seems like a bit of a stretch to me. My guess is that the number of folks who would even be aware of the new !1918 space would be quite small and of those, the ones who would need to reconfigure to use that space would be infinitesimal so this argument against the new !1918 space seems a bit specious. Another possible reason 1918 space can't be used: the large scale ISPs interested in deploying CGN have already used up all of the 1918 space, thus to deploy CGN with minimal disruption to their deployed infrastructure, they need another block. Anything else would require non-trivial renumbering at undoubtedly high cost. In any event, I'm still trying to figure out the problems that would be created if the new !1918 block were not allocated. It seems to me that ISPs deploying CGN who are unable to use existing 1918 space would be faced with the following options: a) use normal space b) use somebody else's space c) redeploy stuff Option (a) simply means accelerating IPv4 free pool exhaustion. To me, this implies moving the date when ISPs have to pay significantly increased costs (going rate is now about US$12/address so a /10 would mean US$50M) to obtain IPv4 addresses forward a year or two. Interestingly, getting normal space now would probably pay off in the longer term as that space will likely be quite in demand after free pool exhaustion. Option (b) used to be SOP with a number of larger ISPs, although I gather at least some of them have learned the risks of doing this the hard way. From a pure business perspective, while unappealing, if the choice is between paying $50M or not, I suspect finding a sparsely used /10 wouldn't be that hard (I imagine everyone here has their favorite blocks they wouldn't mind seeing sacrificed), but it does obviously come with risks. Option (c) is simply inevitable one way or another, but pushing it forward is probably viewed as extremely difficult/expensive in the near term, hence the preference for either new !1918 space or going with options (a) or (b). My impression is that the folks proposing draft-weil are trying to be good net citizens and not use space inefficiently. Failure to pass draft-weil will simply mean they'll go with option (a) or (b) -- I'd guess the moment draft-weil is shot down, the RIRs will start getting very large and perfectly justified address requests and the day of complete IPv4 free pool exhaustion will jump forward. What am I missing? Thanks, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
I think this is indeed all about economics. Role acting ISP for a minute: From a consumer ISP perspective asked to weigh in here, there are two options beyond the ones mentioned below: (1) They can support the new /10, which doesn't cost them anything and reduces the chance that existing NAT boxes cause problems to near-zero. (2) They can try to find some dusty corner of the existing RFC 1918 space, but won't really be able to predict what happens until the phone lines light up. When they do, they have to tell grandma to log into their NAT box and type in a new address range. From an ISP perspective, why would they ever choose (2)? I don't see how we can eliminate the risk of (2) to essentially zero or even estimate it accurately. (The typical DNS root leakage experiments, such as the WIDE report, may miss exactly those devices that are in that dusty corner; it seems to measure broken devices, rather than compliant devices.) We don't necessarily have to care about the support costs for ISPs, but the question is whether the total societal value of having this /10 be used for regular users exceeds the support cost (and the associated consumer aggregation), which is pure deadweight loss. I don't know if there's a good way to estimate this. Henning On Dec 3, 2011, at 9:41 PM, David Conrad wrote: On Dec 3, 2011, at 5:18 PM, Doug Barton wrote: We cannot use 1918 for CGN because some customers use it internally, and they have CPEs that break if the same block is used on both sides. Therefore, we need a new, !1918 block for our side of the CGN. The problem with that argument is that there is nothing to stop customers from using the new block internally (and everyone involved so far has recognized that they inevitably will do this). Hmm. So you're saying a customer behind a CGN is going to reconfigure their CPE to use this new !1918 block in contravention to explicit statements in the specification and then complain to their ISP when said reconfiguration conflicts with the use of the CGN the customer is now behind? This seems like a bit of a stretch to me. My guess is that the number of folks who would even be aware of the new !1918 space would be quite small and of those, the ones who would need to reconfigure to use that space would be infinitesimal so this argument against the new !1918 space seems a bit specious. Another possible reason 1918 space can't be used: the large scale ISPs interested in deploying CGN have already used up all of the 1918 space, thus to deploy CGN with minimal disruption to their deployed infrastructure, they need another block. Anything else would require non-trivial renumbering at undoubtedly high cost. In any event, I'm still trying to figure out the problems that would be created if the new !1918 block were not allocated. It seems to me that ISPs deploying CGN who are unable to use existing 1918 space would be faced with the following options: a) use normal space b) use somebody else's space c) redeploy stuff Option (a) simply means accelerating IPv4 free pool exhaustion. To me, this implies moving the date when ISPs have to pay significantly increased costs (going rate is now about US$12/address so a /10 would mean US$50M) to obtain IPv4 addresses forward a year or two. Interestingly, getting normal space now would probably pay off in the longer term as that space will likely be quite in demand after free pool exhaustion. Option (b) used to be SOP with a number of larger ISPs, although I gather at least some of them have learned the risks of doing this the hard way. From a pure business perspective, while unappealing, if the choice is between paying $50M or not, I suspect finding a sparsely used /10 wouldn't be that hard (I imagine everyone here has their favorite blocks they wouldn't mind seeing sacrificed), but it does obviously come with risks. Option (c) is simply inevitable one way or another, but pushing it forward is probably viewed as extremely difficult/expensive in the near term, hence the preference for either new !1918 space or going with options (a) or (b). My impression is that the folks proposing draft-weil are trying to be good net citizens and not use space inefficiently. Failure to pass draft-weil will simply mean they'll go with option (a) or (b) -- I'd guess the moment draft-weil is shot down, the RIRs will start getting very large and perfectly justified address requests and the day of complete IPv4 free pool exhaustion will jump forward. What am I missing? Thanks, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Noel, Opinion from an operator. There is a difference, and the reality is that the space is unlikely to be used by enterprises and consumers. Here is the difference. RFC1918 has been out (defined) for a long time, so it's well know by operators, enterprise folks and some consumers. There is a possibility that some smart netadmins may try and use the space, but nothing stops them form squatting on non-RFC1918 today anyway (and dealing with any conflicts that arise). There is a big difference if a consumer and an ISP has a conflict because both are [validly] using the same RFC1918 space vs. if a Consumer and an ISP conflict using special assigned space. Regards, Victor K On 11-12-03 8:36 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
I've followed the discussion, both on the OPSAWG list and on the IETF list, and I have to say that I agree with the comments below by Henning Schulzrinne and Bernard Aboba. One question, though, that I wish to address to the authors of draft-weil-shared-transition-space-request and perhaps others: why would not an allocation from 240/4 (the former Class E address space) work for CGN space? I'm well aware that it would be very difficult to use this as ordinary IPv4 address space because of the long history of treating it as a Martian address range. It seems to me, however, that this would NOT be an issue for CGN boxes -- those being new equipment, the software can be upgraded to treat this address range differently than it traditionally has been. It would be more difficult for CPE equipment to use -- especially stuff that's already deployed -- but that's actually an ADVANTAGE since such devices are not supposed to use CGN space. And an allocation from 240/4 would not use up scarce global IPv4 space, which is one of the main objections I've been hearing to this allocation. So ... to the authors of draft-weil-shared-transition-space-request and other advocates of this allocation : please tell us whether an allocation from 240/4 would work for CGN space, and if not, why not. To the IESG: please require the authors and/or other advocates of the propsed allocation to answer the above question before approving the allocation request. If they agree that it will do, approve an allocation from that space. If they provide a cogent argument as to why 240/4 won't work, then I advise (reluctantly) approving the allocation from the remaining IPv4 global space. Thanks for listening. //cmh On Sat, 3 Dec 2011, Bernard Aboba wrote: The same thought occurred to me. A very large enterprise will not utilize this /10 on a whim; they'd talk to their ISP first. A consumer is unlikely to modify the settings of their home router, except if they download malware that does it for them :) and a consumer router vendor has such a low margin that the last thing they want is to utilize this forbidden /10, generating thousands of tech support calls they can't afford to answer. On Dec 3, 2011, at 20:54, Henning Schulzrinne h...@cs.columbia.edu wrote: Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Henning On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
CM One question, though, that I wish to address to the authors of draft-weil-shared-transition-space-request and perhaps others: why would not an allocation from 240/4 (the former Class E address space) work for CGN space? I'm well aware that it would be very difficult to use this as ordinary IPv4 address space because of the long history of treating it as a Martian address range. It seems to me, however, that this would NOT be an issue for CGN boxes -- those being new equipment, the software can be upgraded to treat this address range differently than it traditionally has been. It would be more difficult for CPE equipment to use -- especially stuff that's already deployed -- but that's actually an ADVANTAGE since such devices are not supposed to use CGN space. And an allocation from 240/4 would not use up scarce global IPv4 space, which is one of the main objections I've been hearing to this allocation. It may be possible to use 240/4 on the CGN box (code upgrade), but the CPEs would have a problem. These CPEs are a key part of the problem. The space would need to work with what's in the field. The CGN space would be assigned the the CGN zone which may be configured on the internal interface of the CGN box, but would absolutely be configured on the CPE WAN interface. Numbering tens of CGN boxes is not the issue, numbering thousands to millions of CPEs is. 240/4 would require firmware upgrades to many (if not all) CPEs, of which many are not under the control of the operator (home user bought and controlled). It is not feasible to upgrade the entire CPE base. This is one of the key issues with 240/4. Regards, Victor K So ... to the authors of draft-weil-shared-transition-space-request and other advocates of this allocation : please tell us whether an allocation from 240/4 would work for CGN space, and if not, why not. To the IESG: please require the authors and/or other advocates of the propsed allocation to answer the above question before approving the allocation request. If they agree that it will do, approve an allocation from that space. If they provide a cogent argument as to why 240/4 won't work, then I advise (reluctantly) approving the allocation from the remaining IPv4 global space. Thanks for listening. //cmh On Sat, 3 Dec 2011, Bernard Aboba wrote: The same thought occurred to me. A very large enterprise will not utilize this /10 on a whim; they'd talk to their ISP first. A consumer is unlikely to modify the settings of their home router, except if they download malware that does it for them :) and a consumer router vendor has such a low margin that the last thing they want is to utilize this forbidden /10, generating thousands of tech support calls they can't afford to answer. On Dec 3, 2011, at 20:54, Henning Schulzrinne h...@cs.columbia.edu wrote: Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Henning On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this point before deciding to ask for CGN space, and decided the space was still enough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Ron, Folks, On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat. The decision was deferred because: - it is difficult. (We are choosing between the lesser of two evils.) - a lively discussion on this mailing list has not yet converged Several topic have become intertwined in the mailing list discussion, making it difficult to gauge community consensus. Further discussion of the following topics would help the IESG to gauge consensus: - Is the reserved /10 required for the deployment of CGN? I would say for the sanity of the sum of all CGN deployments a common space would be most sound. It would allow operators to build common rules on managing this CGN zone space. These rules include how information is propagated to and from the local ISP (I.e. BGP, DNS Information etc) and how internal security policies are built. This is important since many ISPs will likely be using part (or all) of the RFC1918 space for other functions which include management zones, back-office systems and the like. Such an allocation would also help avoid any conflicts with RFC1918 space used by customer networks. Although there may be portions of the RFC1918 space that *may * be open in each network, the space is not likely going to be the same (different parts of the range if any) which makes it hard to build common rules and for vendors to accommodate this if required. Should operators need to use squat (should the space not be allocated), this would potentially resolve the address conflict issues, but would promote bad form as many may choose space which can potentially be used on the Internet in the future (making life bad for customers). It would also make building common rules/filers between ISPs difficult to impossible. - What is the effect of burning 4 million IPv4 addresses on the exhaustion of IPv4? This is a question better answered by the RIR themselves. I hear much speculation from those on the list, but I don't think anyone here can authoritatively answer this question. Also, the effect of the allocation should be commented on from a technical position and not presumed market impacts (if any) since this again is speculation. Economics of the IPv4 address markets should be left out of the technical discussion (in my opinion). If the IPv4 address pool is so important and we are so concerned about the price, then one should talk to the 38 (by my count) of private companies and defence organizations which have /8s and ask them for their space back (I will assume this is not feasible) - Can alternative /10s be used? As noted, some have suggested parts of the RFC1918 space, but operators have noted the challenges with this. 240/4 would require upgrades to some of the vary devices (CPEs) which are of concern to us. A part of the legacy assigned space would work. Not sure how feasible that is. I guess if not allocated (the /10), squatting will have the same effect (with all the chaos along with it). Regards, Victor K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
In message pine.lnx.4.64.1112032019010.23...@shell4.bayarea.net, C. M. Heard writes: I've followed the discussion, both on the OPSAWG list and on the IETF list, and I have to say that I agree with the comments below by Henning Schulzrinne and Bernard Aboba. One question, though, that I wish to address to the authors of draft-weil-shared-transition-space-request and perhaps others: why would not an allocation from 240/4 (the former Class E address space) work for CGN space? I'm well aware that it would be very difficult to use this as ordinary IPv4 address space because of the long history of treating it as a Martian address range. It seems to me, however, that this would NOT be an issue for CGN boxes -- those being new equipment, the software can be upgraded to treat this address range differently than it traditionally has been. It would be more difficult for CPE equipment to use -- especially stuff that's already deployed -- but that's actually an ADVANTAGE since such devices are not supposed to use CGN space. And an allocation from 240/4 would not use up scarce global IPv4 space, which is one of the main objections I've been hearing to this allocation. The CGN boxes are new. The customer boxes which are being allocated the addresses are old. Lots of these boxes will not work with a 240/4 address. So ... to the authors of draft-weil-shared-transition-space-request and other advocates of this allocation : please tell us whether an allocation from 240/4 would work for CGN space, and if not, why not. To the IESG: please require the authors and/or other advocates of the propsed allocation to answer the above question before approving the allocation request. If they agree that it will do, approve an allocation from that space. If they provide a cogent argument as to why 240/4 won't work, then I advise (reluctantly) approving the allocation from the remaining IPv4 global space. Thanks for listening. //cmh On Sat, 3 Dec 2011, Bernard Aboba wrote: The same thought occurred to me. A very large enterprise will not utilize this /10 on a whim; they'd talk to their ISP first. A consumer is unlikely to modify the settings of their home router, except if they download malware that does it for them :) and a consumer router vendor has such a low margin that the last thing they want is to utilize this forbidden /10, generating thousands of tech support calls they can't afford to answer. On Dec 3, 2011, at 20:54, Henning Schulzrinne h...@cs.columbia.edu wrote : Almost all residential customers will use a standard home router; as long as that home router does not make the new space available to customers, it will not be used. Almost all residential users get their home NAT box either from the ISP (who obviously won't ship such a box) or from one of a handful of retail consumer equipment vendors, who won't suddenly switch from RFC 1918 addresses, either (because they don't want to get the support calls). I don't think your consumer ISP will have much sympathy if you call them up and tell them that you decided to use 128.59.x.x internally, reconfigured the gateway and can no longer get to Columbia University. This is an economics issue: If one big corporate customer with a too-creative sysadmin calls up after finding this new address space, this can be dealt with. (Indeed, that large corporate customer probably has non-1918 outward-facing addresses to begin with and will keep them, so they are the least likely target of CGNs.) If 10,000 consumer customers call up because their Intertubes aren't working, the ISP has a problem. Thus, I'm having a hard time believing in the theory that the new space will be immediately appropriated for consumer ISPs. By whom, exactly, and on what scale and with what motivation? Henning On Dec 3, 2011, at 8:36 PM, Noel Chiappa wrote: From: Doug Barton do...@dougbarton.us This argument has been raised before, but IMO the value is exactly zero. The fact that you have a finger to wag at someone doesn't make the costs of dealing with the conflict any smaller. Perhaps. But I don't know the ISPs' business as well as they do. So I'd like to hear their views on this point. (They may well have considered this p oint before deciding to ask for CGN space, and decided the space was still en ough use to be worth it.) Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
