Hi folks
The IESG has evaluation process positions as DISCUSS and others, which
is part of examining the I-D before making a decision. IMO also IETF
participants have positions which may name process positions (includes
the WG-chairs and IESG members' positions, because they are also
IETF-participants), I think this message can be a good recommendation
point of view to add-to/update RFC4144,
I agree that after submission of the I-D to IESG by the authors or WG,
the reviewer SHOULD NOT discuss with the authors after his review only
if the reviewer is a user of the I-D. We can define the reviewer is in
REVIEW position, and there is possibility of DISCUSS if he/she is a
user. On the other hand, I think the authors/WGs MUST reply to the
review, because they are in SUBMIT position, they reply to all
comments on the submitted I-D.
I beleive that at any time/place any participant may comment on any
document or input in IETF and may open discussion, but it helps if it
known where the participant poster stands. I remember that once
related to one I-D a participant was commenting in WG and the author
misunderstood him and thought he was in object position but he was in
agree position, he just commented for the best.
Therefore, I may not reply to the below, for all the best reasons :)
AB
++
Sub: Re: Last Call: <draft-cardenas-dff-09.txt> (Depth-First
Forwarding in Unreliable Networks (DFF)) to Experimental RFC
On 2/12/13, Ulrich Herberg <ulrich@xxxxxxxxxxxx> wrote:
> AB,
>
> thank you for the review. See my answer below:
>
> On Sun, Feb 10, 2013 at 3:08 AM, Abdussalam Baryun
> <abdussalambaryun@xxxxxxxxx> wrote:
>>
>> Reply to your request dated 07/02/2013
>> Also following AD advice.
>> Draft Reviewed By: Abdussalam Baryun (AB) Dated: 10/02/2013
>>
>> Reviewer Comment #AB1: Related to Aim and Terminology.
>> ++++++++++++++++++++++++++++++++++++
>>
>> Overall I support the work, but subject to amendments.
>>
>> The Abstract is interesting but seem general
>
> Do you have any specific suggestions what you would like to add/change
> in the abstract?
>
>
>
>> > This document specifies the "Depth-First Forwarding" (DFF) protocol
>> > for IPv6 networks,
>>
>> AB> do you mean all IPv6 networks, if some please mention *some*
>
> I don't think this is relevant to add in the abstract. As stated in
> section 3 of the draft, it can be used for all IPv6 networks, but for
> some the protocol is not very beneficial (and examples are given for
> such situations).
>
>
>> > a data forwarding mechanism that can increase
>> > reliability of data delivery in networks with dynamic topology
>> > and/or
>> > lossy links.
>>
>> AB> IPv6 considers dynamic topology, does the paragraph mean that some
>> networks are static topology.
>
> I am not quite sure what you mean by IPv6 "considers topology". In a
> static topology (i.e. with no or very few changes of links) and with
> low packet loss rate, the DFF protocol would have little (or no)
> benefit, because most likely the packets would be sent from the source
> to the destination according to the information provided by the
> routing protocol, and no packets would be lost.
>
>
>
>> Suggest to clarify the dynamic
>> frequency.
>
> I am not sure what you would like to see clarified. Can you be more
> specific?
>
>
>> Also not clear what is missing with IPv6 protocol in such
>> nets that needs DFF.
>
> If you mean data forwarding, I think the draft is pretty clear about
> which cases it is beneficial in. The motivation for DFF is explained
> in section 1.1.
>
>
>> > The protocol operates entirely on the forwarding plane,
>> > but may interact with the routing plane.
>>
>> AB> amend> entirely on the forwarding plane,
>> to; entirely within the forwarding plane,
>
> I am not a native English speaker, but "to operate on" seems a valid
> usage of the word. But maybe a native speaker could suggest which is
> the right usage.
>
>
>>
>> > The routing plane may be informed of
>> > failures to deliver a packet or loops.
>>
>> AB> Amend> routing plane may be informed
>> to; routing plane protocols may be informed
>
> I think the current sentence is sufficient; I don't see the benefit of
> adding the word "protocols".
>
>
>
>> Terminology section>
>>
>> AB> you need to define that all routers have the DFF protocol, even
>> though it is known by heart that any forwarder needs to run DFF but
>> you MUST mention that at least to the reader,
>
> I think this is actually a good point. I was wondering whether to
> enforce all routers in a routing domain to run DFF. That does not seem
> like a reasonable approach. I found only one case that could be a
> problem when using both DFF and non-DFF routers in the network that
> results in a loop, but I think I found an easy fix. Here is the
> problem illustrated using an example:
>
> ...--- A ----- B ---- C --- ...
>
> Assume routers A and C use DFF, but not B. When B receives a packet
> from A, it would ignore the DFF header and skip over it, and then
> forward the packet to C (assuming C is the next hop in its RIB). Now,
> it is possible that C returns the packet (RET==1) to B, e.g. because
> it does not have any other neighbor. B receives the returned packet
> and would resend the packet to C (because it does not care about the
> DFF header), and thus RET would still be 1. C, having tried already
> all neighbors would return the packet to B (and so on, loop between B
> and C until hop-limit == 0).
>
> I see the following options:
> 1) Change the options header type from something starting with 001
> (i.e. "skip over this option and continue processing the header.") to
> 011 ("discard the packet.") in IPv6 to discard the packet if the
> header is unknown. This would avoid the problem, but I don't think
> that's possible for 6lowpan mesh-under.
> 2) Mandate that all routers in the routing domain "MUST use DFF" for
> forwarding packets.
> 3) Add a rule that if a packet is returned (RET==1) from P_prev_hop
> (i.e. the original previous hop when first received a packet), it is
> discarded, e.g. if router C receives a packet from B with RET==1 and B
> is the P_prev_hop.
>
> Option 1) would be possible, but not for 6lowpans, only for IPv6
> route-over. Option 2) is probably not very good. Option 3) would fix
> the loop issue, and thus allows non-DFF and DFF routers in the same
> network. I will provide some updated text in the next revision of the
> draft.
>
>
>
>>
>> AB> you missed to define the Router, which is mentioned many times but
>> I don't know which one. I think it is a must because you refer to two
>> planes forwarding and routing planes. Please define the Forwarder as
>> well. I don't find any Forwarder action in the draft, why not while
>> you specify there is a forwarding plane!
>
> I am undecided on defining the term "router". It is a well-known term
> in IETF; but then, maybe one could define it like in RFC6130 ("Router
> - A router running this protocol"). Not sure this conveys a lot of
> information, though. So unless others also suggest adding it, I will
> not change the terminology section.
> Since I don't use the term "forwarder" (which is usually part of the
> functions of a router), I don't think I should define that in the
> terminology.
>
>
>>
>> AB> suggest that you explaine forwarding and routing in separate and
>> show where they join relating to your protocol.
>
> I think the concept of forwarding and routing plane is fairly well
> understood in the IETF, so I don't think I should re-explain that in
> the draft.
>
> Best regards
> Ulrich
>