Subject: [6lowpan] 6lowpan-nd ARO status for NS

From: "Colin O'Flynn" <[email-masked]>
Date: Fri, 8 Oct 2010 12:26:22 +0100

Hello,

As an additional comment before LC closing:

I think it would be prudent to set the ARO status to something besides '0'
in the NS, instead defining a new default for the registration message.

This would ensure you could never get in a state where either (a) someone
copies the ARO without changing the status or (b) a node somehow gets
confused and processes the ARO wrong. You can always tell from the ARO if
this is a registration message or a response message without looking at the
encapsulating layer (ie: NS/NA).

Regards,

  -Colin

---

From: Zach Shelby <[email-masked]>
Date: Wed, 13 Oct 2010 15:11:48 +0300

On Oct 8, 2010, at 2:26 PM, Colin O'Flynn wrote:

> I think it would be prudent to set the ARO status to something besides ‘0’ in the NS, instead defining a new default for the registration message.
>  
> This would ensure you could never get in a state where either (a) someone copies the ARO without changing the status or (b) a node somehow gets confused and processes the ARO wrong. You can always tell from the ARO if this is a registration message or a response message without looking at the encapsulating layer (ie: NS/NA).

I think this is a good idea, it could be set to e.g. 255 instead?

Zach

>  
> Regards,
>  
>   -Colin
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Oct 2010 14:36:28 +0200

One usual way of handling this is to split the code space in half, i.e. using 0 to 127 for requests and 128 to 255 for response statuses.  Obviously, we don't need request codes yet -- but maybe we can use the opportunity to get rid of the strange language about using the size of the message to distinguish different kinds of requests.

Just a thought (and no WG chair hats involved).

Gruesse, Carsten

---

From: Masaru Natsu <[email-masked]>
Date: Wed, 13 Oct 2010 10:08:14 -0700

Another way to address this (if the request and 
response Id is one octet long) the request using 
the first 7 bits (form 0.. bit 6)
and use bit 7 only for response... I mean set the 
most significant bit 1 when is a response ID....

Bad example:

request: 0x00
response 0x80

This expands the number of request and response to 
use. Also, same criteria applies to a 16bit 
request/response ID.

P.S. Also, this is just a thought..

-- Masaru

On 10/13/2010 5:36 AM, Carsten Bormann wrote:
> ---
> avast! Antivirus: Inbound message clean.
> Virus Database (VPS): 101013-0, 10/13/2010
> Tested on: 10/13/2010 9:16:40 AM
> avast! - copyright (c) 1988-2010 AVAST Software.
> http://www.avast.com
>
>
>
>

-- 
Ubilogix S.A. de R.L.
Avenida Obregon #110-4
Zona Centro. C.P. 22800
Ensenada B.C. México
[email-masked]

---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 101013-0, 10/13/2010
Tested on: 10/13/2010 10:08:17 AM
avast! - copyright (c) 1988-2010 AVAST Software.
http://www.avast.com

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 13 Oct 2010 19:09:22 +0100

Hi Carsten,

This seems more in-line with how other messages work, and personally I like
this a lot more than my suggestion.

Regards,

  -Colin

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: October 13, 2010 1:36 PM
To: Zach Shelby
Cc: Colin O'Flynn; [email-masked]
Subject: Re: [6lowpan] 6lowpan-nd ARO status for NS

One usual way of handling this is to split the code space in half, i.e.
using 0 to 127 for requests and 128 to 255 for response statuses.
Obviously, we don't need request codes yet -- but maybe we can use the
opportunity to get rid of the strange language about using the size of the
message to distinguish different kinds of requests.

Gruesse, Carsten