Re: [manet-dlep-rg] London meet up?

Teco Boot <> Thu, 06 March 2014 09:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4163F1A0178 for <>; Thu, 6 Mar 2014 01:05:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1D0MpaekKkR0 for <>; Thu, 6 Mar 2014 01:05:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 43F831A0170 for <>; Thu, 6 Mar 2014 01:05:21 -0800 (PST)
Received: by with SMTP id p61so2686222wes.11 for <>; Thu, 06 Mar 2014 01:05:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=6wWPegQGQqqBfzCmQpWKgOipYe8paRlEuPtsIBzOTIc=; b=jX6AdhRdfI3IHKMTQ2KWIVaylKywTkZkEmhlOfXB4wcnOKKpdhgDrTWU+HBn5wWby1 aYHCjuv0bDOZn9go1shh8AVtKvJDeHOM3Pg8eaMqkK2/T48giNkjNSTeREHpSegX+ABZ iKWJZST6L7LKDld2S2Ey+SVVCq7CrVs5IhZh35Nj3lfmc1wUPpf+0uI8Q7GOqtafH63x qDgRut36oeWVRUAGI4Ic/DkOrhL0rrgDwpW5rPTQGvTFPqDfFyDv0Yr2WbSM8uqKSvek nkVls0t8TiSe5SkTUUXE0I823Ve/Ralz02t7Yq/U75kP4RjV/74RZy6nrR0OnsqVOpLv qeHA==
X-Gm-Message-State: ALoCoQkwW8Ku3HHYYu+apLY8OqFsxeOCBUfNNH7rawghx3Ta0Rgn3QJ6gYBOvcV6GwFuxvePymHe
X-Received: by with SMTP id i8mr7838198wjz.81.1394096717556; Thu, 06 Mar 2014 01:05:17 -0800 (PST)
Received: from ( []) by with ESMTPSA id q15sm13749163wjw.18.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 01:05:16 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Teco Boot <>
In-Reply-To: <>
Date: Thu, 6 Mar 2014 10:05:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>, <>, <> <>
To: Rick Taylor <>
X-Mailer: Apple Mail (2.1874)
Cc: " Group, \(\)" <>
Subject: Re: [manet-dlep-rg] London meet up?
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: Thu, 06 Mar 2014 09:05:25 -0000

You missed cleanup delay and EFT, microseconds, 32-bit. Max is over an hour delay. Space agencies may have their own extension TLVs.

I did in-depth review on pre-05. Most of remarks is still to be incorporated.
I’ll better wait check again until pre-06?


Op 5 mrt. 2014, om 18:35 heeft Rick Taylor <> het volgende geschreven:

> Hi Guys,
> Thank you all very much for a very productive meeting this afternoon.  I include a write up of my notes, please correct me if I have missed anything pertinent.
> Stan has committed to updating the session initiation description to place the TCP server in the modem, so the initial part of the protocol is:  Modem broadcasts UDP Hello packets containing version, ident and TCP address/port.  Router TCP connects, session initiation occurs via the new TCP connection.
> Credit windowing will stay in the document, but will be clearly marked as an optional part of the protocol.  There was some concern raised over the clarity of the current text which will need to be address before last call.
> Vendor extensions will be defined using a new Data Item, containing a OUI (or something from an existing registry) and space for a payload.  There will need to be some guidance verbiage to characterise what is a valid vendor extension and what is not. 
> There was clarification of what both ends of a DLEP session must do on reciept of an unrecognized signal and data item.  For a data item, the receiver MUST ignore the data item, for a signal the recipient MUST send an error status signal and terminate the TCP connection. 
> There will be no facility in DLEP v1 for vendor extended signals.  Any extra signals will require an uplift of the verion of the protocol and require a new draft.
> There will be no such thing as a Peer Characteristic Request.  This will prevent abuse and misuse of the DLEP protocol to act as a configuration mechanism.
> There was further discussion concerning multiple QoS flows with seperate metrics across a single link.  This was agreed to be pushed out to another draft after DLEP v1, after some analysis that the proposed approach (heirachial data items) will not break existing DLEP v1 implementations.  Stan agreed to double check that the text specified 16bit length values for all TLVs (data and signals).
> There was discussion about enumerating error codes, and potential error text.  The status signal MUST include an error code, 0 being success, others to be enumerated after close analysis of the protocol, plus and optional free text field to carry loggable information, capped at 80 bytes, utf8 encoded.
> There was discussion of confidence values for metrics, and this was rejected as a core DLEP mechanism, and the suggestion was to use an extension data item TLV instead.
> In light of achieveing their goal of listing the outstanding points that needed to be reolved before DLEP can make progress to WG last-call, and actually achieving suitable consensus to resolve the outstanding issues to the satisafaction of one of the authors present, the DT decided to not apply for a continuation of their charter, and to instead announce "Mission Complete"
> Cheers,
> Rick Taylor
> _______________________________________________
> manet-dlep-rg mailing list