Re: [6tisch] comments on latest terminology draft

Qin Wang <qinwang6top@yahoo.com> Wed, 27 April 2016 14:58 UTC

Return-Path: <qinwang6top@yahoo.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6200D12D851 for <6tisch@ietfa.amsl.com>; Wed, 27 Apr 2016 07:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.695
X-Spam-Level:
X-Spam-Status: No, score=-3.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn5mYi06NRPT for <6tisch@ietfa.amsl.com>; Wed, 27 Apr 2016 07:58:20 -0700 (PDT)
Received: from nm49-vm10.bullet.mail.bf1.yahoo.com (nm49-vm10.bullet.mail.bf1.yahoo.com [216.109.114.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9EDF12D849 for <6tisch@ietf.org>; Wed, 27 Apr 2016 07:58:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1461769098; bh=wZC2XAAL/7xq4ak5U5eiwTDsdTf3XVZ/RSOMlIF5XoE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=IvC2gUhOHqJLmnsQd9X6tq3GpdyTH/9X9OV0oz3+XKkycTC6IX26ljDmiPQ78IQvWjqppPHQEj34v3mgg0fCGC70lanYqt7JA1xmi0sRPIoC/4TkJDYCHT6FCsAvaHFBCb9gxdTrdq5Wa0HKIYkS4aBlVoPlsWK3A8cFS7NLBm0LYSAp0cKKkfMFNU1LS3fJT9XKgdShNWoN3k8z1MbFO6ujCYUYsnv7bJr9BMfFKY8BUxV1mSwQMvn3yE5ouRAa3CVcgXGhcAp4CU/Uuhw4YrudrKxfBP9k1Zw7+9/TMXqrmcDrYvt124fRIvMHW7L1HiPFCo9bx+E7zRIuxFbshw==
Received: from [98.139.215.140] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 27 Apr 2016 14:58:18 -0000
Received: from [98.139.212.198] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 27 Apr 2016 14:58:18 -0000
Received: from [127.0.0.1] by omp1007.mail.bf1.yahoo.com with NNFMP; 27 Apr 2016 14:58:18 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 656650.25558.bm@omp1007.mail.bf1.yahoo.com
X-YMail-OSG: FFWpdbQVM1mgEMxAfV._fGdDz4hjMs0N6T7a_pOOhf6ewW_wh4h6LpwJ9c5O3r4 2vYxxHZO3g7_PFzS1_0V470z8dfakuZMhSr8QIQk6dxafMbrw7AkSXIXOTN9sqtHcyGgZ06_M5VY nQVm1MKK68_DV433tPvcq7g6pSR0sa29lDu0oeGGuSdKmRzCcinJ9E6Zcv3zRJqeoLYvpVrfjcDx D99zMl21UhL9T2VvLgX85QW9mEL_WDw0qWg0oXICdV4a_eZtwqjX3MChDjTcOcYmVa7ggfYp11n4 9zobS1kr_47.zIEv5Z4Li0MPsF6ZXE8q5W6IGlzGBDKVMgj5V8on0DcaV_IQLPgTdf2h9KKq_yWr jtvsor3ZsWzq9cpAtmMTnB0CIR2X7oUp989fI4.IJyKUlVjncqLRbLxbz3vZsH8f6wwwSHQXl315 axZ2p92mlG0gHRjqVUUzh6pnstbbpDgLTMy4B7At9i4.e8L42m45dXCIOHkVKIQ--
Received: by 66.196.81.106; Wed, 27 Apr 2016 14:58:18 +0000
Date: Wed, 27 Apr 2016 14:58:17 +0000
From: Qin Wang <qinwang6top@yahoo.com>
To: Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>, Thomas Watteyne <thomas.watteyne@inria.fr>, "Turner, Randy" <Randy.Turner@landisgyr.com>
Message-ID: <1978594436.3446991.1461769097749.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <F085911F642A6847987ADA23E611780D1D14D40C@hoshi.uni.lux>
References: <F085911F642A6847987ADA23E611780D1D14D40C@hoshi.uni.lux>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_3446990_1097017418.1461769097725"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/3ziRXUgJxGvHIBqJsqcfPddmEl8>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] comments on latest terminology draft
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Qin Wang <qinwang6top@yahoo.com>
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2016 14:58:22 -0000

Hi all,
Do we really need the term "Link"? IMO, "Link" in 6TiSCH is same as Bundle. Right?
ThanksQin 

    On Friday, April 22, 2016 9:07 AM, Maria Rita PALATTELLA <maria-rita.palattella@uni.lu> wrote:
 

 #yiv5085214591 #yiv5085214591 -- _filtered #yiv5085214591 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5085214591 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5085214591 #yiv5085214591 p.yiv5085214591MsoNormal, #yiv5085214591 li.yiv5085214591MsoNormal, #yiv5085214591 div.yiv5085214591MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv5085214591 a:link, #yiv5085214591 span.yiv5085214591MsoHyperlink {color:blue;text-decoration:underline;}#yiv5085214591 a:visited, #yiv5085214591 span.yiv5085214591MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5085214591 span.yiv5085214591hoenzb {}#yiv5085214591 span.yiv5085214591EmailStyle18 {color:#1F497D;}#yiv5085214591 .yiv5085214591MsoChpDefault {} _filtered #yiv5085214591 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5085214591 div.yiv5085214591WordSection1 {}#yiv5085214591 Randy, sorry for my late  answer. Thomas, thanks for jumping into it.    Sure, the typos will be fixed in the next  version  ;)    About the definition of “link” I have to say this is  a  kind of endless story… We have been discussed a lot in the past how to define it, how to make  clear that the concept for 6TiSCH is different from classical  IETF  link  definition,  but it seems we created  confusion, by putting  too  much information all together into  it.    Thomas’s suggestion could  simplify the problem. The  link in fact  exists when the two neighbors have at least  one  cell to exchange pkts.    Thank you. Maria Rita       From: 6tisch [mailto:6tisch-bounces@ietf.org]On Behalf Of Thomas Watteyne
Sent: Friday, April 22, 2016 2:59 PM
To: Turner, Randy <Randy.Turner@landisgyr.com>
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] comments on latest terminology draft    Randy,    I'll let Maria Rita comment about the typos, I assume it's just a matter to spinning the doc.    About "link", I went back to read the draft. The following definition...    ------------------ A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP.  Thus, the IETF parlance for the term "Link" is adopted, as opposed to the IEEE802.15.4e terminology.  In the context of the 6TiSCH architecture, which applies to Low Power Lossy Networks (LLNs), an IPv6 subnet is usually not congruent to a single link and techniques such as IPv6 Neighbor Discovery Proxying are used to achieve reachability within the multilink subnet. A link is distinct from a track.  In fact, link local addresses are not expected to be used over a track for end to end communication.  Finally, from the Layer 3 perspective (where the inner complexities of TSCH operations are hidden to enable classical IP routing and forwarding), a single radio interface may be seen as a number of Links with different capabilities for unicast or multicast services. ---------------    ... is confusing, to say the least. IMO, it touches on almost all of the IETF work (talking about ND proxy, mutiling subnets, tracks in the definition of link ?!?) , is incredibly confusing, and as a result carries 0 information. What about    A link exists between two nodes when at least one cell is schedule between them.    Thomas             On Mon, Apr 18, 2016 at 8:38 PM, Turner, Randy <Randy.Turner@landisgyr.com> wrote: 
Hi Guys,   I had a couple of comments on the recent -07 terminology draft:   Deterministic Network - "A deterministic network can allocates..." should be "A deterministic network can allocate..."   "6top Data Convey Model" - Model describing how the 6top adaptation layer...<snip> Is this really an adaptation layer? - In the IETF, the term "adaptation layer" has come to mean something different   6p Transaction - "Part of the 6top Protocol, in consists in" should probably be "...consists of"   "Bundle" - typo "usining" should be "using"   "Link" – When I read this description, it sounds similar to an interference domain - should the difference (if any) be spelled out or distinguished ? Or am I the only one that sees this similarity?   Thanks!
R. 
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch 
   
    --  _______________________________________    Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH    www.thomaswatteyne.com _______________________________________ 
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch