Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
Pete Resnick <presnick@qti.qualcomm.com> Thu, 23 January 2014 16:56 UTC
Return-Path: <presnick@qti.qualcomm.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044D01A0041; Thu, 23 Jan 2014 08:56:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.836
X-Spam-Level:
X-Spam-Status: No, score=-4.836 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_QmA6YUPXwi; Thu, 23 Jan 2014 08:56:31 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 931FF1A0028; Thu, 23 Jan 2014 08:56:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1390496192; x=1422032192; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=J2++WgbBM/dRSUYMb4hQ5Bk6iTCx6l2p8wErL7ttJgY=; b=qjo/Hm9KbLQOJyvDQgWpTzMNLbOkdpXn0aIO3+QA4x/1Zg6Pyn/uiCaE 05rLqS8XWOG/zgeeHcISaZekqVTbmniEdVwtktnfs2ylyi/DQuM1AMRLn gnw0b7TAEEQ31i82RZo3mkndO8xWL/FWtKj+lAJkrQ+ZqMdshc4kTxN9U U=;
X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="10020121"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 23 Jan 2014 08:56:31 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7326"; a="672379856"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Jan 2014 08:56:30 -0800
Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 23 Jan 2014 08:56:30 -0800
Message-ID: <52E149BC.3090007@qti.qualcomm.com>
Date: Thu, 23 Jan 2014 10:56:28 -0600
From: Pete Resnick <presnick@qti.qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Thomas Narten <narten@us.ibm.com>
Subject: Re: Pete Resnick's Abstain on draft-ietf-6man-stable-privacy-addresses-16: (with COMMENT)
References: <20140122192018.8692.82071.idtracker@ietfa.amsl.com> <m3ppnj8n85.wl%narten@us.ibm.com>
In-Reply-To: <m3ppnj8n85.wl%narten@us.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.30.39.5]
Cc: 6man-chairs@tools.ietf.org, ipv6@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 16:56:34 -0000
On 1/22/14 8:07 PM, Thomas Narten wrote: > Glad this is only a comment, but I think if one argues this document > shouldn't be PS, it opens up the door to saying a rather substantial > number of the standards the IETF has produced in the past should not > be on standards track either. > > I think its worth noting that the classifications we have > (standard/info/bcp/applicability statements) have a very course > granularity. There are lots of individual "things" that don't fit > cleanly into exactly one category, if you start looking closely. > We're now off into "the bigger picture", but I do think we've been pretty lousy about deciding once and for all what we mean by certain documents. Coarse-grained is fine, and I don't have a problem with us picking "the best fit" when a document isn't clearly one or the other. The problem is that we are now in a state of assigning states for marketing reasons ("people will take this more seriously if we make it a standard") rather than to improve how we do things on the Internet. I think it weakens the document series generally to be calling things standards that aren't and vice-versa. With documents that should be Informational that are called standards, people start turning into the protocol police ("The document says you MUST have a button to switch this feature off, and you don't expose that in the UI; you are required by the IETF to fix your UI") and people start viewing the things that *are* interoperability standards as conformance documents. It lowers the usefulness and relevance of our protocols. The problem is not where any given document goes. It's that we haven't been good about defining the categories clearly. > For example, the IETF doesn't really (usually) produce informational > documents that people go off and implement. If you are going to code > something, then presumably you want all implementations do things in a > certain way (so they exhibit important behavior). And you want to be > able to verify that implementations were able to implement from the > spec (perhaps using MUST/SHOULD type language - or perhaps not). We > get that with standards track documents. We have no mechanism in our > processes for reviewing Informational RFCs and whether they were > implementable and meet our criteria for being called a standard. Isn't > that one of the core reasons the IETF exists? > To a certain extent. It is true that one of the aspects of standardization is implementability. But we are supposed to judge implementability from a standpoint of interoperability. In fact, we are quite clear that it is *independent* implementation is key: We *don't* want people implementing things exactly the same way, because that makes for brittle implementations. What we want is for the network-visible output of those implementations to do certain things, but we want the implementations to be independent and we ignore their local (i.e., non-networked) behaviors. So while I agree that we usually don't produce informational document that people go off and implement, I would add that we usually don't (and generally shouldn't) produce standards track documents that prescribe specific local implementation details that do not affect interoperability. In those instances we think that a local implementation problem is important to explain ("Every implementation ends up needing to do X, and we've seen that they never seem to get it right, so here's a a way to do it"), even though we are not saying it is necessary for interoperability, I think an Informational document is appropriate if it's going to be a separate document. (Sometimes a BCP is also reasonable, if we find that we need to give policy or operational guidance to deployment.) > Thus, for IETF WGs, I would say that the vast majority of stuff that > is produced that describes an implementation should be on standards > track. > I agree with the general statement. The issue is that there are a bunch of things about local implementation details that I don't think we should be making normative statements about at all. When we do want to make statements about local implementation details, I don't think those statements should be on the standards track. > This document fits squarely in that category. > > >> This is an algorithm to generate stable, private, and mostly unique >> addresses. It does not affect interoperability at all if people choose >> a different method. >> > Sure it may. How will it? > If we want the IETF "standard" to be "generate addresses > however you want, hopefully they will work, but it's not the business > of an IETF standard to tell you how to ensure you are doing things > right", then I guess publishing this document as informational (and > giving it the same status as an RFC such as "FooBar's Proprietary > Protocol") would be the way to go. > I am curious about the "doing things right" bit. If doing things right is simply "it must be stable, private, and unique", and we're giving an example about how to get such a thing, peachy. But this document does more than that. It says, for example, that the DAD_Counter MUST start at zero and go up. But of course my implementation doesn't need to do that. I could plausibly start high and work my way down (if I were being recalcitrant). I could also come up with something nifty other than the Prefix to put into my generator. And if either of these things works better in my implementation (because it's more efficient, or I'm in a weird local environment that makes doing it the way the document describes hard) and I'm still able to produce stable, private, and unique addresses, that's fine and the IETF can take their standard and piss-off. > But be careful what you wish for. I'm pretty sure the IPv6 addressing > architecture shouldn't be on standards track per your argument. And > maybe the original SLAAC spec shouldn't be either. Beware the slippery > slope. > Well, if this document was saying, "You MUST have addresses that are private because doing otherwise exposes information and potentially harms things" and therefore updated the old way of doing address selection, I would be more inclined to say that this is a reasonable as a standard because it's saying that this is the one way we've all agreed to accomplish this and other ways are bad. But from what I understand, the WG is not inclined to do that. >> Anyone can accomplish the same task in a number of >> different ways. This is just a nice method to use if someone wanted to >> use it. This should just be an Informational document explaining a >> nice way to generate stable, private, mostly unique addresses without >> all of the MUSTs and SHOULDs, which are not interoperability >> requirements in the first place. Standardizing this is silly in the >> extreme. >> > Others have commented on this, but it is perfectly fine (and has been > in the IETF for a long time) to use MUST/MAY type language in > informational documents. Especially ones that describe protocol > details. Why bring up this Red Herring? > It's not the existence of the MUSTs and SHOULDs, it's what they are requiring in this document. They are not requiring things that are required for interoperation or to prevent harm. pr -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478
- Pete Resnick's Abstain on draft-ietf-6man-stable-… Pete Resnick
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Fernando Gont
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Pete Resnick
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Thomas Narten
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Fernando Gont
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Brian Haberman
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Bob Hinden
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Pete Resnick
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Bob Hinden
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Pete Resnick
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Bob Hinden
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Fernando Gont
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Alissa Cooper
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Scott Brim
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Pete Resnick
- Re: Pete Resnick's Abstain on draft-ietf-6man-sta… Brian E Carpenter