Subject: [manet] DLEP-10 comments

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 6 May 2015 17:39:59 +0000

Reading DLEP-10 here are my comments. These fall somewhere between a quick glance and a detailed analysis.

Terminology

Early in the document there are references to signals and data items, without explaining the difference (which is given later). Why is the term signals used rather than the far more common messages?

Introduction

Seems to suggest that only cable/DSL have configuration issues.

Is it worth being explicit that independent of routing protocol?

Authorship

In one place the draft refers to authors, in another to co-authors and WG. Personally I tend to go with an impersonal style, but even if not, consistency is suggested.

Transport mechanism and security

Not totally consistent here. The draft is about UDP and TCP, then in section 2 TLS is suggested, but in section 10 DTLS.

TBDs and IANA/RFCEd

I think the TBDs scattered through the document will be a nuisance when it comes to IANA and RFC Editor. In my experience IANA like tables in their section (with TBDs in them) that they can directly copy, rather than lists that need numbers, that then someone (RFC Editor?) has to backfill through the report. I'm not saying they won't, I'm saying the interactions I've had with them make this not what I think they'll like. In particular I'm sure they won't like the "could we have some experimental values" but will want a definite number, preferably in a table. And you will need an allocation policy, and if Expert Review, nominated experts.

I'd get some advice here.

Section 5.0 (i.e. 5 before 5.1)

This was initially confusing, how can something be optional at one end but mandatory at the other - until you realise how things are driven, in 5.1. That could be easier for the new reader.

And on a related point, Appendices A and B are what I wanted. Could use references to them so the reader will go and look.

Section 5.4 top of page 15, should that e.g. be an i.e.?

Section 6

This has some misstements. It says the signal header is a TLV, no, it's just a type and length. The signal (I still want to call it a message) is a TLV, but the header is not.

It also refers to data items following a signal. That should be following a signal header.

In fourth paragraph, add a comma after invalid (before and disallowed). It's ambiguous without, and the RFC Editor will put it (Oxford comma) in so might as well do it now.

Tables

Should these have captions? Should format pictures have captions? (I tend towards yes and no respectively).

Section 7.3 top of page 20

The wording about own timing and heuristics doesn't look interoperable friendly.

8.1 Version

This is version 0.9 in draft -10. Should that have been updated in the update from -09 to -10? That illustrates a problem with this approach - and another thing embedded in document to update for the RFC.

UTF-8

Is it expected to have to verify the UTF-8 is valid in any way, or is any byte sequence acceptable?

Incidentally 8.7 includes the one use of 1-octet in the draft, all the rest are in bits.

8.10 and similar

Add/Drop that only has two allowed values. Action on receiving other values? Should this be a bitfield with 7 bits reserved? (But you don't have any other bitfields.)

8.18

I make 32 bits of microseconds a little over an hour maximum. Fine - unless you deal with deep space probes (or other forms of DTN). Just to check we're happy with that. (We can be, but it should be deliberate, not an accident.)

Resources

This is a bit vague on what the point is.

Nits

I'd rather see "use" rather than "utilize" in some places.

a priori without a hyphen.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Stan Ratliff <[email-masked]>
Date: Sun, 10 May 2015 20:22:16 -0400

Chris,

Thanks for the thorough review. I have attempted to address these issues; a
DLEP-11 should be posted right after this email.

Working group,
Technically, WGLC on DLEP has expired (I believe it was May 8). So, we
request

On Wed, May 6, 2015 at 1:39 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Early in the document there are references to signals and data items,
> without explaining the difference (which is given later). Why is the term
> signals used rather than the far more common messages?
>

The term came out of our early discussions, in that the modem and router
are "signalling" each other concerning characteristics of the link. To be
honest, this is one that I would like to leave as-is (leaving Signals
instead of Messages). I have added verbiage attempting to explain the
difference, and standardizing on "Signal".

> Seems to suggest that only cable/DSL have configuration issues.

Removed the cable/DSL reference (it was not really necessary).

> Is it worth being explicit that independent of routing protocol?

The document speaks to the characteristics of the link. While I think your
question is valid, I believe that the focus on link characteristics takes
care of routing protocol independence (that, and the fact that we never
mention a routing protocol).

>
>
> Authorship
>
>
>
> In one place the draft refers to authors, in another to co-authors and WG.
> Personally I tend to go with an impersonal style, but even if not,
> consistency is suggested.
>

Made consistent references to co-authors.

> Not totally consistent here. The draft is about UDP and TCP, then in
> section 2 TLS is suggested, but in section 10 DTLS.
>

A left-over from our older UDP days. Thank you for the catch.

>
>
> TBDs and IANA/RFCEd
>
>
>
> I think the TBDs scattered through the document will be a nuisance when it
> comes to IANA and RFC Editor. In my experience IANA like tables in their
> section (with TBDs in them) that they can directly copy, rather than lists
> that need numbers, that then someone (RFC Editor?) has to backfill through
> the report. I’m not saying they won’t, I’m saying the interactions I’ve had
> with them make this not what I think they’ll like. In particular I’m sure
> they won’t like the “could we have some experimental values” but will want
> a definite number, preferably in a table. And you will need an allocation
> policy, and if Expert Review, nominated experts.
>
>
>
> I’d get some advice here.
>

Good point. I've removed TDB from the textual descriptions of the signals,
referring back to the table where the signals are listed.

> This was initially confusing, how can something be optional at one end but
> mandatory at the other – until you realise how things are driven, in 5.1.
> That could be easier for the new reader.
>
>
>
> And on a related point, Appendices A and B are what I wanted. Could use
> references to them so the reader will go and look.
>

I've added text to (hopefully) make those points clearer.

> Section 5.4 top of page 15, should that e.g. be an i.e.?

Yep.

>
>
> Section 6
>
>
>
> This has some misstements. It says the signal header is a TLV, no, it’s
> just a type and length. The signal (I still want to call it a message) is a
> TLV, but the header is not.
>
>
>
> In fourth paragraph, add a comma after invalid (before and disallowed).
> It’s ambiguous without, and the RFC Editor will put it (Oxford comma) in so
> might as well do it now.
>

Done.

> towards yes and no respectively).

Have added captions to the tables. To be honest, I kind of like the
captions on both... I wait for consensus on that one. ;-)

> The wording about own timing and heuristics doesn’t look interoperable
> friendly.
>

This is another one I didn't specifically address, because I'm sure how to
make it clearer. Henning hit an issue with a DLEP implementation where the
Peer Initialization signal wasn't responded to. Since heartbeats weren't
specifically setup - not until Peer Initialization ACK - the implementation
"hung". This just basically tries to say "You need to timeout the Peer Init
signal on your own, because Heartbeats aren't in play"...

>
>
> 8.1 Version
>
>
>
> This is version 0.9 in draft -10. Should that have been updated in the
> update from -09 to -10? That illustrates a problem with this approach – and
> another thing embedded in document to update for the RFC.
>

Changed to version 1.0.

> byte sequence acceptable?

Added text.

> Add/Drop that only has two allowed values. Action on receiving other
> values? Should this be a bitfield with 7 bits reserved? (But you don’t have
> any other bitfields.)
>

Fair point, but it looks like everything works.... if there's a lot of
interest in making everything bitfields, then we can see what we can do,
but at this point, with multiple implementations out there using what's
currently documented, I'm less willing to make changes.

>
>
> 8.18
>
>
>
> I make 32 bits of microseconds a little over an hour maximum. Fine –
> unless you deal with deep space probes (or other forms of DTN). Just to
> check we’re happy with that. (We can be, but it should be deliberate, not
> an accident.)
>

That's a REALLY good point. Other opinions on this?

> This is a bit vague on what the point is.

Yeah. Intentionally so, I'm afraid. It's a legacy item (just for equivalent
feature/function) with RFC 5578. It's pretty vague there, too.

>
>
> Nits
>
>
>
> I’d rather see “use” rather than “utilize” in some places.
>

> a priori without a hyphen.

Done on both items above.

Regards,
Stan

>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Rick Taylor <[email-masked]>
Date: Mon, 11 May 2015 08:55:43 +0000

Comments inline...
<snip>

>     8.18____
>     __ __
>     unless you deal with deep space probes (or other forms of DTN). Just
>     to check we’re happy with that. (We can be, but it should be
>     deliberate, not an accident.)
>
>

My opinion is to keep the 32bit milliseconds. For the vast majority of 
use-cases this is believed to be plenty.  For DTN (and other 
long-latency environments) I would suggest an extension rather than 
forcing everyone to use a 64bit value or some kind of BIGNUM.

For DTN, the per-hop latency is often much lower than the full end to 
end latency for a bundle, and I'm not sure any of the space agencies 
have rolled out DLEP on their deep-space links yet ;)  That's not to say 
that they shouldn't.

Cheers,

Rick Taylor

---

From: Rick Taylor <[email-masked]>
Date: Mon, 11 May 2015 08:57:31 +0000

Doh!  *micro*seconds...

---

From: Henning Rogge <[email-masked]>
Date: Mon, 11 May 2015 11:08:29 +0200

> have rolled out DLEP on their deep-space links yet ;)  That's not to say

Maybe moving it to 64 bit would make it "good enough" for everyone...
and it might simplify processing in the DLEP code because most of the
data we collect is 64 bit anyways.

64 bit in microseconds would be more than half a million years... good
enough even for intergalactic radio communication. ;)

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 11 May 2015 10:29:48 +0100

I don't have a strong opinion, I just wanted to be sure that a positive decision was made.

You could, as a third option, use 32 bits with a value of all ones meaning that value or anything higher. Again not a strong opinion, just an option.

Is it worth listing what issues remain and crossing them off as decisions made? I don't think it will be a long list.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 11 May 2015, at 09:55, Rick Taylor <[email-masked]> wrote:
> 
> Comments inline...
> <snip>
> 
> 
>>    8.18____
>> 
>>    __ __
>>

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 11 May 2015 09:05:12 -0400

All,

I'm with Henning on this one - most of the DLEP data items are 64-bit
quantities as is, and expanding the field to a 64-bit quantity solves all
problems (from what I can see, anyway).

On Mon, May 11, 2015 at 5:29 AM, Christopher Dearlove <
[email-masked]> wrote:

> You could, as a third option, use 32 bits with a value of all ones meaning
> that value or anything higher. Again not a strong opinion, just an option.
>
> Is it worth listing what issues remain and crossing them off as decisions
> made? I don't think it will be a long list.
>

Sure, we could. I took a shot at the list, based on items you brought up in
your review that I didn't specifically address. From what I can see, the
list (with proposed resolutions where possible) is:

1. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text as is,
with 'Signal' used instead of 'Message'.

2. Explicit statement that DLEP is independent of all routing protocols.
Proposed solution: Leave as-is, no routing protocols are even mentioned

3. Peer Initialization timeout verbiage.  Proposed solution: None at this
time. I don't have ideas on how to make the text clearer. Suggestions?

4. Use of bitfields instead of octets.  Proposed solution: Leave text
as-is. All things considered, this is a fairly minor, cosmetic item, and
would cause churn with existing implementations.

5. Definition of "Resources" term is vague.  Proposed solution:  Leave text
as-is. This is an item for backward compatibility with RFC 5578, and is
specified pretty much the same as what is in that draft.

Does that list look ok?

Regards,
Stan

---

From: Rick Taylor <[email-masked]>
Date: Mon, 11 May 2015 14:56:33 +0000

Comments inline...

On 11/05/15 14:05, Stan Ratliff wrote:
> quantities as is, and expanding the field to a 64-bit quantity solves
> all problems (from what I can see, anyway).

+1, nice and easy

>
> On Mon, May 11, 2015 at 5:29 AM, Christopher Dearlove
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     You could, as a third option, use 32 bits with a value of all ones
>     meaning that value or anything higher. Again not a strong opinion,
>     just an option.
>
>     Is it worth listing what issues remain and crossing them off as
>     decisions made? I don't think it will be a long list.
>
>
> Sure, we could. I took a shot at the list, based on items you brought up
> in your review that I didn't specifically address. From what I can see,
> the list (with proposed resolutions where possible) is:
>
> 1. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text as
> is, with 'Signal' used instead of 'Message'.
>
> 2. Explicit statement that DLEP is independent of all routing
> protocols.  Proposed solution: Leave as-is, no routing protocols are
> even mentioned
>
> 3. Peer Initialization timeout verbiage.  Proposed solution: None at
> this time. I don't have ideas on how to make the text clearer. Suggestions?
>
> 5. Definition of "Resources" term is vague.  Proposed solution:  Leave
> text as-is. This is an item for backward compatibility with RFC 5578,
> and is specified pretty much the same as what is in that draft.
>
> Does that list look ok?

Looks good to me, but id-nits raises one issue:

  ** Downref: Normative reference to an Informational RFC: RFC 5578

So that should probably be added to the list.

And Vignesh raised two typos:

In 8.4,

"The IPv4 Connection Point data item contains the following fields:"

Supposed to be IPv6..

In 8.18,

"The Latency data item data item MUST appear in the Peer"

'data item' repeated twice.

Rick

---

From: Stan Ratliff <[email-masked]>
Date: Mon, 11 May 2015 19:09:31 -0400

OK, so we have a list, and now we need *consensus* on how to fix items on
the list... ;-)

I've submitted DLEP-12 to reflect the list below:

1. Latency has been changed to a 64-bit unsigned quantity.   (FIXED)

2. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text as-is,
with 'Signal' used instead of 'Message'.

3. Explicit statement that DLEP is independent of routing protocol.
Proposed solution: Leave text as-is.

4. Peer Initialization timeout verbiage.  Proposed solution: Leave current
text as-is.

5. Use of bitfields instead of octets.  Proposed solution: Leave text
as-is. All things considered, this is a fairly minor, cosmetic item, and
would cause churn with existing implementations.

6. Definition of "Resources" term is vague.  Proposed solution:  Leave text
as-is. This is an item for backward compatibility with RFC 5578, and is
specified pretty much the same as what is in that draft.

7. Downref to RFC 5578. (FIXED IN DLEP-12)

8. Typo in 8.4 referencing IPv4 instead of IPv6.   (FIXED IN DLEP-12)

9. Typo in 8.18 referencing 'data item data item'.  (FIXED IN DLEP-12)

Calling for consensus on the "leave draft as is" items, or suggestions of
text.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Tue, 12 May 2015 10:15:40 +0200

On Tue, May 12, 2015 at 1:09 AM, Stan Ratliff <[email-masked]> wrote:
> 5. Use of bitfields instead of octets.  Proposed solution: Leave text as-is.
> All things considered, this is a fairly minor, cosmetic item, and would
> cause churn with existing implementations.

The only items I could find where this could be relevant is the
IPv4/IPv6-Address TLV (the Add/Remove field).

This could easily be changed into a bitarray because it only uses a
single bit, but I am not sure its worth the effort.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 May 2015 09:09:59 +0000

What should a receiver do if the octet has a value other than 0 or 1? Should this be noted? (That was my original point, a bitfield was one way to handle that.)

T:  +44 (0)1245 242194  |  E: [email-masked]

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 12 May 2015 09:16
To: Stan Ratliff
Cc: Rick Taylor; Dearlove, Christopher (UK); Christopher Dearlove; [email-masked]
Subject: Re: [manet] DLEP-10 comments

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

On Tue, May 12, 2015 at 1:09 AM, Stan Ratliff <[email-masked]> wrote:
> OK, so we have a list, and now we need *consensus* on how to fix items 
> on the list... ;-)
>
> All things considered, this is a fairly minor, cosmetic item, and 

The only items I could find where this could be relevant is the IPv4/IPv6-Address TLV (the Add/Remove field).

This could easily be changed into a bitarray because it only uses a single bit, but I am not sure its worth the effort.

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 May 2015 09:17:31 +0000

Comments inline...

On 12/05/15 00:09, Stan Ratliff wrote:
> 2. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text
> as-is, with 'Signal' used instead of 'Message'.

+1

> Proposed solution: Leave text as-is.

+1

>
> 4. Peer Initialization timeout verbiage.  Proposed solution: Leave
> current text as-is.

+1

> would cause churn with existing implementations.

The only valid values are 0 and 1 in the only place they are used IPv4/6 
address data items) so they are already bitfields with 7 bits reserved, 
so I don't think a change is needed.

>
> 6. Definition of "Resources" term is vague.  Proposed solution:  Leave

+1 - We've gone round this so many times my head hurts, let's just put 
down the whip and leave the dead horse alone.

Cheers,

Rick

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 May 2015 09:19:21 +0000

> What should a receiver do if the octet has a value other than 0 or 1? Should this be noted? (That was my original point, a bitfield was one way to handle that.)

This is mentioned elsewhere in the text.  A status code of 'invalid 
data' MUST be reported if the value is neither 1 or 0.

Rick

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 May 2015 09:23:02 +0000

Only defining 0 and 1 is not the same as defining a bitfield with 7 bits reserved. If you receive a 3 then if only 0 and 1 are defined this is neither, but if a bitfield then this is a 1. Checking that a reserved field is 0s is not a reason to reject a message in any protocol I've come across - in fact you wouldn't even check. (Be liberal in what you receive.)

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 12 May 2015 10:18
To: Stan Ratliff
Cc: Christopher Dearlove; Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] DLEP-10 comments

Comments inline...

+1

+1

+1

> as-is. All things considered, this is a fairly minor, cosmetic item, 
> and would cause churn with existing implementations.

The only valid values are 0 and 1 in the only place they are used IPv4/6 address data items) so they are already bitfields with 7 bits reserved, so I don't think a change is needed.

Cheers,

Rick

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 May 2015 09:23:45 +0000

If so, I missed it. Where is elsewhere?

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 12 May 2015 10:19
To: Dearlove, Christopher (UK); Henning Rogge; Stan Ratliff
Cc: Christopher Dearlove; [email-masked]
Subject: Re: [manet] DLEP-10 comments

On 12/05/15 10:09, Dearlove, Christopher (UK) wrote:
> What should a receiver do if the octet has a value other than 0 or 1? 
> Should this be noted? (That was my original point, a bitfield was one 
> way to handle that.)
>

This is mentioned elsewhere in the text.  A status code of 'invalid data' MUST be reported if the value is neither 1 or 0.

Rick

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 May 2015 09:32:27 +0000

Generic, rather than specific  I would suggest adding where use of 0 and 1 are defined a comment that any other value is (pick term of choice) to make it clear that applies here.

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 12 May 2015 10:29
To: Dearlove, Christopher (UK)
Subject: Re: [manet] DLEP-10 comments

> If so, I missed it. Where is elsewhere?

Section 6, final paragraph:

    If an unrecognized, or unexpected signal is received, or a received
    signal contains unrecognized, invalid, or disallowed duplicate data
    items, the receiving peer MUST terminate the session by issuing a
    Peer Termination signal (Section 7.7) with a Status data item
    (Section 8.2) containing the most relevant status code, and then
    close the TCP connection.

The most relevant status code in this case would be "invalid data"

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 May 2015 09:36:15 +0000

> Only defining 0 and 1 is not the same as defining a bitfield with 7 bits reserved. If you receive a 3 then if only 0 and 1 are defined this is neither, but if a bitfield then this is a 1. Checking…

... is a fair point.  If I remember correctly, originally the Add/Remove 
indicator for addresses had the values 1 or 2, this was changed to 1 or 
0, as it seemed a bit more 'C', i.e. !Add == Drop.

In the case of the Add/Remove indicator (the only example in DLEP), I 
can't see any other values, or other bits (treating the value as a flag 
set) that could carry meaning, so a 'Boolean octet' is the only way to 
treat it.  The more I think of it, treating the value as a bitfield is 
just misleading.

Does that help?

Rick

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 May 2015 09:38:03 +0000

As I said, my issue was what to do if receiving a value. A bitfield was one (hack probably) to do it. I think my last suggestion (just add an explicit comment that any other value is (insert term of choice)) is the way to go.

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 12 May 2015 10:36
To: Dearlove, Christopher (UK); Stan Ratliff
Cc: Christopher Dearlove; [email-masked]
Subject: Re: [manet] DLEP-10 comments

On 12/05/15 10:22, Dearlove, Christopher (UK) wrote:
> Only defining 0 and 1 is not the same as defining a bitfield with 7 
> bits reserved. If you receive a 3 then if only 0 and 1 are defined 
> this is neither, but if a bitfield then this is a 1. Checking that a 
> reserved field is 0s is not a reason to reject a message in any 
> protocol I've come across - in fact you wouldn't even check. (Be 
> liberal in what you receive.)
>

... is a fair point.  If I remember correctly, originally the Add/Remove indicator for addresses had the values 1 or 2, this was changed to 1 or 0, as it seemed a bit more 'C', i.e. !Add == Drop.

In the case of the Add/Remove indicator (the only example in DLEP), I can't see any other values, or other bits (treating the value as a flag
set) that could carry meaning, so a 'Boolean octet' is the only way to treat it.  The more I think of it, treating the value as a bitfield is just misleading.

Does that help?

Rick

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 May 2015 10:06:50 +0000

> As I said, my issue was what to do if receiving a value. A bitfield was one (hack probably) to do it. I think my last suggestion (just add an explicit comment that any other value is (insert term o…

That does make sense, but I then worry about how far we propagate that 
text... do you want us to add "Any other value received MUST result in 
termination..." text to every data item?

Just trying to scope the update,

Rick

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 12 May 2015 10:08:37 +0000

No, I was just suggesting adding that values other than 0 or 1 were (pick your own adjective) at that point. Nothing more, the general comment will then pick up on that.

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: 12 May 2015 11:07
To: Dearlove, Christopher (UK); Stan Ratliff
Cc: Christopher Dearlove; [email-masked]
Subject: Re: [manet] DLEP-10 comments

> As I said, my issue was what to do if receiving a value. A bitfield was one (hack probably) to do it. I think my last suggestion (just add an explicit comment that any other value is (insert term o…

That does make sense, but I then worry about how far we propagate that text... do you want us to add "Any other value received MUST result in termination..." text to every data item?

Rick

---

From: Rick Taylor <[email-masked]>
Date: Tue, 12 May 2015 10:21:43 +0000

> No, I was just suggesting adding that values other than 0 or 1 were (pick your own adjective) at that point. Nothing more, the general comment will then pick up on that.

Ok, sounds sensible... I'll wait for Stan to catch up with the conversation.

Thanks,

Rick

---

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 12 May 2015 13:08:29 +0000

I'm caught up. :-) 

Will add some text for the add/drop indicators. 

Regards,
Stan

> From: manet [mailto:[email-masked]] On Behalf Of Rick Taylor
> Sent: Tuesday, May 12, 2015 6:22 AM
> > No, I was just suggesting adding that values other than 0 or 1 were (pick
> your own adjective) at that point. Nothing more, the general comment will
> then pick up on that.
> >
>