Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
The IETF Last Call has finished after 06.06.13 and now you request discussions. I think only IESG can call for discussions not editors. On 6/10/13, Ulrich Herberg ulr...@herberg.name wrote: We have submitted a new revision of the draft, addressing one comment from Adrian during IETF LC (which we wanted to address in the previous revision, but forgot about it). We added a new section that can trigger future work, as requested by Adrian. I don't see that Adrian requested a future work section, could you refer to his input for that or was that private request. May be comments in last call made you think to add missing information as future. What is the reason for future work in this informational draft? To the WG: Obviously, the new text is up for discussion if anyone has any issues with it. Is that a new text or new idea? if I don't know what the Editors discussed privately (outside IETF) how can I discuss inside IETF? However, I will not review any more for this draft because it has special policy for refering to contributions. AB Best regards Ulrich On Thu, May 23, 2013 at 3:22 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
RE: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
We have submitted a new revision of the draft, addressing one comment from Adrian during IETF LC (which we wanted to address in the previous revision, but forgot about it). We added a new section that can trigger future work, as requested by Adrian. I don't see that Adrian requested a future work section, could you refer to his input for that or was that private request. May be comments in last call made you think to add missing information as future. What is the reason for future work in this informational draft? Abdussalam, Look and ye shall see. Seek and ye shall find. http://www.ietf.org/mail-archive/web/manet/current/msg15423.html 2. Please consider adding a short section that may drive new work by suggesting which threats need to be addressed in new protocol work, which in deployment, and which by applications. Adrian
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, As co-editor of this document, I didn't expect the acknowledgement issue can result in such long discussion. I have to repeat that, the decision regarding the acknowledgment section is made following the instructions from rfc 5378 and rfc 2026. We think the facts are: o AB made a lot of comments on this draft. o The comments made didn't have any major impact to the draft. There were *very* few editorial nits discovered by AB, but not technical contribution - not to mention major impact. Therefore, I don't see the need of adding AB to the acknowledgment section. Ulrich (also co-editor) has sent the same opinion to the manet mailing list. There are a few WG participants showed that they agree with our observation. In the meantime, I didn't see any other WG participant support AB's proposal. best Jiazi On Jun 8, 2013, at 07:50 , Abdussalam Baryun abdussalambar...@gmail.com wrote: Dear Routing Area AD, I had many comments/issues regarding your area always addressed to you and including this issue which I hope my all comments (past/present) will help to make better practice/procedural progresses in this IETF Area. I am sorry also to any one receiving this email but I send it only to an AD, IETF, and IESG. This is not noise but a signal to IETF to progress, if you think it is noise please explain, and please notice that all particpants have rights under the IETF procedures not only managements. My reply below and if you want to continue discussing on any other list please inform me, but if you reply copying any list, I will have to do the same because you are part of management and I am not. On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: Sorry to everyone for the noise this thread is creating. This thread containing my messages never creates noise, I beleive you may ne refering to your messages only as noise. Please note that I don't accept this describtion, I think that community messages regarding any I-D is never noise even if the IETF management could not handle the volume. I RECOMMEND any receiver that has noise in it to fix its problem without blaming transmitters. Multiple questions that I have to answer. ok, that is why this list is discussing list for ietf progress, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Are you asking whether there was an explicit consensus call within the working group on whether or not you should be acknowledged in this document? I think the question is clear, and is easy to answer. The answer is, there was no decision made by the WG or the community regarding my request of adding a name in the ack section. You send me back a question saying explicit consensus, it is simpler to make my question asking of notification of such reaction from management, which was not either established. I did not get a message saying that any kind of consensus was established privately/publicly on any IETF lists (please ask the WG chair because I am sure I did not received any answer for my request by the WG/community). There was no such call in the working group or on the IETF list. Thanks for the answer, so I understand that the editors/management did not answer my request (one person from the community), just because they or AD did not beleive in my concerns without consulting the WG in any way. Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. This opinion does not apply to your comments on this document. You did not discover a wrong technical-idea. Your comments did not lead directly to the addition of any new technical-idea. The question of I-D managers not acknowledging such input/contribution, was not answered if you agree to acknowledge discovering an error or adding a new idea. Regarding the opinion, do you agree with the opinion first? Regarding the error and missing information, I did discover error in the document and did found missing definitions if this informational I-D (after my contribution there was changes made to the document, please notice that) I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? That person is you. Yes but I said that because this message it not me defending me, it is me defending future
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
We have submitted a new revision of the draft, addressing one comment from Adrian during IETF LC (which we wanted to address in the previous revision, but forgot about it). We added a new section that can trigger future work, as requested by Adrian. To the WG: Obviously, the new text is up for discussion if anyone has any issues with it. Best regards Ulrich On Thu, May 23, 2013 at 3:22 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
AB, This may surprise you, but not everyone cares what you think. John Sent from my iPhone On Jun 8, 2013, at 1:51 AM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Dear Routing Area AD, I had many comments/issues regarding your area always addressed to you and including this issue which I hope my all comments (past/present) will help to make better practice/procedural progresses in this IETF Area. I am sorry also to any one receiving this email but I send it only to an AD, IETF, and IESG. This is not noise but a signal to IETF to progress, if you think it is noise please explain, and please notice that all particpants have rights under the IETF procedures not only managements. My reply below and if you want to continue discussing on any other list please inform me, but if you reply copying any list, I will have to do the same because you are part of management and I am not. On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: Sorry to everyone for the noise this thread is creating. This thread containing my messages never creates noise, I beleive you may ne refering to your messages only as noise. Please note that I don't accept this describtion, I think that community messages regarding any I-D is never noise even if the IETF management could not handle the volume. I RECOMMEND any receiver that has noise in it to fix its problem without blaming transmitters. Multiple questions that I have to answer. ok, that is why this list is discussing list for ietf progress, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Are you asking whether there was an explicit consensus call within the working group on whether or not you should be acknowledged in this document? I think the question is clear, and is easy to answer. The answer is, there was no decision made by the WG or the community regarding my request of adding a name in the ack section. You send me back a question saying explicit consensus, it is simpler to make my question asking of notification of such reaction from management, which was not either established. I did not get a message saying that any kind of consensus was established privately/publicly on any IETF lists (please ask the WG chair because I am sure I did not received any answer for my request by the WG/community). There was no such call in the working group or on the IETF list. Thanks for the answer, so I understand that the editors/management did not answer my request (one person from the community), just because they or AD did not beleive in my concerns without consulting the WG in any way. Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. This opinion does not apply to your comments on this document. You did not discover a wrong technical-idea. Your comments did not lead directly to the addition of any new technical-idea. The question of I-D managers not acknowledging such input/contribution, was not answered if you agree to acknowledge discovering an error or adding a new idea. Regarding the opinion, do you agree with the opinion first? Regarding the error and missing information, I did discover error in the document and did found missing definitions if this informational I-D (after my contribution there was changes made to the document, please notice that) I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? That person is you. Yes but I said that because this message it not me defending me, it is me defending future wrong reaction of ignoring to acknowledge the persons in the community. If any I-D authors are best knowledgeable people in a special field they should not try to seek to dis-acknowledge the community efforts that changed few I-D ideas (even if the community person is not expert, that does not mean that authors have right to exclude contributors). Yes, you made a review. Reviewing a document is not something authors acknowledge in the IETF or (AFAIK) in academic journals. I disagree with your opinion, but do you think your opinion is in the IETF procedure, if yes please provide me with that procedure of not acknowledgement. I respect your opinion but it is wrong because in one sense yes documents in the world don't acknowledge all
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Dear Routing Area AD, I had many comments/issues regarding your area always addressed to you and including this issue which I hope my all comments (past/present) will help to make better practice/procedural progresses in this IETF Area. I am sorry also to any one receiving this email but I send it only to an AD, IETF, and IESG. This is not noise but a signal to IETF to progress, if you think it is noise please explain, and please notice that all particpants have rights under the IETF procedures not only managements. My reply below and if you want to continue discussing on any other list please inform me, but if you reply copying any list, I will have to do the same because you are part of management and I am not. On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: Sorry to everyone for the noise this thread is creating. This thread containing my messages never creates noise, I beleive you may ne refering to your messages only as noise. Please note that I don't accept this describtion, I think that community messages regarding any I-D is never noise even if the IETF management could not handle the volume. I RECOMMEND any receiver that has noise in it to fix its problem without blaming transmitters. Multiple questions that I have to answer. ok, that is why this list is discussing list for ietf progress, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Are you asking whether there was an explicit consensus call within the working group on whether or not you should be acknowledged in this document? I think the question is clear, and is easy to answer. The answer is, there was no decision made by the WG or the community regarding my request of adding a name in the ack section. You send me back a question saying explicit consensus, it is simpler to make my question asking of notification of such reaction from management, which was not either established. I did not get a message saying that any kind of consensus was established privately/publicly on any IETF lists (please ask the WG chair because I am sure I did not received any answer for my request by the WG/community). There was no such call in the working group or on the IETF list. Thanks for the answer, so I understand that the editors/management did not answer my request (one person from the community), just because they or AD did not beleive in my concerns without consulting the WG in any way. Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. This opinion does not apply to your comments on this document. You did not discover a wrong technical-idea. Your comments did not lead directly to the addition of any new technical-idea. The question of I-D managers not acknowledging such input/contribution, was not answered if you agree to acknowledge discovering an error or adding a new idea. Regarding the opinion, do you agree with the opinion first? Regarding the error and missing information, I did discover error in the document and did found missing definitions if this informational I-D (after my contribution there was changes made to the document, please notice that) I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? That person is you. Yes but I said that because this message it not me defending me, it is me defending future wrong reaction of ignoring to acknowledge the persons in the community. If any I-D authors are best knowledgeable people in a special field they should not try to seek to dis-acknowledge the community efforts that changed few I-D ideas (even if the community person is not expert, that does not mean that authors have right to exclude contributors). Yes, you made a review. Reviewing a document is not something authors acknowledge in the IETF or (AFAIK) in academic journals. I disagree with your opinion, but do you think your opinion is in the IETF procedure, if yes please provide me with that procedure of not acknowledgement. I respect your opinion but it is wrong because in one sense yes documents in the world don't acknowledge all reviews (usually when they don't request it), one the other hand the world documents do acknowledge reviews when the document owner calls for review. Please note that this I-D did request/call for review and I was the only reveiwer in the
RE: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. I also believe that the comments he made did not advance the content of the document. Furthermore, per multiple references (such as RFC 2026) the Acknowledgements section is used to properly acknowledge major contributors. Normal IETF business is to discuss not seek acknowledgement. I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. The authors have posted a revised I-D handling other IETF last call issues, and I will advance that to IESG evaluation. Thanks, Adrian From: Abdussalam Baryun [mailto:abdussalambar...@gmail.com] Sent: 03 June 2013 17:10 To: ietf Cc: adr...@olddog.co.uk; i...@ietf.org Subject: Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC I would hope that IETF add my name in the acknowledgement section of the I-D. I complained to AD about that my efforts in WGLC was not acknowledged by editors even after my request, however, I did not stop reviewing (trying not be discouraged) which I will complete on 6 June with the final comments. Therefore, this message (can be added as a comment on the I-D) is an objection to section 8 that ignores acknowledge input/review effort related to the I-D. AB On Mon, Jun 3, 2013 at 6:35 AM, Ulrich Herberg ulr...@herberg.name wrote: Hi Adrian, I personally agree that adding an informational ref to draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my co-authors. Thanks Ulrich On Sunday, June 2, 2013, Adrian Farrel wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. Thanks, Adrian I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
Re: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: Hi, It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? Why don't you consider discovering an error as a contribution? Why don't you consider providing new ideas a contribution? What is your definition to contribution? I also believe that the comments he made did not advance the content of the document. So I understand that you need to have advance the content then you acknowledge. Furthermore, per multiple references (such as RFC 2026) the Acknowledgements section is used to properly acknowledge major contributors. I am trying to find that condition of *major contribution*, Normal IETF business is to discuss not seek acknowledgement. Ideas, Comments and reviews are included in the discuss for drafts progress. Seeking acknowledgement is not wrong within IETF, but please consider *not acknowledging reviews* within IETF documents is not IETF culture (we are not paid so why you thinking much of the business, the IETF business will only progress with acknowledging the volunteers). I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. IMO, it should have been done in the WG. AB From: Abdussalam Baryun [mailto:abdussalambar...@gmail.com] Sent: 03 June 2013 17:10 To: ietf Cc: adr...@olddog.co.uk; i...@ietf.org Subject: Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC I would hope that IETF add my name in the acknowledgement section of the I-D. I complained to AD about that my efforts in WGLC was not acknowledged by editors even after my request, however, I did not stop reviewing (trying not be discouraged) which I will complete on 6 June with the final comments. Therefore, this message (can be added as a comment on the I-D) is an objection to section 8 that ignores acknowledge input/review effort related to the I-D. AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats* Reading the RFC6130 applicability section 3, the I-D does not consider all the use-cases included in the that section 3. AB Does the use-case of NHDP [RFC6130] add any value to the threats, or the I-D assumes only one use case which is OLSRv2 network. The NHDP uses RFC5444 packets and RFC5444 messages, so what are the threats to NHDP use for each? not mentioned in I-D. RFC6130 NHDP Can use relevant link-layer information if it is available. AB is there any threat from that use-case? not mentioned in the I-D. *Information bases threats* RFC6130 Appendix F This appendix illustrates various examples of physical topologies, as well as how these are logically recorded by NHDP from the point of view of the router A. This representation is a composite of information that would be contained within A’s various Information Bases after NHDP has been running for sufficiently long time for the state to converge. AB Why the logically recording of the NHDP for all the examples not mentioned in the I-D and were not threat analysed? If there is similar level of threats related to all exampels in RFC6130, then please mention that. This is my last message, thanks. Regards AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
AB, while the IETF LC has already ended, I will reply to your comments below: On Thu, Jun 6, 2013 at 1:33 PM, Abdussalam Baryun abdussalambar...@gmail.com wrote: Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats* Reading the RFC6130 applicability section 3, the I-D does not consider all the use-cases included in the that section 3. AB Does the use-case of NHDP [RFC6130] add any value to the threats, or the I-D assumes only one use case which is OLSRv2 network. I don't understand the question. The use case is a MANET running NHDP. Section 5 in addition outlines consequences of security threats to NHDP for protocols using the information from NHDP. The NHDP uses RFC5444 packets and RFC5444 messages, so what are the threats to NHDP use for each? not mentioned in I-D. I don't understand the question. There is no danger from a message or packet itself; they may contain information that has either been legitimately tampered with or that is wrong because of misconfiguration. And these are the cases we have described. RFC6130 NHDP Can use relevant link-layer information if it is available. AB is there any threat from that use-case? not mentioned in the I-D. After discussion on the MANET mailing list, this was already added in section 4.8 (even though the link quality itself is not a normative part of RFC6130, the authors agreed to add that section). *Information bases threats* RFC6130 Appendix F This appendix illustrates various examples of physical topologies, as well as how these are logically recorded by NHDP from the point of view of the router A. This representation is a composite of information that would be contained within A’s various Information Bases after NHDP has been running for sufficiently long time for the state to converge. AB Why the logically recording of the NHDP for all the examples not mentioned in the I-D and were not threat analysed? If there is similar level of threats related to all exampels in RFC6130, then please mention that. I don't understand the question. The example in RFC6130 simply illustrates how NHDP would perceive and store several sample topologies. How would that represent a level of threat? The I-D describes several security threats and explains in which situations these could occur (and what effect it would have). That could happen in an infinite amount of different topologies, so it is impossible (and useless) to list all topologies where such attacks could occur. Best regards Ulrich
RE: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
I find it somewhat disruptive that this email raises new questions on a draft authored in a working group in which you participate, and that it has arrived after the end of IETF last call. I see a series of questions in this message, but no suggested textual changes. I therefore conclude that you are requesting no changes and none shall be made. Thank you. Adrian Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats*
RE: Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Sorry to everyone for the noise this thread is creating. Multiple questions that I have to answer. It falls to me to make a call on this issue before the document moves on. Abdussalam has complained that he has not been acknowledged and has objected to the current text in section 8. The authors have responded on the MANET list We believe that only comments that lead to significant improvements of the draft deserve a listing in the acknowledgment section, and we have therefore not modified the section. What was the WG decision? Are you asking whether there was an explicit consensus call within the working group on whether or not you should be acknowledged in this document? There was no such call in the working group or on the IETF list. Why any contribution that influnces the I-D ideas is not acknowledged? IMO, if a technical-idea within the I-D was discovered wrong by a participant, or a new technical-idea added to I-D from an input, then the I-D should be acknowledged. This opinion does not apply to your comments on this document. You did not discover a wrong technical-idea. Your comments did not lead directly to the addition of any new technical-idea. I have reviewed the email threads on the MANET mailing list and do not consider that Abdussalam made contributions to the text of the document. Didn't that person make review and discovered errors? That person is you. Yes, you made a review. Reviewing a document is not something authors acknowledge in the IETF or (AFAIK) in academic journals. No, I don't think you discovered errors of any significance. Caveating my answers below as describing a contribution to a document (not a contribution in the wider IETF sense) Why don't you consider discovering an error as a contribution? I would personally consider discovering a major error as something I would acknowledge it in a document I was editing. I would personally consider discovering multiple minor errors as something I would acknowledge it in a document I was editing. However, there is no requirement for editors to act in that way. Furthermore, you do not fit into these categories for this document. Why don't you consider providing new ideas a contribution? I would consider providing major ideas as something I would acknowledge it in a document I was editing. I would consider providing smaller ideas through text for inclusion in the document as something I would acknowledge it in a document I was editing. You do not fit into these categories for this document. What is your definition to contribution? As above, or written text that was included or modified for inclusion in a document and represents a material or substantial part of the document. I also believe that the comments he made did not advance the content of the document. So I understand that you need to have advance the content then you acknowledge. Furthermore, per multiple references (such as RFC 2026) the Acknowledgements section is used to properly acknowledge major contributors. I am trying to find that condition of *major contribution*, I would borrow from 2026 and 5378 to say a material or substantial contribution to the document. And, before you ask, no-one is going to write down a rule that says 139 characters is not substantial, but 140 is. This is one of the places where a principal of reasonableness applies. I would know a major contribution if I saw one. I did not see one from you in this case. Normal IETF business is to discuss not seek acknowledgement. Ideas, Comments and reviews are included in the discuss for drafts progress. Seeking acknowledgement is not wrong within IETF, but please consider *not acknowledging reviews* within IETF documents is not IETF culture (we are not paid so why you thinking much of the business, the IETF business will only progress with acknowledging the volunteers). If you want to change the way that the IETF participants (and document authors/editors in particular) acknowledge reviews of their documents, then please start a separate thread or, better still, write an I-D and see whether you can gain consensus. The last time you brought this topic up on this list, I do not recall seeing support. The only reason I can find for someone being able to demand that they are named in an Acknowledgements Section is for conformance to the IETF's Rights policies. I do not propose to do an explicit consensus call on whether Abdussalam should be named in this draft. IMO, it should have been done in the WG. Thank you for your opinion. Are you asserting that consensus on the readiness of this document for a publication request was incorrectly called by the working group chairs. This would be a serious allegation against the chairs and I would require evidence that there had been no consensus or that they had made an incorrect assessment of the consensus. Thank you, Adrian
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
I received an IESG message asking my comments so I gave it, regard to your comments below, the reply is that I refer to missing information needed in the I-D, so the reveiw suggests that there is something missing. Did not suggested text because I know that it most probably not be considered. The Last call ends by 06.06.2013 so I still am in this date, not sure why you close, AB On 6/6/13, Adrian Farrel adr...@olddog.co.uk wrote: I find it somewhat disruptive that this email raises new questions on a draft authored in a working group in which you participate, and that it has arrived after the end of IETF last call. I see a series of questions in this message, but no suggested textual changes. I therefore conclude that you are requesting no changes and none shall be made. Thank you. Adrian Reply to your request dated 24/05/2013 I-D: draft-ietf-manet-nhdp-sec-threats-03 Draft Reviewed By: Abdussalam Baryun (AB)Dated:06/06/2013 Reviewer Comment A3: Use Cases not considered and the Information Bases Threats. +++ *Use-cases threats*
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, I think it's OK to add an informative reference to draft-ietf-nhdp-olsrv2-sec, which serves as a pointer to the related work going on, and possible countermeasures to the threats. best Jiazi On Jun 3, 2013, at 07:35 , Ulrich Herberg ulr...@herberg.name wrote: Hi Adrian, I personally agree that adding an informational ref to draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my co-authors. Thanks Ulrich On Sunday, June 2, 2013, Adrian Farrel wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. Thanks, Adrian I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
I would hope that IETF add my name in the acknowledgement section of the I-D. I complained to AD about that my efforts in WGLC was not acknowledged by editors even after my request, however, I did not stop reviewing (trying not be discouraged) which I will complete on 6 June with the final comments. Therefore, this message (can be added as a comment on the I-D) is an objection to section 8 that ignores acknowledge input/review effort related to the I-D. AB On Mon, Jun 3, 2013 at 6:35 AM, Ulrich Herberg ulr...@herberg.name wrote: Hi Adrian, I personally agree that adding an informational ref to draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my co-authors. Thanks Ulrich On Sunday, June 2, 2013, Adrian Farrel wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. Thanks, Adrian I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
RE: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. Thanks, Adrian I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi Adrian My comments below, On 6/2/13, Adrian Farrel adr...@olddog.co.uk wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. So I understand you agree with my suggestion on this I-D to referencing/refering to that draft [1]. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. I think the work completes when the WG submits to AD, but reviews not completed. IMHO, the draft/work [1] is completed from WGLC, and now is at AD review. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. I suggest the I-D referencing. I do not think I suggested way of reviews, but that other satetment was my opinion/beleive or advise to community of such reveiw for output quality. I don't understand why you think it was wrong way of review, after you agreed to reference such document (usually my reviewing reviews all references as well). Regards AB I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi Adrian, I personally agree that adding an informational ref to draft-ietf-manet-nhdp-olsrv2-sec is a good idea. I will discuss with my co-authors. Thanks Ulrich On Sunday, June 2, 2013, Adrian Farrel wrote: Hi Abdussalam, I think it is a reasonable suggestion for this I-D to make a forward reference to draft-ietf-manet-nhdp-olsrv2-sec Although this work is clearly scoped to NHDP (RFC 6130) as currently specified, it is worth an informational reference to note that there is work in progress that seeks to update NHDP to counter a number of security threats described in this document. I do not think, however, that this I-D should attempt to describe the situation with NHDP after the inclusion of protocol work that has not yet been completed. Contrary to your suggestion, I think this I-D motivates updates to 6130 and it would be wrong to review this document in the context of changes being made to address this document. Thanks, Adrian I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Continue Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:02/06/2013 Reviewed I-D: draft-ietf-manet-nhdp-sec-threats-03 Reviewer Comment A2: Referencing the NHDP and related to RFC6130 ++ I think if we got an effort in IETF to update NHDP [RFC6130] as draft [1] does, why this reviewed I-D of threats does not include [1] in its references to be reviewed before reviewing this NHDP-threat I-D? I suggest to include draft [1] in References section, IMHO, any updates to RFC6130 should be considered by the community while reviewing this I-D. [1] draft-ietf-manet-nhdp-olsrv2-sec-02 AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, I think those comments have been addressed/answered in my previous reply http://www.ietf.org/mail-archive/web/manet/current/msg15274.html I didn't see the support of your comments from other WG participants. best Jiazi 2013/5/27 Abdussalam Baryun abdussalambar...@gmail.com Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:27/05/2013 Reviewer Comment A1: Previous comments in WGLC +++ Related to your request below please read my previous review comments [1] and I will continue with additional messages/comments. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:27/05/2013 Reviewer Comment A1: Previous comments in WGLC +++ Related to your request below please read my previous review comments [1] and I will continue with additional messages/comments. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
Hi, Reviews at this stage don't need supports from WG when it is in the IETF Last Call, the comments are sent as per request of iesg. AB On 5/27/13, Jiazi YI yi.ji...@gmail.com wrote: Hi, I think those comments have been addressed/answered in my previous reply http://www.ietf.org/mail-archive/web/manet/current/msg15274.html I didn't see the support of your comments from other WG participants. best Jiazi 2013/5/27 Abdussalam Baryun abdussalambar...@gmail.com Reply to your request dated 24/05/2013 Draft Reviewed By: Abdussalam Baryun (AB)Dated:27/05/2013 Reviewer Comment A1: Previous comments in WGLC +++ Related to your request below please read my previous review comments [1] and I will continue with additional messages/comments. [1] http://www.ietf.org/mail-archive/web/manet/current/msg15254.html Regards AB On 5/24/13, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D. ___ manet mailing list ma...@ietf.org https://www.ietf.org/mailman/listinfo/manet
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
On 5/27/13, Jiazi YI yi.ji...@gmail.com wrote: Hi, I think those comments have been addressed/answered in my previous reply http://www.ietf.org/mail-archive/web/manet/current/msg15274.html I didn't see the support of your comments from other WG participants. I also didn't see objection of my comments from the WG. I also didn't see support of your reply from the WG. (WG decisions are WG-rough-consensus, not the editors opinion). If there was WG objection then I will report that in my reviews to IESG as information. AB
Re: [manet] Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
On 5/27/13 10:39 AM, Abdussalam Baryun wrote: I also didn't see objection of my comments from the WG. I also didn't see support of your reply from the WG. (WG decisions are WG-rough-consensus, not the editors opinion). Chairs call consensus.
Last Call: draft-ietf-manet-nhdp-sec-threats-03.txt (Security Threats for NHDP) to Informational RFC
The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Security Threats for NHDP' draft-ietf-manet-nhdp-sec-threats-03.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-06-06. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec-threats/ballot/ No IPR declarations have been submitted directly on this I-D.
