Subject: [manet] New AODVv2 draft and status

From: Justin Dean <[email-masked]>
Date: Wed, 20 Apr 2016 13:50:50 -0400

As Thomas has noted the status has changed to experimental.  You beat the
authors to the punch in noticing that before they posted up an overview
email.  In short, we, the working group are out of time. It's now time to
finish this document.  Not all open issues (ones brought up today or not
decided upon) metrics, security, and a few others have not been
incorporated into this updated draft.  Regardless we are out of time and we
need to move on to other work specifically having a new charter finished
and approved before the next IETF.

So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status
change, updates to the draft, and my review, and continued intense work
from the editorship team and the working group there is a chance of
success.  The working group will have 2 weeks to provide input at which
time I'll make the call to pass it on up to the IESG or remove it as a WG
item and hand it back to the authors to do with it what they will.

Due to the short timeline we will also need to discuss and come to
consensus on a new WG charter. I'll start that in another email thread.

Justin

p.s. I'm looking forward to continued positive discussions and
improvements.  AODVv2 I STRONGLY encourage you to use (almost exclusively
to the extent possible) the MANET list for all future AODVv2 discussions
within this last call period.

---

From: [email-masked]
Date: Wed, 20 Apr 2016 20:10:29 +0200

Justin,

> On Apr 20, 2016, at 19:50, Justin Dean <[email-masked]> wrote:
> 
> As Thomas has noted the status has changed to experimental.  You beat the authors to the punch in noticing that before they posted up an overview email.  In short, we, the working group are out of time. It's now time to finish this document.  Not all open issues (ones brought up today or not decided upon) metrics, security, and a few others have not been incorporated into this updated draft.  Regardless we are out of time and we need to move on to other work specifically having a new charter finished and approved before the next IETF. 
> 
> So, I'll be issuing a 2 week WGLC on AODVv2.  Given the intended status change, updates to the draft, and my review, and continued intense work from the editorship team and the working group there is a chance of success.  The working group will have 2 weeks to provide input at which time I'll make the call to pass it on up to the IESG or remove it as a WG item and hand it back to the authors to do with it what they will.

What the heck? A WGLC is simply inappropriate at this stage, for reasons including the following:

	o	There were core algorithmic changes between -14 and -15 (message processing, …) 
		that have not been discussed,  let alone not reviewed (multicast processing, for example) 
		on the list.

	o	There are *many* unresolved issues in this document (I just did a quick RFCdiff), despite
		the changes between -14 and -15, and discussion of some of these is ongoing on the list.
		None of those issues are new, but have been raised in the far past, on the list …

	o	The document is 78 pages long.

Those three combined means that the document should not be WGLCed, certainly not with only a 2 week lead time, at this juncture.

Best,

Thomas

> Due to the short timeline we will also need to discuss and come to consensus on a new WG charter. I'll start that in another email thread.
> 
> Justin
> 
> p.s. I'm looking forward to continued positive discussions and improvements.  AODVv2 I STRONGLY encourage you to use (almost exclusively to the extent possible) the MANET list for all future AODVv2 discussions within this last call period.

---

From: Justin Dean <[email-masked]>
Date: Wed, 20 Apr 2016 14:17:36 -0400

We are out of time.  This WGLC is the final 2 weeks one way or another.
You're comments are valid and understood we just don't have any more time.
How things go depends on the working group and the editorship team.  WGLC
doesn't mean that the draft is finished, it's a means for the chair to
explicitly poll the WG when I feel a document has a chance to find
consensus.  Also, we are out of time.

Justin

On Wed, Apr 20, 2016 at 2:10 PM, <[email-masked]> wrote:

> > As Thomas has noted the status has changed to experimental.  You beat
> the authors to the punch in noticing that before they posted up an overview
> Those three combined means that the document should not be WGLCed,
> certainly not with only a 2 week lead time, at this juncture.
>
> Best,
>
> Thomas
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 20 Apr 2016 19:36:35 +0100

This is the cart before the horse. I'm pretty sure every IETF guideline says get the document right, not rush to a deadline.

Is the document right? I don't know. It would be hard enough with a more usual four week deadline (even 5444 usage, a much simpler document, got three) and had the authors been engaging here. As it is, they have persistently declined do do so except on a few points when pushed. Despite continual requests and appeals to the WG chair to make that happen. And the authors have been making functional changes right up to now. To expect the WG to give a reasoned view of the document in two weeks, even at experimental status, is just not going to be possible. Document shepherd, when appointed, please note.

Incidentally - and obviously I haven't read the draft (and right now I'm not committing to do so in the timescale) - the last draft I was an author of that left the WG in experimental state, there was a requirement to add a description of the experiment. (It actually made experimental harder work than standards track in material to write.) But whether that will be required here, no idea.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 20 Apr 2016, at 18:50, Justin Dean <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Justin Dean <[email-masked]>
Date: Wed, 20 Apr 2016 14:51:25 -0400

On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <
[email-masked]> wrote:

> This is the cart before the horse. I'm pretty sure every IETF guideline
> says get the document right, not rush to a deadline.
>
> 10+ years isn't rushing.

> Is the document right? I don't know. It would be hard enough with a more
> usual four week deadline (even 5444 usage, a much simpler document, got
> three) and had the authors been engaging here. As it is, they have
> persistently declined do do so except on a few points when pushed. Despite
> continual requests and appeals to the WG chair to make that happen. And the
> authors have been making functional changes right up to now. To expect the
> WG to give a reasoned view of the document in two weeks, even at
> experimental status, is just not going to be possible. Document shepherd,
> when appointed, please note.
>
> As for the maturity of the document there was some helpful and useful
discussions this morning before the new draft was released so issues
remain.  I hope those discussions continue and consensus reached on
appropriate fixes.  That being said I did give a pretty indepth review and
while I found numerous issues many of them have been addressed in the newer
draft.  Do I think it's perfect?  Nope but I do think it's approaching the
levels seen in other ietf documents.
Shepherd will be sure to note the objections to issuing of WGLC and the
timeline provided by multiple WG members;  If the document gets there, I'll
still need consensus even if rough from the WG before I'll pass it along.

I'd much rather spend our remaining time on technical issues.

Justin

Incidentally - and obviously I haven't read the draft (and right now I'm
> not committing to do so in the timescale) - the last draft I was an author
> of that left the WG in experimental state, there was a requirement to add a
> description of the experiment. (It actually made experimental harder work
> than standards track in material to write.) But whether that will be
> required here, no idea.
>
> --
> Christopher Dearlove

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 20 Apr 2016 20:54:12 +0200

Justin, all

You are asking the WG to do in two weeks, what the authors have just not done in 3 (or, to be fair, more like 10...) years: discuss the document on the [email-masked] list, and resolve all issues - issues, which you know exist, because they have been raised on the list....for, if not 10 years, then at the least 4-5 years.

Except, the WG gets two weeks to do so. 

If you (as chair) feel the document is not right, pull it. 
If you (as chair) in the past have felt it wasn't going in the right decision, you could have stepped on the authors earlier, or replaced them, or spoken to your AD, or to the WG, or something else.

But to expect the WG to resolve this document in 2 weeks, after having been kept in the dark (apparently the document was discussed in some other, closed, forum -- with the WG chairs knowledge) for years, is simply not reasonable, and is simply not possible.

I believe, in fact, it would give cause for an appeal. Document shepherd, if/when appointed, take notice.

Thomas

> On 20 Apr 2016, at 20:17, Justin Dean <[email-masked]> wrote:
> 
> We are out of time.  This WGLC is the final 2 weeks one way or another.  You're comments are valid and understood we just don't have any more time.  How things go depends on the working group and the editorship team.  WGLC doesn't mean that the draft is finished, it's a means for the chair to explicitly poll the WG when I feel a document has a chance to find consensus.  Also, we are out of time.
> 
> Justin
>

---

From: Justin Dean <[email-masked]>
Date: Wed, 20 Apr 2016 15:08:53 -0400

On Wed, Apr 20, 2016 at 3:06 PM, Christopher Dearlove <
[email-masked]> wrote:

> No, ten years isn't rushing. Two weeks is.
>
> It's clear you've made a decision. I disagree with it, but I'm not
> expecting to change it. If I have any input in that time, I'll let you have
> it. Or that I haven't been able to. I've made my observations at this
> point, I'll make anything else technical I come across, and I'll let the
> system handle it. But my experience makes me predict a rough road ahead.
>
> Thank you.

Justin

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 20 Apr 2016 21:08:56 +0200

Justin,

> On 20 Apr 2016, at 20:51, Justin Dean <[email-masked]> wrote:
> 
> 
>> On Wed, Apr 20, 2016 at 2:36 PM, Christopher Dearlove <[email-masked]> wrote:

<SNIP>

> I'd much rather spend our remaining time on technical issues.

Sorry, no.

The authors having, for 10+ years (as you note yourself), not been discussing technical issues with the WG, but in a private forum apparently with your knowledge/blessing, and the successive WG chairs (you included) having let them get away with it means, that when *you* issue a WGLC under these conditions, you do get to discuss those process issues.

Thomas

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 20 Apr 2016 20:10:11 +0100

I'm a step back from that. I expect, if we get there, the document shepherd to note however many people express dissatisfaction with the timescale (and aspects of process) but that's as far as I'm going to take it. (At standards track would have been a different issue.)

> On 20 Apr 2016, at 19:54, Thomas Clausen <[email-masked]> wrote:
> 
> Justin, all
>

---

From: Justin Dean <[email-masked]>
Date: Wed, 20 Apr 2016 15:20:29 -0400

On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen <[email-masked]>
wrote:

> The authors having, for 10+ years (as you note yourself), not been
> discussing technical issues with the WG, but in a private forum apparently
> with your knowledge/blessing, and the successive WG chairs (you included)
> having let them get away with it means, that when *you* issue a WGLC under
> these conditions, you do get to discuss those process issues.
>
> Thomas
>

Technical discussions have been had on this list as was happening this
morning. Any many times in the past.  Yes there is a list the AODVv2 team
uses.  Yes I am aware of that list.  I can ask them to shut it down but
they could just communicate in another way without my knowledge if they so
choose.  I don't follow that list actively only to monitor amount of
activity but you've no way of of knowing that's true so point taken.  I
have repeatedly asked them to use THIS list more.  In this we are in
agreement.

Justin

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 20 Apr 2016 15:24:06 -0400

> these conditions, you do get to discuss those process issues.
Once again, we're plowing ground that's already been plowed, and is a
complete red herring. It's been discussed on this list already - the
authors were *not* engaged in a "private kabal", but in discussions amongst
themselves as to how to address issues. We've said before that perhaps this
strayed into being too closed - but to continue to bash over it is silly.
To attempt to blow it up into something more is to edge closer and closer
to "conspiracy theory" territory.

Stan

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 20 Apr 2016 21:46:58 +0200

> On 20 Apr 2016, at 21:20, Justin Dean <[email-masked]> wrote:
> 
> 
>> On Wed, Apr 20, 2016 at 3:08 PM, Thomas Clausen <[email-masked]> wrote:
>> Justin,
>> 
> Technical discussions have been had on this list as was happening this morning. Any many times in the past. 
> Yes there is a list the AODVv2 team uses.  Yes I am aware of that list.  I can ask them to shut it down but they could just communicate in another way without my knowledge if they so choose.

On the above, no, you are wrong. As WG chair, you can do much more than throw up your arms in despair, and then watch the train-wreck unfold.

For example, you instruct the authors to communicate and discuss issues on the WG list, openly. If they don't (regardless of if they discuss on another list, which you are on, or not) then as WG chair you say:

	Guys, this is a WG document. You are not developing this document within the WG,
	despite my instructions. Thank you for your effort, you are hereby replaced by 
	Pierre, Paul and Pascale, as authors.

Since I am not on that "secret list", I do not know - but you presumably do. Outside of these process issues, have AODVv2 protocol design and  document editing issues been, in majority, discussed on the "secret list" or on the MANET list?

In the past, there have been reviews posted to this document and its predecessor, on the Manet list, which were ignored for months, years, and even demi-decades.

Issues and reviews have been brought up, the resolutions of which have not been discussed on the Manet list, but rather the authors have dumped a monolithic "here's a new version" without explanation, on the Manet list.

Rather than discussing with the WG on the Manet list, e.g., regarding 5444-usage, metrics, security, ..., the authors of this document have been working in a private forum, often on misunderstandings.

And, various WG participants have been asking, begging, insisting that things should not be discussed in private, to no avail.

All this adds up to "a non IETF protocol, brought in for publication as an RFC" - which is what the Independent Stream or AD sponsorship (if IETF review is desired) is for. 

WGLCing this document is not appropriate.

Thomas

>   I don't follow that list actively only to monitor amount of activity but you've no way of of knowing that's true so point taken.  I have repeatedly asked them to use THIS list more.  In this we are in agreement.

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 20 Apr 2016 21:52:42 +0200

> On 20 Apr 2016, at 21:24, Stan Ratliff <[email-masked]> wrote:
> 
> 
> 
> Once again, we're plowing ground that's already been plowed, and is a complete red herring. It's been discussed on this list already - the authors were *not* engaged in a "private kabal", but in discussions amongst themselves as to how to address issues. We've said before that perhaps this strayed into being too closed - but to continue to bash over it is silly. To attempt to blow it up into something more is to edge closer and closer to "conspiracy theory" territory. 
> 

I'll ignore the condescending tone of your email, but simply say:

If  you indeed were not engaged in a "private kabal", but wanted to do the right thing then why didn't you just when this was (quoting you) "discussed on the list already", say:

	"oops, sorry, we're shutting the private list and taking all that public - now." 

Nobody *forced* you to keep developing this protocol out-of-view of the public and out-of-view of the IETF.

Thomas

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 20 Apr 2016 20:28:49 +0000

On 4/20/16, 1:50 PM, "manet on behalf of Justin Dean" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi!

Regardless we are out of time and we need to move on to other work specifically having a new charter finished and approved before the next IETF.

Justin has mentioned several times that "we are out of time".  I think it is important for me to expand on what he means (or at least what I have talked to the Chairs about).

As all of you know, AODVv2 is the last piece of work that the WG needs to clear before moving on to new topics.  While the current draft was adopted by the WG in 2013, the original draft (draft-ietf-manet-dymo) was first published in 2005.  There have been ups and downs in the interest of the WG and the speed at which the authors produce updates and address comments.  The WG has considered alternatives and has even seen "lines in the sand" drawn and then taken over by time…

I'm not interested in revisiting the decisions made in the past…  The current facts are that the WG has been involved in discussions around AODVv2 for at least the last year (when I became the responsible AD) and that we don't seem to be significantly closer than we were then to moving on [*].  This situation has heavily contributed to the WG not meeting for two IETF cycles.

It has become painfully clear to me that the WG may not be able to complete the work it has been chartered with [*].  According to rfc2418 [1], if "…it becomes evident that a working group is unable to complete the work outlined in the charter, …the working group can either:

   1. Recharter to refocus its tasks,
   2. Choose new Chair(s), or
   3. Disband."

I don't believe that at this point changing the Chairs would help [*].  I do believe that Mobile Ad-Hoc Networking is an important topic for the IETF to be involved in, which means that the obvious step forward is to recharter.

Given the still active discussion on AODVv2, I don't think it is the right thing to expect it to continue (and be concluded at some point [*]) mixed in with new charter items.  In other words, the WG has to clear the AODVv2 work item before moving on: (as Justin put it earlier) "pass it on up to the IESG or remove it as a WG item and hand it back to the authors to do with it what they will" [2].  As you have already noticed, the chosen path is to attempt to reach WG consensus in the next 2 weeks or give up.

There is no time limit related to how long a WG may discuss a specific topic.  Besides the fact that the WG doesn't seem to be making progress [*], why the hurry?  IETF 96 is scheduled for the 3rd week in July.  Unless the WG has a new Charter, this will be the 3rd meeting in a row without a manet WG session.  As I've been trying to elaborate above: there is no new Charter because the WG hasn't been able to complete the current work.  Going back to the options from rfc2418, the next action would then be to close the WG.

[Slight aside:  IETF 96 starts on Jul/18.  The cut-off date to request a WG meeting is Jun/3.  The process to have a new Charter approved and give the WG participants enough time to write new drafts, start new discussions on the mailing list, etc., puts us back to the last week in May to have a charter written up that the IESG can review.  This is where the rush comes from.]

Let me be clear…  I think Mobile Ad-Hoc Networking is an important topic for the IETF, but the WG hasn't shown an ability to complete the work [*].  Again, in this context "completing the work" is not just tied to a request for publication of AODVv2 (or any specific status) — but, as Justin explained, to the result of the WGLC (which may result in a publication request or in giving up).

Having said all that, the IETF consensus works.  It is completely up to you (the WG) how you want to spend your time.  Some things that come to mind are: discuss the process, discuss the AODVv2 document and try to reach consensus — or at least point at all the reasons it should/should not be published (to help Justin with his decision); you could also keep working as usual [*] or even decide to do nothing.  It would be very nice if this WG had a new charter and we could all turn to a new page before IETF 96, but clearly that is not a MUST.

Alvaro.

[*] Based on my observation of the discussions on the list, the clear animosity some of the participants express at each other on the list, the opinions you express of each other, and conversations I've had with several of you at the IETF, on e-mail, on the phone or while at other venues…

[1] RFC2418: IETF Working Group Guidelines and Procedures (https://tools.ietf.org/html/rfc2418)
[2] https://mailarchive.ietf.org/arch/msg/manet/3MQgdG7jg0nhKNF2Be9i_S21hx8

---

From: Jiazi YI <[email-masked]>
Date: Wed, 20 Apr 2016 22:50:20 +0200

Hi Justin, all,

I'm very surprised by the WGLC at this point. At least with my limited IETF
experience, it's out of my understanding. I checked related document, and
found those text in "The Tao of IETF":

When a WG document has been fully discussed, it usually goes through
> Working Group Last Call (often abbreviated as "WGLC"). This is a
> hopefully-final time for the WG to iron out issues. Sometimes, WGLC will
> bring out so many issues that there will be a second WGLC after the
> revisions have been incorporated. There are no formal rules for how a WGLC
> happens, or even if a WGLC is needed: it is up to the WG chairs.

There is no doubt that the document is not fully discussed yet, so we are
in an *unusual* case here. Especially considering the number of significant
issues in the document, even no single comment is raised during the WGLC,
the authors need to produce new revisions to address existed tickets, and
another WGLC is needed.
So I don't really get the point of the WGLC at this point (except "running
out of time").

Anyways, I'm not against the chair's decision at this point. But I would
like my concern to be noted by the document shepherd and the WG (although
they are obvious and have been raised by others):

- There are still significant amount of technical issues to get resolved
before the WGLC.

- As a WG document, the editing process is in lack of transparency. The
authors didn't discuss the comments on the mailing list until very
recently. Most of the time, we see a new revision of the document, telling
us the comments are addressed -- some yes, but lots are not so.
Now the document became experimental and last called -- which is a big
surprise to lots of the WG participants.

- Lack of response from the author team on the comments. Because of the
lack of transparency on the discussion of the technical issues, lots of
comments remains for long time without being discussed or addressed.

- Lack of implementation and experience. I heard there was an
implementation of AODVv2 long time ago, but considering the evolution of
the document, I'm afraid it's not up-to-date? I didn't hear any paper or
document reporting the experience of AODVv2 in the field either.
Of course, considering the document is now in experimental track, this
issue is less important.

(I finished this mail before seeing Alvaro's post, which gives me more
background of the whole issue -- thanks)

A detailed review will be provided later.

best

Jiazi

---

From: John Dowdell <[email-masked]>
Date: Wed, 20 Apr 2016 23:00:21 +0100

Hi AD, co-chairs and all

Speaking as  a co-author of this document, I have to say I am very surprised at the sudden WGLC and labelling as Experimental, not least because the first I heard of it was when it was announced on the list earlier today. That is not to say that I did not know something like this would happen one day, but to come as a fait accompli with such a guillotine is a considerable shock. I have read on- and off-list emails on this topic this evening and can understand the reasons, but this to me is not consensus politics. I agree that those in charge have to make decisions, but I disagree that they should be made in isolation from the author team and the WG. The WG has not met face to face for two meetings so these issues have not been discussed in the normal way, although I am pleased that informal meetings have taken place instead.

I was asked to join the three-man author team for AODVv2 following the Paris IETF in 2012 that I’m sure many on this list will remember. We worked hard, but by the Honolulu meeting in late 2014 it was clear we needed additional authors who were used to working at a high level of detail. Enter Lotte and Vicky who have provided stellar contributions and have way exceeded even my best hopes for making progress on this document. Let me also say that all of the authors have given significant amounts of their own time to make this document what it is today.

As I understand it, it seems likely that this document will now be consigned to the dustbin of history, since, despite huge progress having been made from what we were handed in 2012, there will be no consensus on what to do next. That to me says that this WG holds no value to the work that has been carried out, that it is of no worth. As has been pointed out elsewhere, this is a large document, although shorter and far easier to understand than it used to be, and it takes time to review. For the review to be demanded in 2 weeks, especially with the 5444 usage draft WGLC going on at the same time, it is a tall order.

I would respectfully ask that this decision be reconsidered.

John

> On 20 Apr 2016, at 21:50, Jiazi YI <[email-masked]> wrote:
> 
> Hi Justin, all, 
> 
> I'm very surprised by the WGLC at this point. At least with my limited IETF experience, it's out of my understanding. I checked related document, and found those text in "The Tao of IETF":
> 
> When a WG document has been fully discussed, it usually goes through Working Group Last Call (often abbreviated as "WGLC"). This is a hopefully-final time for the WG to iron out issues. Sometimes, WGLC will bring out so many issues that there will be a second WGLC after the revisions have been incorporated. There are no formal rules for how a WGLC happens, or even if a WGLC is needed: it is up to the WG chairs.
> 
> 
> There is no doubt that the document is not fully discussed yet, so we are in an *unusual* case here. Especially considering the number of significant issues in the document, even no single comment is raised during the WGLC, the authors need to produce new revisions to address existed tickets, and another WGLC is needed. 
> So I don't really get the point of the WGLC at this point (except "running out of time"). 
> 
> Anyways, I'm not against the chair's decision at this point. But I would like my concern to be noted by the document shepherd and the WG (although they are obvious and have been raised by others):
> 
> - There are still significant amount of technical issues to get resolved before the WGLC. 
> 
> - As a WG document, the editing process is in lack of transparency. The authors didn't discuss the comments on the mailing list until very recently. Most of the time, we see a new revision of the document, telling us the comments are addressed -- some yes, but lots are not so.  
> Now the document became experimental and last called -- which is a big surprise to lots of the WG participants. 
> 
> - Lack of response from the author team on the comments. Because of the lack of transparency on the discussion of the technical issues, lots of comments remains for long time without being discussed or addressed. 
> 
> - Lack of implementation and experience. I heard there was an implementation of AODVv2 long time ago, but considering the evolution of the document, I'm afraid it's not up-to-date? I didn't hear any paper or document reporting the experience of AODVv2 in the field either. 
> Of course, considering the document is now in experimental track, this issue is less important. 
> 
> (I finished this mail before seeing Alvaro's post, which gives me more background of the whole issue -- thanks)
> 
> On Wed, Apr 20, 2016 at 7:50 PM, Justin Dean <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
> 
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Apr 2016 02:42:31 +0200

On Wed, Apr 20, 2016 at 10:50 PM, Jiazi YI <[email-masked]> wrote:

> [....]
I don't agree with you. I know that the WG is responsible to react quickly
of what it adopted, even participants MUST edit the draft by mentioning
clearly what they want to see written exactly in words. Comments should be
addressed by the WG to make it into words in the draft, so the commenters
needs to edit and help writing. If you disagree please point me to the IETF
procedure that authors are alone responsible for addressing all comments
into words. IMO, this authors team do respond and they edit for  WG. I
think we all need to take the responsibility for the WG situation, we also
as WG may need to have a nice meal together in next IETF.

AB

---

From: John Dowdell <[email-masked]>
Date: Thu, 21 Apr 2016 19:24:09 +0100

All

I believe we’re going about this the wrong way, and we’re setting ourselves an impossible target at which we are bound to fail.

BCP 9, governing the Internet Standards process, section 4.1.1 deals with the first level of maturity, termed Proposed Standard. To paraphrase, a Proposed Standard is supposed to be as correct as we can make it, but there is no requirement to have made an implementation. Since no engineer has ever written a fully correct specification before cutting metal, it may be expected that there are some areas which will need attention later on, at Draft Standard if we ever wanted to go that far. I’ll say now that one area in AODVv2 will need some work later, that of hop-by-hop security in an ad hoc network. This is because nobody has really cracked that problem yet; some real bright people are grappling with that right now over in DTN. The work in our own group on Identity Based Signatures will help but there is still ground to cover. However the actual level of security is not for AODVv2 to mandate, it is for the implementor and system integrator, based on an assessment of the likely risk and the thickness of their wallet.

It is clear to me that few will make an independent implementation without the RFC stamp. This much is obvious in modems fitted with DLEP; there are just four such implementations I know of, and two of those were written with the encouragement of author team members, but I know of many more who are just waiting for the dust to settle so they can make the business case to proceed. Allow AODVv2 to get to RFC and we’ll encourage others to use it and get some feedback.

Regards
John

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 21 Apr 2016 11:45:49 -0700

Hello folks,

At least this author is ready to get on with revising the draft. There's 
not much currently left to do.

We don't have to take anyone's name away from previously published 
documents.  All we have to do is accede to the request for the future 
documents.

I have already offered to spend time on making the revision.

Regarding security: if AODVv2 were to solve all the possible security 
exposures of ad hoc networks, it would be historic and worthy of 
publication -- probably would win paper of the year. Needless to say, 
that was never part of the charter.

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 21 Apr 2016 20:27:32 +0100

This is missing the point, or not expressing clearly, that Experimental, which may or may not be accepted, is an RFC. It's not a choice between Proposed Standard and RFC. The WG can produced a Proposed Standard, Experimental or not (I'm ignoring obviously inappropriate things like Informational). Not is however not the final word on RFC status, there's approaches like AD sponsored and Independent Submission.

But Proposed Standard is, by current practice, a high bar. It's not acceptable to say "this is roughly right, let's do this and get it right in a future advance". That's more like (I'm not saying exactly like) Experimental. Most protocols never advance beyond Proposed Standard, even ones the Internet relies on. In most organisations it would be called a standard.

In addition, the next stage after Proposed Standard isn't Draft Standard. That's been abolished (for new documents). The next stage after Proposed Standard is Internet Standard, and that's a very high bar indeed.

That's been in the abstract. In fact the chair has ruled out Proposed Standard. You'd have to invoke process to overturn that - and (switching to opinion, up to now I may or may not have made errors, but it's meant to be objective) I'm pretty sure you'd fail.

Do the labels Experimental and Proposed Standard (and others) matter? Outside the IETF quite a few people just say "RFC" and that's enough. Inside the IETF people care, and many of those wished others did - and some do.

> On 21 Apr 2016, at 19:24, John Dowdell <[email-masked]> wrote:
> 
> 
> All
>

---

From: Jiazi YI <[email-masked]>
Date: Thu, 21 Apr 2016 22:38:05 +0200

Hi,

On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <
[email-masked]> wrote:

> <snip>
> publication -- probably would win paper of the year. Needless to say, that
> was never part of the charter.
>

But security and its consideration are part of every specification.

As one who co-authored several vulnerability analysis drafts/RFCs
(ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we always do
for a protocol is:

  - assuming that we have a compromised router in the network, what can it
do to break the network? What's the consequences? What about if there are
several of them?

  - what about if there are mis-configured routers or wrong-implemented
routers?

  - what kind of threats can be mitigated by existed security measurements
(like RFC 7182/7183)?

  - what kind of future work can be done to make the protocol more secure?

With the current AODVv2 specification, if I was to produce a
aodvv2-sec-threats draft, it would be much simpler:

   - one single compromised router can easily jam the whole network (RREQ
flooding), or even bring down the whole network (remember the multicast
RERR?) because of the transit-trust model used.

  - with my limited knowledge, as future work, there is no easy way to
protect the message because of the reconstructed and length-varied message
regenerated in every hop.

Even *if* security was acceptable as future work (it is not, but as a
thought experiment, let's assume), there is no easy way to protect the
message because of the reconstructed and length-varied message regenerated
in every hop.

Securing a reactive protocol requires different considerations than does
securing a proactive protocol, but there has been work done in this area,
and other WG participants have raised both their concerns, and suggestions
to security architectures, and protocol architectures (better) able to
accommodate security, a long time ago. I don't see those works, nor the
suggestions and comments made, reflected or considered in revision -15 of
the draft. Especially, the current design based on message regeneration
makes the future extension to the security very hard, as has been
reiterated repeatedly.

Abdussalam doesn't agree with me on my observation on "Lack of response
from the author team on the comments. " -- this is an example.

regards

Jiazi

btw, I would like to confirm with the WG chair: the WGLC is from April 20th
to May 4th, right?

>> I believe we’re going about this the wrong way, and we’re setting
>> ourselves an impossible target at which we are bound to fail.
>>
>> BCP 9, governing the Internet Standards process, section 4.1.1 deals with
>> the first level of maturity, termed Proposed Standard. To paraphrase, a
>> Proposed Standard is supposed to be as correct as we can make it, but there
>> is no requirement to have made an implementation. Since no engineer has
>> ever written a fully correct specification before cutting metal, it may be
>> expected that there are some areas which will need attention later on, at
>> Draft Standard if we ever wanted to go that far. I’ll say now that one area
>> in AODVv2 will need some work later, that of hop-by-hop security in an ad
>> hoc network. This is because nobody has really cracked that problem yet;
>> some real bright people are grappling with that right now over in DTN. The
>> work in our own group on Identity Based Signatures will help but there is
>> still ground to cover. However the actual level of security is not for
>> AODVv2 to mandate, it is for the implementor and system integrator, based
>> on an assessment of the likely risk and the thickness of their wallet.
>>
>> It is clear to me that few will make an independent implementation
>> without the RFC stamp. This much is obvious in modems fitted with DLEP;
>> there are just four such implementations I know of, and two of those were
>> written with the encouragement of author team members, but I know of many
>> more who are just waiting for the dust to settle so they can make the
>> business case to proceed. Allow AODVv2 to get to RFC and we’ll encourage
>> others to use it and get some feedback.
>>
>> Regards
>> John

---

From: Jiazi YI <[email-masked]>
Date: Thu, 21 Apr 2016 23:00:00 +0200

And by simply searching the archive, I would like to point out that those
comments are nothing new.

In the comments from Thomas in 2010 (6 years ago), the issue has been
brought out in
http://www.ietf.org/mail-archive/web/manet/current/msg11858.html , I quote:

<DYMO>   In situations where routing information or router identity are
   suspect, integrity and authentication techniques SHOULD be applied to
   DYMO messages.  In these situations, routing information that is
   distributed over multiple hops SHOULD also verify the integrity and
   identity of information based on originator of the routing
   information.

<TC> This is really difficult to do, in case messages are mutable
in-transit, which appears to be the case for RERR and RM's; i.e. for all
DYMO messages. For that reason, using SHOULD is - imo - dangerous here.
Also, for that reason, I think that this issue of mutable messages deserves
being called out explicitly in this section, especially if there are known
or recommended ways of handling this (as is the case, for example, in the
security considerations section of RFC5444 regarding the mutable header
fields for hop-count/hop-limit of messages.

Then related comments were repeated again and again. Isn't enough to bring
the attention of the authors? In fact, the situation get even worse by
changing the strategy to regenerating messages.

best

Jiazi

On Thu, Apr 21, 2016 at 10:38 PM, Jiazi YI <[email-masked]> wrote:

> btw, I would like to confirm with the WG chair: the WGLC is from April
> 20th to May 4th, right?
>
>
>
>>
>> Regards,
>> Charlie P.
>>
>>
>>
>>> BCP 9, governing the Internet Standards process, section 4.1.1 deals
>>> with the first level of maturity, termed Proposed Standard. To paraphrase,
>>> a Proposed Standard is supposed to be as correct as we can make it, but
>>> there is no requirement to have made an implementation. Since no engineer
>>> has ever written a fully correct specification before cutting metal, it may
>>> be expected that there are some areas which will need attention later on,
>>> at Draft Standard if we ever wanted to go that far. I’ll say now that one
>>> area in AODVv2 will need some work later, that of hop-by-hop security in an
>>> ad hoc network. This is because nobody has really cracked that problem yet;

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 21 Apr 2016 14:21:01 -0700

Hello Jiazi,

Follow-up below...  notably I probably should not be doing email today 
since I am ill, but nevertheless you certainly deserve answers...

On 4/21/2016 1:38 PM, Jiazi YI wrote:
> Hi,
>
>
> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     <snip>
>
>     Regarding security: if AODVv2 were to solve all the possible
>     security exposures of ad hoc networks, it would be historic and
>     worthy of publication -- probably would win paper of the year.
>     Needless to say, that was never part of the charter.
>
>
>

And also part of AODVv2 specification.

> (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we 
> always do for a protocol is:
>
>   - assuming that we have a compromised router in the network, what 
> can it do to break the network? What's the consequences? What about if 
> there are several of them?
>
>   - what about if there are mis-configured routers or 
> wrong-implemented routers?
>
>   - what kind of threats can be mitigated by existed security 
> measurements (like RFC 7182/7183)?
>

We have tried to do exactly these things, except for the last one. I 
have read a lot of Security Considerations sections, and that last one 
is by no means universally included.

>    - one single compromised router can easily jam the whole network 
> (RREQ flooding), or even bring down the whole network (remember the 
> multicast RERR?) because of the transit-trust model used.
>
> protect the message because of the reconstructed and length-varied 
> message regenerated in every hop.

Well, I am somewhat happy to see that you are agreeing with me.  I did 
produce an e2e draft that has some protections, and asked for comments, 
and offered it as an adjunct to the current draft.

> message because of the reconstructed and length-varied message 

This is not true.  As is usual in such cases, one has to identify the 
parts that may modified as the packet goes from source to destination, 
and provide some way to verify the authenticity of those fields.

>
> Securing a reactive protocol requires different considerations than 
> does securing a proactive protocol, but there has been work done in 
> this area, and other WG participants have raised both their concerns, 
> and suggestions to security architectures, and protocol architectures 
> (better) able to accommodate security, a long time ago. I don't see 
> those works, nor the suggestions and comments made, reflected or 
> considered in revision -15 of the draft. Especially, the current 
> design based on message regeneration makes the future extension to the 
> security very hard, as has been reiterated repeatedly.
>
> Abdussalam doesn't agree with me on my observation on "Lack of 
> response from the author team on the comments. " -- this is an example.
>

If we missed some things, please be more specific.  But it is factually 
incorrect to suggest that we have not been responsive to the comments.  
I have personally rewritten large parts of the Security Considerations 
twice in response, as well as offered a lot of text during the time when 
other co-authors have held the editorial pen.

Please excuse if I must delay further comment.

Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 21 Apr 2016 23:49:12 +0200

> On 21 Apr 2016, at 23:21, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Jiazi,
> 
> Follow-up below...  notably I probably should not be doing email today since I am ill,

First: take care of yourself, and do get well!

> but nevertheless you certainly deserve answers...
> 
>> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <[email-masked]> wrote:
>>> <snip>
>>> 
>>> Regarding security: if AODVv2 were to solve all the possible security exposures of ad hoc networks, it would be historic and worthy of publication -- probably would win paper of the year. Needless to say, that was never part of the charter.
>> 
>> 

For having relatively recently seen an I-D through to RFC, as I have stated multiple times, the requirements for the security considerations have evolved considerably, since what you may be familiar with, or what you have been reading in the past.

> 
>> 
>> As one who co-authored several vulnerability analysis drafts/RFCs (ndhp-sec-threats, smf-sec-threats, olsrv2-sec-threats), what we always do for a protocol is:
>> 
>>   - assuming that we have a compromised router in the network, what can it do to break the network? What's the consequences? What about if there are several of them?
>> 
>>   - what about if there are mis-configured routers or wrong-implemented routers?
>> 
>>   - what kind of threats can be mitigated by existed security measurements (like RFC 7182/7183)? 
>> 
> We have tried to do exactly these things, except for the last one.  I have read a lot of Security Considerations sections,

I repeat, for having relatively recently seen an I-D through to RFC, as I have stated multiple times, the requirements for the security considerations have evolved considerably, since what you may be familiar with, or what you have been reading in the past.

> and that last one is by no means universally included.
> 
>> 
>> With the current AODVv2 specification, if I was to produce a aodvv2-sec-threats draft, it would be much simpler: 
>> 
>>    - one single compromised router can easily jam the whole network (RREQ flooding), or even bring down the whole network (remember the multicast RERR?) because of the transit-trust model used. 
>> 
>>   - with my limited knowledge, as future work, there is no easy way to protect the message because of the reconstructed and length-varied message regenerated in every hop.
> 
> Well, I am somewhat happy to see that you are agreeing with me.  I did produce an e2e draft that has some protections, and asked for comments, and offered it as an adjunct to the current draft.

As I have also pointed out repeatedly, the e2e draft that you propose inhibits extensibility-without-also-updating-the-e2e-draft - I.e., each possible future extension requires also respinning / updating / replacing that draft. And, as it would be, I am not actually sure that the e2e draft suffices, even without considering extensions, given the things that can happen in a "regeneration of a message". Either way, even *if* the e2e draft was a solution, experience shows that it would have to advance in parallel with the protocol specification, and not as "a promised afterthought". The SEC-ADs won't have the latter.

As I have also pointed out repeatedly, the solution to this problem is to do away with "message regeneration". I have described *how* as well as the security model that would go with that, in several  emails in the past -- emails which so far have not been considered by the authors..

>> Even *if* security was acceptable as future work (it is not, but as a thought experiment, let's assume), there is no easy way to protect the message because of the reconstructed and length-varied message regenerated in every hop.
> 
> This is not true.  As is usual in such cases, one has to identify the parts that may modified as the packet goes from source to destination, and provide some way to verify the authenticity of those fields.
> 

Which is greatly simplified if doing away with both the regeneration and the e2e- Draft, as previously proposed, and repeatedly.

>> Securing a reactive protocol requires different considerations than does securing a proactive protocol, but there has been work done in this area, and other WG participants have raised both their concerns, and suggestions to security architectures, and protocol architectures (better) able to accommodate security, a long time ago. I don't see those works, nor the suggestions and comments made, reflected or considered in revision -15 of the draft. Especially, the current design based on message regeneration makes the future extension to the security very hard, as has been reiterated repeatedly.
>> 
>> Abdussalam doesn't agree with me on my observation on "Lack of response from the author team on the comments. " -- this is an example. 
> 
> If we missed some things, please be more specific. 

Done, for this subject, above. 

> But it is factually incorrect to suggest that we have not been responsive to the comments. 

No, that is factually accurate.

Several comments have been made, by myself and others, including proposals for how to address security, as indicated in the above,  which (demonstrably, least security would have been resolved) have not been addressed.

Thomas

> I have personally rewritten large parts of the Security Considerations twice in response, as well as offered a lot of text during the time when other co-authors have held the editorial pen.
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 22 Apr 2016 10:38:34 +0200

Hi John,

I understand your email that you want standard proposed status which we
wanted before, but did the WG chair or AD change their decision, I read
that they made a decision that either experimental RFC or no RFC. I think
this WG problem is to convince management again. So they don't give me
space for discussion about standard any more. My only choice is discussing
experimental and two weeks for completing it. Am I wrong?

AB

On Thu, Apr 21, 2016 at 8:24 PM, John Dowdell <[email-masked]>
wrote:

> It is clear to me that few will make an independent implementation without
> the RFC stamp. This much is obvious in modems fitted with DLEP; there are
> just four such implementations I know of, and two of those were written
> with the encouragement of author team members, but I know of many more who
> are just waiting for the dust to settle so they can make the business case
> to proceed. Allow AODVv2 to get to RFC and we’ll encourage others to use it
> and get some feedback.
>
> Regards
> John

---

From: Lotte Steenbrink <[email-masked]>
Date: Fri, 22 Apr 2016 11:22:11 +0200

Hi Jiazi, hi everyone,

> Am 21.04.2016 um 23:00 schrieb Jiazi YI <[email-masked]>:
> 
> And by simply searching the archive, I would like to point out that those comments are nothing new.
> 
> In the comments from Thomas in 2010 (6 years ago), the issue has been brought out in http://www.ietf.org/mail-archive/web/manet/current/msg11858.html <http://www.ietf.org/mail-archive/web/manet/current/msg11858.html> , I quote: 
> 
> 
> <TC> This is really difficult to do, in case messages are mutable in-transit, which appears to be the case for RERR and RM's; i.e. for all DYMO messages. For that reason, using SHOULD is - imo - dangerous here. Also, for that reason, I think that this issue of mutable messages deserves being called out explicitly in this section, especially if there are known or recommended ways of handling this (as is the case, for example, in the security considerations section of RFC5444 regarding the mutable header fields for hop-count/hop-limit of messages.
> 
> Then related comments were repeated again and again. Isn't enough to bring the attention of the authors? In fact, the situation get even worse by changing the strategy to regenerating messages. 
> 

The strategy has never been changed, at least not in the past 2-3 years I’ve been watching AODVv2. We’ve just been talking past each other for a really long time. The discussion has just now finally taken a direction where all parties are on the same page, which is really unfortunate timing. For the sake of completeness, I’d also like to point out that we’ve brought up the topic of regeneration issues in September [1] and November [2] 2015, where we’ve explained why we use the word “regeneration”. That would’ve been a great place to resolve the miscommunication that’s apparently been happening. 
I get that we all have day jobs and lives and that E-Mails get lost, but to be pinned as the sole source of delay in this case when we were waiting for (and really curious about) the WG’s input is starting to get insulting.

Anyway, the regeneration discussion is now *finally* on the right path, so let’s get to it.

Best,
Lotte

[1] https://www.ietf.org/mail-archive/web/manet/current/msg18055.html <https://www.ietf.org/mail-archive/web/manet/current/msg18055.html>
[2] https://www.ietf.org/mail-archive/web/manet/current/msg18167.html <https://www.ietf.org/mail-archive/web/manet/current/msg18639.html>
> best
> 
> Jiazi
> 
> On Thu, Apr 21, 2016 at 10:38 PM, Jiazi YI <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, 
> 
> 
> On Thu, Apr 21, 2016 at 8:45 PM, Charlie Perkins <[email-masked] <mailto:[email-masked]>> wrote:
> <snip>
> 
> btw, I would like to confirm with the WG chair: the WGLC is from April 20th to May 4th, right?
>  
>  
> 
> Regards,
> Charlie P.
> 
> 
>