Re: [Plus] New Version Notification for draft-trammell-plus-spec-00.txt

Hi Thomas,

sorry for the late reply and thanks for the feedback!

See below!

> Am 06.01.2017 um 18:40 schrieb Fossati, Thomas (Nokia - GB) <thomas.fossati@nokia.com>:
> 
> Hi Mirja,
> 
> On 05/01/2017 10:44, "Plus on behalf of Mirja Kühlewind"
> <plus-bounces@ietf.org on behalf of mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>> we submitted (just before Christmas) a new draft proposing a common wire
>> image for UDP substrates. Based on the previous discussion on the list,
>> the proposal follows the simpler approach of using a random serial number
>> and highest number echo for basic diagnostics. In addition, we discuss
>> further diagnostic information that could be provided by an extended
>> header without proposing a extended header format yet.
>> Stay tuned for further updates and please provide input or feedback!
>> Thanks!
> 
> I've just finished reading the draft and was extremely pleased to see the
> LoLa bit in the basic header.  An end-to-end integrity-protected marking
> is definitely better than DSCP.
> 
> It also look pretty straightforward to add a couple of PCFs to the
> extended header to support MTG signalling, which is nice.
> 
> A few editorial nits:
> Sec 2.1, second bullet: "When multiplexing, it must ensure the PSN is not
> already in use for the 5-tuple." -- you probably mean CAT instead of PSN?

Fixed in md file in GitHub.

> Sec 2.2, second bullet: "It verifies the integrity of the information in
> the PLUS Basic Header, using information carried in the overlying
> transport." -- it's not clear which "information carried in the overlying
> transport" you are referring to.

The idea here would be that the overlaying transport would e.g. have a hash that could be used to verify the header information. Basically this is a question about how the interface to the crypto engine would look like and we deliberately stayed a bit vague here. Should probably refine this for the next version. 

I’ve put an editor’s note in the md.

> Sec 2.3.1, first para -- a bit hard to parse.

Yes, that was broken. Fixed in the md now.

> 
> One meta-comment: how do you think the use of PLUS is negotiated by the
> endpoints?

Yes, this needs further discussion. The most likely case will be out-of-band knowledge (I know that this server on this port speaks plus) but we might also want to think about other discovery mechanisms but those things might actually be use case/higher protocol dependent.

Mirja

> 
> Cheers, t
> 
> 
>> Happy new year!
>> Mirja
>> 
>> 
>>> Am 23.12.2016 um 15:28 schrieb internet-drafts@ietf.org:
>>> 
>>> 
>>> A new version of I-D, draft-trammell-plus-spec-00.txt
>>> has been successfully submitted by Brian Trammell and posted to the
>>> IETF repository.
>>> 
>>> Name:		draft-trammell-plus-spec
>>> Revision:	00
>>> Title:		Path Layer UDP Substrate Specification
>>> Document date:	2016-12-23
>>> Group:		Individual Submission
>>> Pages:		13
>>> URL:            
>>> https://www.ietf.org/internet-drafts/draft-trammell-plus-spec-00.txt
>>> Status:         
>>> https://datatracker.ietf.org/doc/draft-trammell-plus-spec/
>>> Htmlized:       https://tools.ietf.org/html/draft-trammell-plus-spec-00
>>> 
>>> 
>>> Abstract:
>>>  This document specifies a common Path Layer UDP Substrate (PLUS) wire
>>>  image for encrypted transport protocols carried over UDP.  The base
>>>  PLUS header carries information for driving a minimal state machine
>>>  at middleboxes described in [I-D.trammell-plus-statefulness], and
>>>  provides optional exposure of additional information to devices along
>>>  the path using the mechanism described in
>>>  [I-D.trammell-plus-abstract-mech].
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>> 
>> _______________________________________________
>> Plus mailing list
>> Plus@ietf.org
>> https://www.ietf.org/mailman/listinfo/plus
>> 
> 