IETF Logo Mail Archive

Re: [manet] Question regarding RFC 8175 version 29

Rick Taylor <rick@tropicalstormsoftware.com> Tue, 07 November 2017 21:10 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 0EB5F127ABE for <manet@ietfa.amsl.com>; Tue, 7 Nov 2017 13:10:12 -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 hUxOynkgrNbB for <manet@ietfa.amsl.com>; Tue, 7 Nov 2017 13:10:09 -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 B96B11271FD for <manet@ietf.org>; Tue, 7 Nov 2017 13:10:08 -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:09:45 +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 version 29
Thread-Index: AQHTV/2kIgjpW3yRskadQfXnnm8Iv6MJaDig
Date: Tue, 07 Nov 2017 21:09:43 +0000
Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801D32295C9@tss-server1.home.tropicalstormsoftware.com>
References: <0C73675F64C7DC4DAC17313DE1383D632F6B8CE3@ottsvw192.gdcan.com> <CALtoyonbLF9ejsx1LhxOnwP7LgLoM+WMpDjsWqEQ5jsgtq=-TQ@mail.gmail.com>
In-Reply-To: <CALtoyonbLF9ejsx1LhxOnwP7LgLoM+WMpDjsWqEQ5jsgtq=-TQ@mail.gmail.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_38A5475DE83986499AEACD2CFAFC3F9801D32295C9tssserver1hom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/5N09CrG--se7gdkYEfiU89wpSPA>
Subject: Re: [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 21:10:12 -0000

Anthony,

Adding to Stan’s response, in my mind “inconsistent data” covered the case where there is nothing wrong with the format of the message, i.e. all the right bytes and concerning valid destinations, but the semantic content of the message indicated to one peer that the other peer had somehow got its internal information out of sync.  That was why the word “inconsistent” was picked.

Hope that helps?

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

v2.23.0 | Report a Bug | By Email