Re: [manet] Question regarding RFC 8175
Rick Taylor <rick@tropicalstormsoftware.com> Tue, 07 November 2017 21:12 UTC
Return-Path: <rick@tropicalstormsoftware.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7A312773A for <manet@ietfa.amsl.com>; Tue, 7 Nov 2017 13:12:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dj9Bl28vJS6r for <manet@ietfa.amsl.com>; Tue, 7 Nov 2017 13:12:36 -0800 (PST)
Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC39126E7A for <manet@ietf.org>; Tue, 7 Nov 2017 13:12:35 -0800 (PST)
Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Tue, 7 Nov 2017 21:12:12 +0000
From: Rick Taylor <rick@tropicalstormsoftware.com>
To: Stan Ratliff <ratliffstan@gmail.com>, "Tran, Anthony" <Anthony.Tran@gd-ms.ca>
CC: "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] Question regarding RFC 8175
Thread-Index: AdNYDRG57Vo04oqXRLKE/JAfTxTw6Q==
Date: Tue, 07 Nov 2017 21:12:07 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D32295DB@tss-server1.home.tropicalstormsoftware.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F9801D32295DBtssserver1hom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/3_1DLPgLQaksZ_hcnSju-wvDSkY>
Subject: Re: [manet] Question regarding RFC 8175
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 07 Nov 2017 21:12:38 -0000
Anthony, Just to be a pedant: it’s just RFC8175, the version numbers were only for the drafts. I’m only being picky because someone asked me what version of DLEP I supported the other day, and there are intentionally no version numbers in the protocol. Cheers, Rick From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff Sent: 07 November 2017 19:21 To: Tran, Anthony Cc: manet@ietf.org Subject: Re: [manet] Question regarding RFC 8175 version 29 Anthony, The two bulleted points you included from 13.8.1 cover some of the "inconsistent data" that concerned us: " ...Examples of such conditions are: o An address Drop operation referencing an address that is not associated with the peer in the current session. o An address Add operation referencing an address that has already been added to the peer in the current session." That said, there is "wiggle room" in the text to allow implementations to decide if additional conditions apply. Regards, Stan On Tue, Nov 7, 2017 at 11:12 AM, Tran, Anthony <Anthony.Tran@gd-ms.ca<mailto:Anthony.Tran@gd-ms.ca>> wrote: Hello, I have a question regarding the scope of what RFC 8175 covers. Specifically section 13.8.1: IPv4 address processing. If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are: o An address Drop operation referencing an address that is not associated with the peer in the current session. o An address Add operation referencing an address that has already been added to the peer in the current session. Does the RFC cover what would be “invalid data” or is that determined by whoever is implementing the DLEP solution? Thanks in advance, Anthony Tran Anthony Tran, E.I.T. Evolve to Open (EvO) – Junior Software Engineer General Dynamics Misson Systems Canada Anthony.Tran@gd-ms.ca<mailto:Anthony.Tran@gd-ms.ca> 403-295-5251<tel:(403)%20295-5251> _______________________________________________ manet mailing list manet@ietf.org<mailto:manet@ietf.org> https://www.ietf.org/mailman/listinfo/manet
- Re: [manet] Question regarding RFC 8175 Rick Taylor