[edu-discuss] FW: RE: solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt -

"Hosnieh Rafiee" <ietf@rozanak.com> Tue, 07 May 2013 08:42 UTC

Return-Path: <ietf@rozanak.com>
X-Original-To: edu-discuss@ietfa.amsl.com
Delivered-To: edu-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AE021F8FB2; Tue, 7 May 2013 01:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level:
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8ldN-4fPW69; Tue, 7 May 2013 01:42:07 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5750C21F8F83; Tue, 7 May 2013 01:42:07 -0700 (PDT)
Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LvVEJ-1URYcM177T-00zqDX; Tue, 07 May 2013 04:42:03 -0400
From: Hosnieh Rafiee <ietf@rozanak.com>
To: edu-discuss@ietf.org
References: <C91E67751B1EFF41B857DE2FE1F68ABA0FF1E6E1@tk5ex14mbxc272.redmond.corp.microsoft.com> <OF9B334605.3F5D177D-ON48257B64.001C0657-48257B64.001C421C@zte.com.cn> <6.2.5.6.2.20130506231929.0b647f30@resistor.net> <001401ce4af7$962f8fc0$c28eaf40$@rozanak.com> <6.2.5.6.2.20130507010020.0c0667a0@resistor.net>
In-Reply-To:
Date: Tue, 07 May 2013 10:41:57 +0200
Message-ID: <000701ce4afe$be9111d0$3bb33570$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH6QFB/qNl13OpkUL0HYUqLOI9edQFk0iKxARC6ZdcB2mM9xQJNr+zymGyKHxCAAAWbYA==
Content-Language: en-us
X-Provags-ID: V02:K0:2ojiJY3FZ9J3ULbzUUC7LuDQgUKyGmKhA2+MRIgXWC5 E58XZhYu4kFxvElJvJlG55gbryRUe/f7MBXutvqw6nVgIiy7iP WpgmorHWfYhBMe1TkzSH6qW65yYsZtMRbMw0uzc7jNWvZjJuq7 yCYTd1LnvNMSp1h2auIeSLG5QJvzYYVjQYOUns9w4XYWfsmXhH yVizXyy2UhFP/Ir1ctwNJfm3bx+F5hVgOnmaHXk/3qIB22fPZP x54y1lO6A++ZNWIGR+n6+8sh78ZpFeMp29As3zHv6cvF+xGRoI 8U9mITxdPyWEN/0HO5Jn/QVpnJ0M2C9+SsnZf7/nSKcQvr8IKY of3cv4E/1n1tLCt3ejtI=
Cc: ipv6@ietf.org
Subject: [edu-discuss] FW: RE: solution to RFC 4941 I-D action : draft-rafiee-6man-ra-privacy.txt -
X-BeenThere: edu-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF Education Discussion <edu-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/edu-discuss>, <mailto:edu-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/edu-discuss>
List-Post: <mailto:edu-discuss@ietf.org>
List-Help: <mailto:edu-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/edu-discuss>, <mailto:edu-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2013 08:42:15 -0000

Hi,

> >In my opinion, it is better to update the current RFCs or obsolete 
> >them instead of adding more specifications which will result on 
> >confusing vendors. Of course, it is my point of view and some people 
> >are disagree with that. They would like to have several optional 
> >standards and let the implementers to choose.
> 
> Proposed Standards were supposed to be "optional".  Implementers 
> choosing to implement them was a good test for running code (code 
> which is actually used on the Internet).  The specifications can then 
> be published as Standard.  If you don't have time to track all the 
> Proposed Standard you could implement the Standard and achieve at 
> least minimum interoperability.  It does not work in practice.  There 
> isn't any Standard for IPv6.  The Standard for SMTP (email) is old and it
is not worth basing an implementation on that.
> 
> I am curious about what you find difficult about IETF specifications.  
> Note that I am not going to disagree with your opinion or argue that 
> what you said is wrong. :-)
> 

As you stated here, there are some old RFCs that, in my opinion, we do not
know whether or not they still address today's minimum requirements. There
are also some vendors that still using them because they did not see any
update on them. This means we are adding more and more standards while we do
a few efforts to check the old standards and obsolete them or update them. I
do not have any problem with having several options. But I do think that
addressing the current RFCs has more priority on adding new specifications.
In other word, to say whether or not the current RFCs can still address our
needs or they need a few modifications to address our needs, has higher
priority than trying to come up with something that might have the same
impact as we resolve the problem with the current RFCs.  

I heard from some people that their problem of not addressing the old RFC is
backward compatibilities. In my opinion, It is the choice of vendors to
improve their old implementations or just leave it as it is. But by
addressing those RFCs at least the customers know that they did not choose
the best option. This means that the customers will force vendors to improve
their current implementations. Then instead of having thousands of RFCs we
will have some that we can rely on and we are sure that they are not
something not useful. When something does not have our today's requirement
why we need to think about that?! 

Regards,
Hosnieh