[manet] Question regarding RFC 8175 version 29
"Tran, Anthony" <Anthony.Tran@gd-ms.ca> Tue, 07 November 2017 16:20 UTC
Return-Path: <Anthony.Tran@gd-ms.ca>
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 B22DD133666 for <manet@ietfa.amsl.com>; Tue, 7 Nov 2017 08:20:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=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 o-9InKNMKDkn for <manet@ietfa.amsl.com>; Tue, 7 Nov 2017 08:20:03 -0800 (PST)
Received: from OTTMGC002.GDCAN.COM (smtp5.gdcanada.com [209.29.4.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53423133722 for <manet@ietf.org>; Tue, 7 Nov 2017 08:12:20 -0800 (PST)
X-IronPort-AV: E=McAfee;i="5900,7806,8707"; a="5593916"
Received: from unknown (HELO gd-ms.ca) ([172.16.7.198]) by OTTMGC002.GDCAN.COM with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2017 11:12:18 -0500
Received: from OTTSVW192.gdcan.com ([fe80::5949:f987:4b00:edf]) by ottsvw198.gdcan.com ([::1]) with mapi id 14.03.0339.000; Tue, 7 Nov 2017 11:12:18 -0500
From: "Tran, Anthony" <Anthony.Tran@gd-ms.ca>
To: "manet@ietf.org" <manet@ietf.org>
Thread-Topic: Question regarding RFC 8175 version 29
Thread-Index: AdNX4tbByXxt+dOJQiqFQFSo6CFztQ==
Date: Tue, 07 Nov 2017 16:12:17 +0000
Message-ID: <0C73675F64C7DC4DAC17313DE1383D632F6B8CE3@ottsvw192.gdcan.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.164.62]
x-tm-as-product-ver: SMEX-12.0.0.1727-8.100.1062-23446.007
x-tm-as-result: No--22.027900-8.000000-31
x-tm-as-matchedid: 139704-113220-708196-111604-700362-705718-700345-701827-7 00264-702497-700450-700732-701012-701306-704425-709859-111605-700074-303242 -709323-188124-703223-700476-712032-702143-112074-863299-705861-701604-1880 51-701944-704421-701618-703112-700107-701192-106580-121133-111610-187125-18 8093-148004-148050-20020-42000-63
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_0C73675F64C7DC4DAC17313DE1383D632F6B8CE3ottsvw192gdcanc_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/dt7qVOQf2xvCME-S1bEx2fdmyf8>
X-Mailman-Approved-At: Tue, 07 Nov 2017 11:11:46 -0800
Subject: [manet] Question regarding RFC 8175 version 29
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 16:29:38 -0000
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
- [manet] Question regarding RFC 8175 version 29 Tran, Anthony
- Re: [manet] Question regarding RFC 8175 version 29 Stan Ratliff
- Re: [manet] Question regarding RFC 8175 version 29 Rick Taylor