Re: [manet-dlep-rg] Slight issue with Data items

"Stan Ratliff (sratliff)" <> Mon, 10 March 2014 16:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 811D31A0642 for <>; Mon, 10 Mar 2014 09:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S-tbEpKT0X0V for <>; Mon, 10 Mar 2014 09:57:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 55FE41A0574 for <>; Mon, 10 Mar 2014 09:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2429; q=dns/txt; s=iport; t=1394470648; x=1395680248; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oiftBc/29aBaJSimPLcVZa6hPTCTOoEtln3FGujwR9k=; b=Z4lITHfsci5ID50EfXmf3ZK/wha18mkKXQqEo47Ci/arADfk8r14VGhp 6u8k6UYAtTJF+j6m1dnb1/dRu6MHNtNtKn03CMRlSZtw85MQCL9jJxtd9 RGiRP/Yl5IfXjw8NmiOUtoSSU28e7rrAakhcUh1lNJ/ugXTjfprxvGlvn s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="306221561"
Received: from ([]) by with ESMTP; 10 Mar 2014 16:57:27 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s2AGvRRk017057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Mar 2014 16:57:27 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 10 Mar 2014 11:57:27 -0500
From: "Stan Ratliff (sratliff)" <>
To: Rick Taylor <>
Thread-Topic: [manet-dlep-rg] Slight issue with Data items
Thread-Index: AQHPPH91PCp7d2LHg0SwkWmlhgboNJra3nSA
Date: Mon, 10 Mar 2014 16:57:27 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " Group, \(\)" <>
Subject: Re: [manet-dlep-rg] Slight issue with Data items
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Mar 2014 16:57:39 -0000

On Mar 10, 2014, at 12:40 PM, Rick Taylor <> wrote:

> Hi All,
> I've been ruminating over Data Items and their default handling as we discussed in London, i.e. an implementation MUST silently drop any unrecognised Data Items it receives.
> But, there is some inconsistency over what a Data Item is (in my mind), and so I ask:  Is a Data Item *any* signal payload, or is it one of the payload items in a Destination Up/Down/Update message?
> The reason I ask is that there is a class of TLVs in DLEP that appear in session initiation (and possibly discovery) that are semantically different from 'regular' TLVs in session signals: Version information, TCP server addresses, etc...  Now, are these TLVs treated as Data Items as far as the handling rules apply?  What happens if you receive a Version Data Item in a Destination_Update:  The implementation should recognise it, but not expect it where it finds it.
> So, have I revealed a new class of Data Item that needs it's own rules and status code, or do the existing rules still work?

I don't know if you've revealed a new class of data item, but you've opened an area for discussion that we haven't talked about yet - Data Items that are understood, but not meaningful for the DLEP signal. Version information in a destination update is a perfect example of that.

I'll offer up a slight modification of the "London Rule" :  Experimental Data Items (and Vendor-specific TLVs) that are not supported by an implementation should be parsed (e.g. "stepped over') and silently dropped. Data Item TLVs that are not *understood* (e.g. TLV number not registered, or "reserved"), OR are out-of-context (like a Version TLV in a destination update message) should cause PEER_TERMINATION and closure of TCP session.


> In summary, do we need to define "Status Code <N>: Data Item not allowed in last signal"
> Hmm... something for you all to ponder at the start of the week...
> Rick
> P.S> Is everyone happy for me to post the summary report to the WG mailing list?  If I hear no objections by close of play Tuesday, I'll just forward it.
> _______________________________________________
> manet-dlep-rg mailing list