#35: Last call comments: editorial
'''Chonggang:'''
· pp. 3, 2nd paragraph, “…control operations such industrial
automation…” ---> ““…control operations such as industrial automation…”
· pp.3, 3rd paragraph, “…timeSlotted Channel Hopping …” --->
“…Time Slotted Channel Hoppin
#36: Last call comments: MCR comments
If it is going to proceed in volumes (I suggest "editions" is the correct
term), then I think that most things which are speculation should either
be removed to a later edition, or something specific should be said, with
the understanding that it might cha
#35: Last call comments: editorial
Comment (by pthub...@cisco.com):
Replying to [ticket:35 shwethab@…]:
> '''Chonggang:'''
>
> · pp. 3, 2nd paragraph, “…control operations such industrial
automation…” ---> ““…control operations such as industrial automation…”
> · pp.3, 3rd
#36: Last call comments: MCR comments
Comment (by pthub...@cisco.com):
Replying to [ticket:36 shwethab@…]:
> If it is going to proceed in volumes (I suggest "editions" is the
correct term), then I think that most things which are speculation should
either be removed to a later edition, or s
#36: Last call comments: MCR comments
Comment (by pthub...@cisco.com):
Replying to [ticket:36 shwethab@…]:
> If it is going to proceed in volumes (I suggest "editions" is the
correct term), then I think that most things which are speculation should
either be removed to a later edition, or s
#36: Last call comments: MCR comments
Comment (by pthub...@cisco.com):
6tisch issue tracker wrote:
>> 3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability]
>> will
> ever get published. If there is terminology there that we still
need,
#36: Last call comments: MCR comments
Comment (by pthub...@cisco.com):
6tisch issue tracker wrote:
>> 3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability]
>> will
> ever get published. If there is terminology there that we still
need,
#36: Last call comments: MCR comments
Changes (by shwet...@cisco.com):
* status: new => closed
* resolution: => fixed
--
-+-
Reporter: | Owner: draft-ietf-6tisch-
shwet...@cisco.com | arch
#36: Last call comments: MCR comments
Comment (by shwet...@cisco.com):
Micheal confirmed that -07 addresses all these points
--
-+-
Reporter: | Owner: draft-ietf-6tisch-
shwet...@cisco.com | a
#37: Make Archie infiormational
Architecture says track = standard, should be informational
--
+
Reporter: pthub...@cisco.com | Owner: pthub...@cisco.com
Type: defect | Status: new
Priority: major
#4: add text to desceribe the high level PCE operation for 6Tisch
Changes (by pthub...@cisco.com):
* status: new => closed
* resolution: => fixed
Comment:
Added text in section 5
"
The work on centralized track computation is deferred to a subsequent
volume of the architecture.
#35: Last call comments: editorial
Comment (by pthub...@cisco.com):
All fixed in 07. Got confirm from issue authors that the text in 07 was
solving the tickets.
--
-+-
Reporter: | Owner: draft-ietf-
#35: Last call comments: editorial
Changes (by pthub...@cisco.com):
* status: new => closed
* resolution: => fixed
--
-+-
Reporter: | Owner: draft-ietf-6tisch-
shwet...@cisco.com | archite
#37: Make Archie infiormational
Changes (by pthub...@cisco.com):
* status: new => closed
* resolution: => fixed
Comment:
done in 08
--
+-
Reporter: pthub...@cisco.com | Owner: pthub...@cisco.com
Type: defec
#10: 6tisch-security: packet size and quantity for join process
Changes (by pthub...@cisco.com):
* milestone: milestone1 => Architecture volume 2
--
--+
Reporter: m...@sandelman.ca | Owner: m...@sandelman.ca
Type:
#11: 6tisch-security: device IDs
Changes (by pthub...@cisco.com):
* version: => 2.0
* milestone: milestone1 => Architecture volume 2
--
--+
Reporter: m...@sandelman.ca | Owner: m...@sandelman.ca
Type: task
#12: 6tisch-security: join process impact on network
Changes (by pthub...@cisco.com):
* version: => 2.0
* milestone: milestone1 => Architecture volume 2
--
--+
Reporter: m...@sandelman.ca | Owner: m...@sandelman.ca
#13: 6tisch-security: join process impact on network, local schedule
Changes (by pthub...@cisco.com):
* version: => 2.0
* milestone: milestone1 => Architecture volume 2
--
--+
Reporter: m...@sandelman.ca | Owner: m.
#20: 6tisch-security: document persistant storage requirements/expectations
Changes (by pthub...@cisco.com):
* version: => 2.0
* type: defect => task
* milestone: milestone1 => Architecture volume 2
--
--+
Reporter: m...@
#21: 6tisch-security: consider how a node to dis-enroll a node
Changes (by pthub...@cisco.com):
* version: => 2.0
* type: defect => task
* milestone: milestone1 => Architecture volume 2
--
--+
Reporter: m...@sandelman.ca
#38: update links to documents
please use un-versioned links ot the I-Ds.
Raised by randy.tur...@landisgyr.com, see http://www.ietf.org/mail-
archive/web/6tisch/current/msg04144.html
--
-+-
Reporter:
#39: Ralph's INT AREA review
I am an assigned INT directorate reviewer for draft-ietf-6tisch-
minimal-12. These comments were written primarily for the benefit of the
Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
comments fro
#39: Ralph's INT AREA review
Description changed by pthub...@cisco.com:
Old description:
> I am an assigned INT directorate reviewer for draft-ietf-6tisch-
> minimal-12. These comments were written primarily for the benefit of the
> Internet Area Directors. Document editors and
> shepherd(s) sh
#39: Ralph's INT AREA review
Changes (by pthub...@cisco.com):
* status: new => assigned
Comment:
Dear all:
I created issue 39 to address Ralph’s comments; The changes are quite
extensive, but I tried to maintain the content to the level of 08.
The result is already visible in https://bi
#40: Ralph's INT AREA review on minimal
I am an assigned INT directorate reviewer for draft-ietf-6tisch-
minimal-12. These comments were written primarily for the benefit of the
Internet Area Directors. Document editors and
shepherd(s) should treat these comments just like they would treat
c
#39: Ralph's INT AREA review
Comment (by pthub...@cisco.com):
Published 09 with the proposed changes, awaiting feedback frm Ralph and
the group
--
+-
Reporter: pthub...@cisco.com | Owner: pthub...@cisco.com
Type:
#40: Ralph's INT AREA review on minimal
Comment (by pthub...@cisco.com):
Xavi addressed comments one by one, tracked under bitbucket as
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal/issues/
All issues are solved but the intended status that we will track with a
separate ticket
--
#41: internded status for draft minimal
From Suresh's INT-DIR review
* Intended Status:
This looks more like a recommended set of network configuration parameters
than a new protocol definition. Has the wg considered whether the Proposed
Standard status is appropriate (as opposed to Info or
#41: internded status for draft minimal
Comment (by pthub...@cisco.com):
from the interim call minutes, Nov 27th
o [Michael] no intended surveys, but BCPs ("profile") say that,
"when using protocol X in context Y, you SHOULD use parameters Z". This is
for operators rather than impleme
#41: intended status for draft minimal
--
---+
Reporter: pthub...@cisco.com | Owner: xvilajos...@gmail.com
Type: defect | Status: new
Priority: major | Milestone: mi
#40: Ralph's INT AREA review on minimal
Changes (by pthub...@cisco.com):
* status: new => closed
* resolution: => fixed
--
---+
Reporter: pthub...@cisco.com | Owner: xvilajos...@gmail.com
Type: defect
#40: Ralph's INT AREA review on minimal
Comment (by pthub...@cisco.com):
All issues but the intended status fixed in https://www.ietf.org/id/draft-
ietf-6tisch-minimal-13.txt. Intended status tracked as issue #41. This
issu is fixed, waiting for feed back to close.
--
--
#39: Ralph's INT AREA review
Changes (by pthub...@cisco.com):
* status: assigned => closed
* resolution: => fixed
--
+-
Reporter: pthub...@cisco.com | Owner: pthub...@cisco.com
Type: defect |
#39: Ralph's INT AREA review
Comment (by pthub...@cisco.com):
All issues fixed with http://www.ietf.org/id/draft-ietf-6tisch-
architecture-09.txt.
Waiting for feedback to close.
--
+-
Reporter: pthub...@cisco.com | Own
#42: update the abstract and the intro of the minimpal draft after Ralph's
Intarea review
Dear all:
We had a final call on this at the interim, and the text below is now
adopted.
Xavi: can you please retrofit the text below in the minimal draft?
Cheers,
Pascal
-Original Message
#41: intended status for draft minimal
Comment (by watte...@eecs.berkeley.edu):
The draft was republished (https://tools.ietf.org/html/draft-ietf-6tisch-
minimal-14) as BCP, per the discussions captured in this issue. This
resolves this issue.
--
---+
#41: intended status for draft minimal
Changes (by watte...@eecs.berkeley.edu):
* status: new => closed
* resolution: => fixed
--
---+
Reporter: pthub...@cisco.com | Owner: xvilajos...@gmail.com
Type: d
#44: cleanup Figure 1
Convert the figure in 3 sub-figures. One that represents the case that
there are too many cells, another where there are more cells needed and
another where the number of cells is fine. Also, draw the THRESH as a
single-ended arrow.
--
--
#43: 6P CLEAR command should cause both node to clear cells
The 6P draft should indicate that, if a 6P CLEAR is issued, BOTH motes
MUST clear cells
--
-+-
Reporter: | Owner: draft-ietf-6tis
#45: details missing on error codes
Thread started https://www.ietf.org/mail-
archive/web/6tisch/current/msg04764.html
- [Tengfei] error codes not detailed enough. What does RC_ERROR mean?
- [Dale] exact error code returned can be implementation specific. [light
disagreement from Qin and Xav
#46: add LinkOptions flags to 6P messages?
thread started in https://www.ietf.org/mail-
archive/web/6tisch/current/msg04780.html:
Proposal is to add a bitmap of flags to a 6P ADD command so that a node
can schedule both TX and RX cells to its neighbor, possibly shared.
--
--
#47: proposal: 6P receiver cell suggestion
Context:
- When an 6P ADD command fails, today transmitter side has to "guess" at
new cells to suggest.
- It might take multiple (failed) 6P ADD transactions before finding the
cells that are acceptable to receiver side
Proposal:
- On a failed 6P
#48: dynamic number of cells in response
Context:
- in https://tools.ietf.org/html/draft-ietf-6tisch-6top-
protocol-02#section-4.3.10, "If node A requests more cells than can fit in
the response, node B MUST return code RC_ERR_NORES and an empty cell
list."
- it's possible that the number of
#43: 6P CLEAR command should cause both node to clear cells
Changes (by watte...@eecs.berkeley.edu):
* status: new => closed
* resolution: => fixed
--
-+-
Reporter: | Owner: draft-iet
#43: 6P CLEAR command should cause both node to clear cells
Comment (by watte...@eecs.berkeley.edu):
captured in -02
--
-+-
Reporter: | Owner: draft-ietf-6tisch-
watte...@eecs.berkeley.
#45: details missing on error codes
Comment (by watte...@eecs.berkeley.edu):
The proposal which reached consensus discussed at the 10/07/2016 interim
is:
- change RC_ERR to RC_ERR_RESET in https://tools.ietf.org/html/draft-ietf-
6tisch-6top-protocol-02#section-4.3.3
- add a couple of lines
#46: add LinkOptions flags to 6P messages?
Comment (by watte...@eecs.berkeley.edu):
The proposal which reached consensus discussed at the 10/07/2016 interim
is:
- add a 1-byte "cellOptions" field in the 6P ADD command, between the
metadata and the cellList fields
- the cellOptions field con
#47: proposal: 6P receiver cell suggestion
Comment (by watte...@eecs.berkeley.edu):
The proposal has reached consensus at the 09/23/2016 interim meeting. Per
the worflow, please raise additional comment in the next 48h. If
consensus, we will reassign issues to the editor.
--
---
#48: dynamic number of cells in response
Comment (by watte...@eecs.berkeley.edu):
The proposal has reached consensus at the 09/23/2016 interim meeting. Per
the worflow, please raise additional comment in the next 48h. If
consensus, we will reassign issues to the editor.
--
-
#49: [typo] remove "(default 11)" from Table
Table 1 contains the statement "(default 11)". That statement shouldn't be
there.
--
-+-
Reporter: | Owner: draft-ietf-6tisch-
watte...@eecs.
#49: [typo] remove "(default 11)" from Table
Comment (by watte...@eecs.berkeley.edu):
Fixed by Xavi in https://bitbucket.org/6tisch/draft-ietf-6tisch-
minimal/commits/30b8541b9caf9e743fb281114fb493fe183e1e4b.
--
-+-
Re
#49: [typo] remove "(default 11)" from Table
Changes (by watte...@eecs.berkeley.edu):
* owner: draft-ietf-6tisch-mini...@tools.ietf.org =>
watte...@eecs.berkeley.edu
--
-+-
Reporter: |
#49: [typo] remove "(default 11)" from Table
Changes (by watte...@eecs.berkeley.edu):
* status: new => assigned
--
-+-
Reporter: | Owner:
watte...@eecs.berkeley.edu | watte...
#50: typos
"and determine" -> "and determines"
re-allocation-> relocation
dissappears -> disappears
6P ALL Request -> 6P ADD Request?
--
---+---
Reporter: diego.dujo...@mail.udp.cl | Owner: Diego Dujovne
Type: defect
#50: typos
Changes (by diego.dujo...@mail.udp.cl):
* priority: major => minor
--
---+
Reporter: diego.dujo...@mail.udp.cl | Owner: Diego Dujovne
Type: defect | Status: new
Priority: mi
#51: Proposed Editorial changes
- the many acronyms (BEA, COBU, NIBR,NOB, AP, etc) add confusion more than
clarity. Can we not simply talk about "incoming", "outgoing" and
"generated"?
- isn't "NOB=NIBR-COBU", not "NOB=COBU+NIBR"
- the draft starts very abruptly by referencing triggering ev
#51: Proposed Editorial changes
Changes (by diego.dujo...@mail.udp.cl):
* owner: draft-ietf-6tisch-6top-...@ietf.org => diego.dujo...@mail.udp.cl
* status: new => assigned
--
-+-
Reporter: |
#52: Whitelist / Blacklist
There was a discussion on the meaning of Whitelisting or Blacklisting
cells to request. This was created after a request to reduce the number of
cells on the transactions.
--
---+---
Reporter: diego.dujo.
#53: Timeout calculation
Timeout is currently calculated as the number of cells until the next
opportunity to transmit. This timeout should be larger than the normal
delay instead as we need to take into account the PDR.
But, the timeout should be related to the backoff period. Not to the PDR.
#54: Bandwidth -> Cells
the term bandwidth is confusing. Is it a number of packets per second? per
frame? a number of cells?
Proposed: change to number of cells, since cells have a fixed size.
Note: Bandwidth was never defined for SF0, but it should have been bytes
per second. Since the beg
#55: Comply with 6P requirements for SF0
Add a temporary Appendix to the draft to define if the draft complies to
SF0 requirements, as follows:
5.2. Requirements for an SF
The specification for an SF
o MUST specify an identifier for that SF.
o MUST specify the rule for a node
#56: Performance Evaluation
Follow the implementation section by a "Performance Evaluation" section in
which you list the key results. The WG needs to know the limits of the SF:
how does it scale with number of motes, network dynamics, etc.
--
---+-
#57: Improve figures on SF0 Allocation policy
As a result from the Berlin meeting, and in order to improve comprehension
of the Allocation Policy, a better figure should be included on the draft.
--
---+---
Reporter: diego.dujo...@m
#54: Bandwidth -> Cells
Comment (by diego.dujo...@mail.udp.cl):
In order to reduce complexity, from now on, instead of taking into account
the PDR when allocating cells, SF0 will allocate them directly, assuming a
100% PDR. The cell relocation algorithm will take care of PDR thresholds.
--
#53: Timeout calculation
Comment (by diego.dujo...@mail.udp.cl):
As from Tengfei's comment at Webex, we must go back to
the timeout proposed by Nicola, which is related to the
Backoff time and delete the current one.
timeout = (2^(macMaxBE+1)-2^macMinBE) * SM
- what timeout is this exactl
#58: Meaning of Metadata
I don't understand the use of the metadata in Section "Meaning of Metadata
Information".
There is a field called Metadata, which is owned by the SF and can use it
internally without intervention of any other entity. It is used to signal
the inter-node allocation proc
#59: Cell relocation
"Relocating Cells" now states:
SF0 uses Packet Delivery Rate (PDR) statistics to monitor the currently
allocated cells for cell re-allocation (by changing their slotOffset
and/or channelOffset) when it finds out that the PDR of one or more
softcells below 20% of the aver
#50: typos
Changes (by diego.dujo...@mail.udp.cl):
* status: new => closed
* resolution: => fixed
--
---+
Reporter: diego.dujo...@mail.udp.cl | Owner: Diego Dujovne
Type: defect | Stat
#51: Proposed Editorial changes
Comment (by diego.dujo...@mail.udp.cl):
Replying to [ticket:51 diego.dujovne@…]:
> - the many acronyms (BEA, COBU, NIBR,NOB, AP, etc) add confusion more
than clarity. Can we not simply talk about "incoming", "outgoing" and
"generated"?
Solved: instead of "ge
#53: Timeout calculation
Comment (by diego.dujo...@mail.udp.cl):
I propose not to define a timeout until simulation/experimental
work provides results. For the time being, we are leaving the
timeout for the implementer, since 6P says the SF may (and not
must) define a timeout.
--
-
#53: Timeout calculation
Comment (by diego.dujo...@mail.udp.cl):
Replying to [comment:2 diego.dujovne@…]:
> I propose not to define a timeout until simulation/experimental
> work provides results. For the time being, we are leaving the
> timeout for the implementer, since 6P says the SF may
#57: Improve figures on SF0 Allocation policy
Comment (by diego.dujo...@mail.udp.cl):
Modified the figure.
--
---+
Reporter: diego.dujo...@mail.udp.cl | Owner: Diego Dujovne
Type: defect |
#54: Bandwidth -> Cells
Comment (by diego.dujo...@mail.udp.cl):
Changed to number of cells. There is no more bandwidth involved.
--
---+
Reporter: diego.dujo...@mail.udp.cl | Owner: Diego Dujovne
Type: enhancement
#53: Timeout calculation
Changes (by diego.dujo...@mail.udp.cl):
* owner: Diego Dujovne => diego.dujo...@mail.udp.cl
--
-+-
Reporter: | Owner:
diego.dujo...@mail.udp.cl | dieg
74 matches
Mail list logo
