Re: [Roll] Topics and drafts within Roll charter

[Abdussalam Baryun <[e-mail]>]

Hi Peter and Ines,

I thank you for your respond, and I think that WG chair
guidance/discussions are always important for any WG list, not only for
IETF lists. My comments below,


On Mon, Feb 12, 2018 at 10:04 AM, peter van der Stok <[e-mail]>
wrote:

> Hi Abdul,
>
> Indeed, not all authors reply as quickly to reviews as one should wish.
>

I know that, but not a month, I think a month is a very very long time,
what do you think? However, I think that the WG chair/AD should follow up
with items that are related to WG LC drafts.


> There are several reasons for this, such as extra work load by employer,
> disappearing interest, etc..
> As a WG we should be aware that our work is a composition of contributions
> by individual authors.
>

I don't think that is a good excuse for IETF business, because we have
managers in IETF, amanager should follow up and push the work or find who
can help. No one asked me to help or no author asked the WG participants
that they need help. If authors don't ask for help, they MUST not hold our
draft or the draft we adopted. The IESG MUST solve this issue, and SHOULD
find a better way to make WG lists respond to serious people/participats.



>
> This being so, dependent on importance of topic, time spent by the
> authors, responsiveness by WG, and others, drafts will proceed in their own
> tempo (or leisure).
>
> It is a bad idea to stop all WG progress on all topics, because some
> drafts have a very slow progress.
>

I never like to stop any thing, but we need to agree/discuss on priorities,
any IETF WG should discuss all issues, but some WGs discuss off lines or in
the face to face meeting. While I don't do meeting, I am concerned by WG
list or our ROLL list.



> Drafts with little activity will finally disappear, while the WG as such
> needs to make progress.
>

I know, but the WG chair should comment on the list for such issue when
appears. Please note that in this comment I am not against any, but just
discussing for best practice,


>
> There are two concerns that I have at the moment and that I want to
> discuss during ietf101:
> - Making sure that all (current and future) drafts which discuss parent
> selection, ranking, or dodag selection, clarify the chosen metric and that
> the different metrics can co-exist or exclude each other during RPL
> operation.
> - Making sure that there are enough authors and reviewers to advance this
> subject
>
> I hope this clarifies the wish for a discussion during ietf101.
>

Yes, hope you/authors contact me if there is any draft needs
co-authoring/assistant, while some authors are bussy as you mentioned. So
we need to make things faster/acurate by sharing load.

AB

Africa Region

(above using SHOLD or MUST is not shouting, just like to use more clear
wording)


Peter
>
> Abdussalam Baryun schreef op 2018-02-10 10:21:
>
>> Hi WG,
>>
>> I disagree to discuss new issues before discussing our adopted drafts,
>> especially WGLC ones,
>>
>> I suggest that our editors reply to discussions in our list, related
>> to adopted drafts before the ietf meeting,
>>
>> I hope that this WG managers or Chairs, and the IETF chair follow up
>> to solve this important issue, the issue of no replies from ietf
>> lists.
>>
>> AB
>>
>> On Mon, Oct 9, 2017 at 9:46 AM, peter van der Stok
>> <[e-mail]> wrote:
>>
>> Hi Roll,
>>>
>>> In a discussion with Rahul and Pascal, it transpires that there are
>>> still many topics to address that fit within our charter. The
>>> proliferation of topics worries us a bit. We have only a limited
>>> number of active authors and some topics also seem to be competing.
>>> The result of this situation might be that we have an overflowing
>>> work agenda. Therefore, we need to find additional people to work on
>>> those topics; or reduce the number of topics.
>>> It is our suggestion that we discuss these topics, find dedicated
>>> authors, and prioritize them  after some debate on the M-L.
>>> Also we should like to remove the competitive subjects by joining
>>> them into one draft.
>>>
>>> Your comments please.
>>>
>>> Ines + Peter
>>>
>>> ------------------------ List of topics
>>> ------------------------------------------
>>>
>>> 1 Route invalidation as a standalone topics The topic is mentioned
>>> in several drafts, but we need to come to one general approach.
>>>
>>> 2.A draft that allows a ND only device to connect, be
>>> reachable and move in a RPL network.
>>>
>>> 3. Not all implementers are aware of the design issues of storing
>>> mode of
>>> RPL vs non-storing. Both of the modes have issues with their design.
>>> Some
>>> issues are getting sorted out by drafts such as dao-projection and
>>> no-path
>>> DAO optimization. But still considerable design issues need to be
>>> handled. To name few:
>>> a. handling parent switching optimally in storing MOP. Currently
>>> with
>>> Storing MOP it would lead to DIO/DAO storm in the sub-path from the
>>> child
>>> node who switches the parent. This is handled well in NS MOP
>>> (Non-storing
>>> MOP).
>>> b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases
>>> it is
>>> trivial, but in most cases it is not (considering dependence on
>>> several
>>> state variables such as DTSN across reboots)! Also for practical
>>> point of
>>> view, need to consider that writing to flash/NV-memory is not a good
>>> option in
>>> embedded devices and should be avoided as far as possible.
>>> c. Problems of current DAO-ACK in storing MOP. There was a
>>> discussion on
>>> ML long time back, but there is no draft in the space.
>>> d. problem of bulging IPv6 headers in NS MOP. Most part of this will
>>> be
>>> taken care of by SRH compression and dao-projection.
>>>
>>> 4. Confusion between DAG selection (for joining and jumping) vs.
>>> parent selection (for re-parenting within a DODAG). 6TiSCH has
>>> isolated the need for a join preference which is different from the
>>> Rank used in parent selection. The resulting Rank may be used in the
>>> join preference, but not only. The size of the DODAG, the number of
>>> children of that parent, etc... may influence. There is basically
>>> the need for a new sort of objective function, this time in order to
>>> select a DODAG to join.
>>>
>>> 5. Integration with 6LoWPAN. We need to write that draft that
>>> standardizes the procedures suggested in the 6TiSCH architecture and
>>> shows a non RPL aware joining a DODAG and moving inside. With the
>>> new 6LoWPAN ND and the NP DAO, we now have all the tools to do it.
>>> Unless we consider that the reference is the 6TiSCH architecture in
>>> which case we complete the design there.
>>>
>>> 6. Exposing (some of) the structure of the Mesh to the root to
>>> enable the DAO projection for transversal routes and in storing mode
>>> in general.
>>>
>>> 7. Using bitmaps for multicast and unicast routing, used in
>>> 7a routing tables, or 7b in header for source routing
>>>
>>> 8. Guidance to implementers who are relatively new to
>>> RPL are not aware of many design considerations and there should be
>>> a doc which talks about it. Similar work is started in
>>> https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 [1]
>>> ... but
>>> it does not list all the issues imo.
>>>
>>> 9. What to do with expired YANG model drafts
>>>
>>> 10. What else do you think that we should consider?
>>>
>>> --
>>> Peter van der Stok
>>> vanderstok consultancy
>>> mailto: [e-mail]
>>> www: www.vanderstok.org [2]
>>> tel NL: [phone] [3]     F: [phone] [4]
>>>
>>> _______________________________________________
>>> Roll mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll [5]
>>>
>>
>>
>>
>> Links:
>> ------
>> [1] https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09
>> [2] http://www.vanderstok.org
>> [3] tel:%2B31%280%29492474673
>> [4] tel:%2B33%280%29966015248
>> [5] https://www.ietf.org/mailman/listinfo/roll
>>
>