Hi Jazi, I disagree with draft-editors decision, comments below,
On 3/23/13, Jiazi Yi <i...@jiaziyi.com> wrote: > Dear AB, > > On this particular issue (threats of packet sequence number), as far as I > can remember, the change was not based on (or influenced by) your input. In > the meantime, the input from Chris, Henning, Teco, etc., does have impact on > the document. my input had impact as well, please read my input, and discussion with you, you did not consider Teco input while I supported, the editors input was against to mention the change to consider NHDP sequence number consideration, now the WG draft considers, > > It is true that you mentioned several times that message sequence number > threat should be kept in nhdp-sec-threat. However, you didn't provide valid > technical argument why it should be kept. Actually, there is no doubt that > the original section of sequence number in -00 revision was wrong. No I did provide valid argument, I mentioned RFC6130 content that this threat draft ignored and one editor named that content as it was not normative, I continued arguing the important to mention thoes items then Teco supported my concerns as well, then the editors found that my argument is important because an old participant supported. > > My understanding of "IETF input" must be based on technical argument. > Simply saying "I want *foo*, not *bar*" - without explaining why - doesn't > say much thing. Even *foo* was adopted in the end. > In the contrast, even some one is against *foo*, but he provided valid > arguments during the discussion that help improving the design, he should be > regarded as contributor. > I explained why, not sure why you think my input has no reason, but please don't ignore that reviewers in IETF consider consistency of drafts, so I was focusing that your draft is following RFC6130, and that the draft mentioned sequence number in its draft-00 then removed without the WG consensus (which was not reflecting some participants concerns that I reminded the WG) do you think there is no reason now, > Last but not least, we acknowledged all the MANET participants - if you > regard yourself as one of the participants, then you are acknowledged. You mean the editors of this draft (I will note them as not acknowledging participants, for my future review). I am a MANET WG participants, but if you mention the names that made efforts it is more true because many are MANET participants and never send a comment. Please note that IETF mentioned, Request For Comments= RFC. I commented on the draft, and will only continue commenting on drafts that are edited and monitored by acknowledging IETF participants. > > btw, I remembered that you brought a discussion on RFC Acknowledgement > http://www.ietf.org/mail-archive/web/ietf/current/msg77065.html before. I > didn't follow that thread, but I think other participants have already > explained fairly well how it works. Yes, which I am following, because my input was impact on changes on this draft and I claim impact indirectly on others as to update RFC6130 and other RFCs in MANET WG. > My personal suggestion is that, if you put move attention to the previous > sections of the document(s), rather than acknowledgment section, you would > be naturally listed there - that's how IETF works. > my suggestion is that editors SHOULD not ignore the WG participants input and suggestions. The editors don't control the edit process of WG drafts, it is controled by WG, the editors just follow, represent versions of participants related input and edit. Overall, if the way you do is the true IETF work way then I will know now why many people leave the IETF, because I want IETF WG work as a team in IETF. I would like to change that also if it was true. There is no harm if you acknowledge efforts and inputs, don't know why people like to do that, I always acknowledge my document reviewers, hope that ALL IETF drafts and RFC acknowledges its commenters. If you don't acknowledge why you request for comments, that is strange and not reasonable. Regards Abdussalam Baryun > sincerely > > Jiazi > > On Mar 23, 2013, at 9:17 PM, Abdussalam Baryun <abdussalambar...@gmail.com> > wrote: > >> Hi Jiazi (draft editor) >> >> Please note that I had effort to make below change in this draft, but >> my name is not in acknowledgement as others were. Please add my name. >> I don't think the changes was not influenced by my inputs and >> discussions. I don't think that the changes was to happen if I ignored >> the draft ( i.e. it was in WGLC and not much discussions). I don't >> think I should be discouraged, >> >> Best regards >> Abdussalam Baryun, >> +++++++++++++++++ >> If the IETF culture is to encourage participants then editors SHOULD >> add efforts owners in acknowledgements, otherwise participants MAY be >> discouraged (depends on individual culture). >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> The below message in MANET WG list >> >> On 3/20/13, Jiazi Yi <i...@jiaziyi.com> wrote: >>> Dear all, >>> >>> The authors of nhdp-sec-threats have submitted a new revision based on >>> the >>> comments during WGLC. >>> >>> The only technical change is that, a new sub-section is added on link >>> quality update: >>> >>> ========== >>> 4.8. Attack on Link Quality Update >>> >>> According to NHDP, "Link quality is a mechanism whereby a router MAY >>> take considerations other than message exchange into account for >>> determining when a link is and is not a candidate for being >>> considered as HEARD or SYMMETRIC. As such, it is a link admission >>> mechanism.". >>> >>> Section 14.4 of NHDP [RFC6130] then lists several examples of which >>> information can be used to update link quality. One of the listed >>> examples is to update link quality based on [RFC5444] packet >>> exchanges between neighbor routers, e.g., an NHDP Router may update >>> the link quality of a neighbor based on receipt or loss of packets if >>> they include a sequential packet sequence number. >>> >>> NHDP does not specify how to acquire link quality updates >>> normatively, however, attack vectors may be introduced if an >>> implementation chooses to calculate link quality based on packet >>> sequence numbers. The consequences of such threats would depend on >>> specific implementations. For example, if the link quality update is >>> based on sequential packet sequence number from neighbor routers, a >>> Comprised NDHP Router can spoof packets appearing to be from another >>> Legitimate NHDP Router that skips some packet sequence numbers. The >>> NHDP Router receiving the spoofed packets may degrade the link >>> quality as it appears that several packets have been dropped. >>> Eventually, the router remove the neighbor when the link quality >>> drops below HYST_REJECT. >>> ========== >>> >>> Your comments are welcome. >>> >>> @chairs: >>> I suppose that if this section gets approved, there is no need for >>> another >>> WGLC for the whole document? >>> >>> best >>> >>> Jiazi >>> >>> Begin forwarded message: >>> >>>> From: internet-dra...@ietf.org >>>> Subject: New Version Notification for >>>> draft-ietf-manet-nhdp-sec-threats-02.txt >>>> Date: March 20, 2013 11:43:53 AM GMT+01:00 >>>> To: ji...@jiaziyi.com >>>> Cc: t.clau...@computer.org, ulr...@herberg.name >>>> >>>> >>>> A new version of I-D, draft-ietf-manet-nhdp-sec-threats-02.txt >>>> has been successfully submitted by Jiazi Yi and posted to the >>>> IETF repository. >>>> >>>> Filename: draft-ietf-manet-nhdp-sec-threats >>>> Revision: 02 >>>> Title: Security Threats for NHDP >>>> Creation date: 2013-03-20 >>>> Group: manet >>>> Number of pages: 17 >>>> URL: >>>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-threats-02.txt >>>> Status: >>>> http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats >>>> Htmlized: >>>> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-02 >>>> Diff: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-sec-threats-02 >>>> >>>> Abstract: >>>> This document analyses common security threats of the Neighborhood >>>> Discovery Protocol (NHDP), and describes their potential impacts on >>>> MANET routing protocols using NHDP. >>>> >>>> >>>> >>>> >>>> The IETF Secretariat >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> ma...@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> > >
