Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization

"Stan Ratliff (sratliff)" <sratliff@cisco.com> Sat, 09 August 2014 22:55 UTC

Return-Path: <sratliff@cisco.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4311A0368 for <manet@ietfa.amsl.com>; Sat, 9 Aug 2014 15:55:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.168
X-Spam-Level:
X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Ku0xms-OLGTY for <manet@ietfa.amsl.com>; Sat, 9 Aug 2014 15:55:53 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397041A0364 for <manet@ietf.org>; Sat, 9 Aug 2014 15:55:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6261; q=dns/txt; s=iport; t=1407624953; x=1408834553; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XvBGeUkP9eLJm4Kl/JflH+NDOrPEh254gLYpGnHVRXs=; b=RMMeZKuwpkSE01A5LrCmoGv6cyPLratrCyV9xcJuiYB4alq4fdXn7xHO 86TbIFC0ZmISwdohjdPY26pgJU04kWRnV13ovoKcw9JWzvQzX5SWZWSKX 6MEK4fOx3cREGlDdgPwO2oevNsq2geXaZqomHrKm79iaxxBIibnLiEJsk 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAKOm5lOtJA2F/2dsb2JhbABYgw2BKQTUXwGBCBZ3hAQBAQQdXBACAQg7BAchERQRAgQOBYguAxG/Gg2FYBeJf4Mggi0Hgy+BHQWRGYkNggmOSYYyghaBRmyBRw
X-IronPort-AV: E=Sophos;i="5.01,834,1400025600"; d="scan'208,217";a="346347349"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2014 22:55:27 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s79MtRTi018884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 22:55:27 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.251]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Sat, 9 Aug 2014 17:55:27 -0500
From: "Stan Ratliff (sratliff)" <sratliff@cisco.com>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Thread-Topic: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization
Thread-Index: AQHPsmetgFGqmSrFFkajPEnl2Q8ID5vF/jOAgAADfQCAAUr/gIAACK0AgAAwGYCAAPLTgIAAwL4A
Date: Sat, 09 Aug 2014 22:55:27 +0000
Message-ID: <DC967826-34DD-494C-8528-50B3E08B4A5A@cisco.com>
References: <20140807152647.19846.41050.idtracker@ietfa.amsl.com> <74C6EFB5-71D8-4B41-B1F5-2449EFE1C493@thomasclausen.org> <C6757792-DA6D-4141-AA11-803DCDE47AA6@cisco.com> <CADnDZ8_DE9YHFWGFJoz0h---maEdePcNihv-0OaVNcNQpu+cOQ@mail.gmail.com> <DD45D196-0020-4040-8276-5492A93B6C40@mnemosyne.demon.co.uk> <03ae01cfb32e$d9acc600$8d065200$@olddog.co.uk> <EA96BB97-E37C-4AE9-B925-3CE1EAA85B49@cisco.com> <8802CEE7-D6BD-4950-B02F-FB9D195B0066@gmail.com> <CADnDZ88Qp8buJOZTMqirOXr+xpPC95cQqtJ-X1bjQ-+JARuSLw@mail.gmail.com>
In-Reply-To: <CADnDZ88Qp8buJOZTMqirOXr+xpPC95cQqtJ-X1bjQ-+JARuSLw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.116.179.220]
Content-Type: multipart/alternative; boundary="_000_DC96782634DD494C852850B3E08B4A5Aciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qNEK4rXVTgehwp0euzWN4mgg1yU
Cc: Christopher Dearlove <christopher.dearlove@gmail.com>, manet IETF <manet@ietf.org>, manet-ads <manet-ads@tools.ietf.org>, Thomas Clausen <thomas@thomasclausen.org>, "<manet-chairs@tools.ietf.org>" <manet-chairs@tools.ietf.org>
Subject: Re: [manet] Working group last call for draft-ietf-manet-rfc6779bis and draft-ietf-manet-nhdp-optimization
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Aug 2014 22:55:55 -0000

Abdussalam,

On Aug 9, 2014, at 7:25 AM, Abdussalam Baryun <abdussalambaryun@gmail.com<mailto:abdussalambaryun@gmail.com>> wrote:



On Friday, August 8, 2014, Christopher Dearlove wrote:
Adrian

Thanks for the effort in unearthing this. I take the same view as Stan. I will note that I have implemented this, but don't have any publishable performance results. But as I said, I agree with Stan on the lack of necessity of this.

 The draft is updating two standards, and promoting better performance. I remember when the first present of the draft at IETF 89, I asked you of its difference, and the answer was no much code difference just performance.

 When we promote optimum that means best performance? So how can this WG get sure of that optimum behavior, do we just follow the author/implementor, is that IETF practice.  The results can be necessary to prove it's a suitable standard update. If you want it to be not necessary to give results then no need to update our standards, just a new standard extension.

There is a long history in the IETF of promoting standards and extensions using a thorough logical analysis of the protocols. Note that this does *not* imply an analysis of *a given implementation* of a protocol, via simulation or otherwise. The analysis of a given protocol, or extension, is undertaken by the authors, and by Working Group participants with sufficient interest (and time) to undertake the analysis. This is a critical part of the consensus mode of operation within the IETF, and has never required formal proofs, or simulation runs/output, etc. The stated goal of the IETF has always been "rough consensus and working code".

So at this point, we *still* have the authors, and others in the WG, in consensus that the document represents *exactly* what it says it represents - an optimization for NHDP. If you have analysis to the contrary, WGLC is *exactly* the time to bring that analysis up, and share with the WG situations where you believe implementing this change will have an adverse effect - either on performance, or on protocol integrity. Otherwise, with my co-chair hat firmly on, it still looks like we have rough consensus, with you being "in the rough".

Regards,
Stan



AB