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. 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. 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. Last but not least, we acknowledged all the MANET participants - if you regard yourself as one of the participants, then you are acknowledged. 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. 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. sincerely Jiazi On Mar 23, 2013, at 9:17 PM, Abdussalam Baryun <abdussalambaryun@xxxxxxxxx> 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 <ietf@xxxxxxxxxxx> 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-drafts@xxxxxxxx >>> 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: jiazi@xxxxxxxxxxx >>> Cc: t.clausen@xxxxxxxxxxxx, ulrich@xxxxxxxxxxxx >>> >>> >>> 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 >> manet@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/manet >>