Subject: [manet] Regarding the reactive protocol development.

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 8 Nov 2013 11:44:18 -0800

Stan Ratliff asked me to bring some of the comments I made at the mike during the MANET wg meeting yesterday, to the list. I believe that this is a good idea, if for nothing else but to enter them into public record. 

I realize, though, that the points I raised during the meeting yesterday actually already ARE public record, and have been so since 2010:

	http://www.ietf.org/mail-archive/web/manet/current/msg11858.html

So, I'll hereby go on public record indicating that I've been on public record with these things since 2010...

1) The detailed review comments that I gave to the reactive protocol (at the time, known under the name DYMO) during the Maastricht IETF'78 (in 2010) still largely apply to the current incarnation of the MANET reactive protocol. My review comments were posted to the MANET mailing list, and are on record in the archives:

	http://www.ietf.org/mail-archive/web/manet/current/msg11858.html

Around at the same time, other reviews were posted by others. A quick skim through these indicate that many of those review comments have not been addressed either.
I believe that it would have behoved the authors to look through these reviews when reviving this activity, and to ensure that the comments were reflected in the document - or, deflected through discussion on the list. Alas, given that such reviews (still) have not been throughly addressed by the most recent WG document, I'm not sure that providing a review again saying the same is any good use of my (or WG) time. 

2) RFC5444 is used wrongly in the document: positional semantics of address, and semantics of  an address given by its mere presence in a message, has as consequence that it is nigh impossible to develop extensions that are backwards compatible. It's a comment that the WG well should be aware of, as it was raised in the context of early versions of DLEP (where it was promptly resolved). 

	Note: This issue also was raised in the review cited under point 1.The document must be 
	substantially revised to this effect.

3) The document is extremely unstructured. When I get a message X, then what procedure must I follow? This information is scattered throughout the 60ish pages, and it renders it extremely complicated to even begin to understand how to implement correctly. I've read the document on the way over to Vancouver, and I've read it again this morning. I still can't properly draw the state machines, and there're processing bits that I *think* are not specified (but maybe reading it a 3rd time is required). The point here is, the IETF writes specifications so as to help implementers make correct implementations. This document makes it a lot of work to try to figure out what's supposed to be implemented.

	Note: This issue also was raised in the review cited under point 1.The document must be
	substantially revised to this effect.

4) The document employs sloppy terminology and invented (and redundant) non-standard terminology. For example, but non-exhaustively, the terms "Routing client" and "node" - why not  the well-defined terms "host" and "router"? 

	Note: This issue also was raised in the review cited under point 1.The document must be 
	substantially revised to this effect.

5) I am worrying that there are virtually non-existent security considerations in this document. In part, "in this day and age, this is unacceptable", but more pragmatically, having seen the (justified) scrutiny that the SEC-DIR and SEC ADs apply to documents they review, this won't pass muster. 

	Note: This issue was only touched upon in the review cited under point 1.
	But, I still believe that the document must be  substantially revised to this effect.

6) The document is ripe with options, often expressed vaguely "XX should be done, you can do that by, for example ZZ, YY or WW....", and that makes me worried. Options means code branches, which means more test-cases to run through (and, more branches in an interoperability test). It also means, that if an implementation "does XX by way of ZZ", will that, or will that not, interoperate with an implementation that "does XX by way of WW"? 

I believe that the author presenting implicitly acknowledged that such options make things complicated - by saying that the first implementation that he intended to produce would be very partial and include only a "core" without options. 

	Note: I have numerous times (since the last Paris IETF, at least) suggested that in that case 
	it's miles better to produce a document with that minimal "core", leaving options for a later 
	process.

7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG.

8) Given that the past 12 months, when the effort was "rebooted" by the responsible AD, have yielded no improvement of the document quality, and has seen none of the comments previously made, it's hard to have confidence in this document going forward - and, therefore, it is hard to justify the WG spending further time on this document (across all venues)

Respectfully,

Thomas

Sent from my iPad

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 09 Nov 2013 05:27:25 -0800

Hello folks,

I'm traveling and don't have time just now to go dig out the precise
emails.  But, given the tone of this email, I thought it appropriate to
at least make an initial response.  Inline below.

> I believe that it would have behoved the authors to look through these reviews when reviving this activity, and to ensure that the comments were reflected in the document - or, deflected through di…

I did in fact address these issues, resulting in a thoroughgoing
revision of the document.  I got no feedback at the time, and so
thought there wasn't much more to do.  It would be nice to see
just what particular points remain to do, especially if they were
put on the issue tracker.

> 	substantially revised to this effect.

Similarly, I did address these issues and as far as I know the
current specification is in conformance with RFC 5444.

> 	substantially revised to this effect.

Similarly, I did address this issue.  However, one person's view of
proper structure may differ from another person's view.  If there
are any questions about how to follow a procedure, they should
be pointed out.  Cross references can be inserted as needed, or
document sections rearranged.  I already did a lot of rearrangement,
but I am certainly willing to do more.

> 	substantially revised to this effect.

The terms cited above have particular meanings in the document.
The suggested terms "host" and "router" do not capture the more
specific meanings required at certain points in the document.

> 	But, I still believe that the document must be  substantially revised to this effect.

As best I understand, the security considerations are sufficient.
This is a topic that deserves more attention.

> I believe that the author presenting implicitly acknowledged that such options make things complicated - by saying that the first implementation that he intended to produce would be very partial an…

This is a very generic comment that applies to practically every
protocol in the IETF, including DHCP, IPv6, SIP, IP, TCP, Mobile IP, ...
The "complication" alluded to is far less than in most existing
protocols, and (again) has been thoroughly understood from
past work.

> 	it's miles better to produce a document with that minimal "core", leaving options for a later

This ignores the fact that the optional features have been
well known for many years, and in fact the current division of
functionality into "base" versus "option" was done in response
to previous requests.  I am not aware of any IETF requirement
to delete all optional features when producing base documents.

> 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of m…

This is a gross misrepresentation of fact, and as best I can tell
the person making this complaint has made very little effort
been made to review recent versions of the document, despite
my requests.  If further elaboration is needed I will go back and
find the relevant emails, but right now I can't do that.

====================================================

Having said all that, I encourage constructive dialog and more
detailed suggestions about how to improve document structure
and terminology.  I think it is appropriate to move forward with
the document including the current optional features, or perhaps
including also the intermediate route reply which is a feature that
was originally specified in the base document and has long been
part of the reactive routing protocol development.

If specific suggestions are made to improve the document structure
or terminology (again, much better if posted to the issue tracker),
I can respond much more effectively and will make document
revisions in a timely fashion.

-- 
Regards,
Charlie P.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 12 Nov 2013 15:41:19 -0800

Hi,

UH> I agree with many points from Thomas' review, and I am sad to see that
there was so little progress of AODVv2 (not even a new revision).

UH> I went through one of my old reviews to see which of these items have
been addressed (there was another one in 2010).

UH> November 2012 (my second detailed review of the DYMO/AODVv2 draft):
    http://www.ietf.org/mail-archive/web/manet/current/msg14023.html

==============
[text from the review was:]
The main comments (as shown in detail below) are:
  - The draft is still very difficult to read and is underspecified in
many occasions.

UH> That is still true. The draft is still very hard to read. The structure
makes it very hard for implementers to follow the draft in an easy way
(e.g., which steps do I have to perform when I receive a message / generate
a message). I much prefer the document structure of the OLSRv2 draft.
There are several terms specified (e.g., routers client, upstream router)
that are unclear how they affect the MANET architecture, and why existing
terms (e.g., hosts) would not be sufficient.

For example, it is unclear how the blacklisting works,
how metrics are used, how the TLVs are associated with certain
addresses.

UH> In the black list section, there are many SHOULDs. It is unclear why
they are not MUSTs, or what happens if an implementation decides not to do
so. Text such as "The IP address of the node" is ambiguous: why node, not
router? Which IP address? A router may have many interfaces, and each of
them may have multiple IP addresses. "The time at which Blacklist.Node will
be removed from the blacklist.". What does "will" mean? MUST?

UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk"
still indicate requirement of address order in an address block. WG
consensus was not to use that. Also, the text seems to indicate that there
is a single address block. That would be against the intended RFC5444
architecture.

Some of the parameters and TLVs specified in the IANA
section are not used. There are at least four timers for each route
entry, and it is unclear how they may affect each other. It is not
clearly specified how to update forward/reverse routes + the route to
the previous hop
  - The use of metrics is not well defined; there is an optional
distance field. It is unclear how metrics are created, whether they
are additive, how they are formatted etc. What happens if some routers
now the Distance field, others don't use it.
  - There are several extensions specified, but too few details to
assure interoperability. Some of them violate end-to-end security.

UH> That still applies (see section 13 of the AODVv2 draft) During IETF86,
we have been promised a summary of these options (see
http://tools.ietf.org/wg/manet/minutes?item=minutes-86-manet.html), but
that has not been delivered. There needs to be a lot more discussion about
how these options affect interoperability and security (e.g., the argument
that intermediate RREPs make end-to-end security very difficult still
applies). I still believe that a slim core without any optional features
would be a better approach. Some of these extensions severely affect how
message integrity can be provided. That must be discussed in a lot of
detail. I also note that none of these extensions are tested in the
(yet-to-be-done) AODVv2 implementations.

  - As messages are modified in transit, end-to-end security is not
possible. The security considerations section does not fulfill the
requirements in RFC3552.

UH> This still applies (in particular with intermediate RREPs)

  - Extensions, such as for security, cannot be hooked into AODVv2, as
there is no section to allow an external mechanism to provide
additional reasons to reject a message as invalid, such as done in
RFC6130.

UH> This still applies.

  - The IANA section is not correct. There are no requests, no new
registries or code points in existing registries, no allocation policy
is provided.

UH> This still applies.

  - There are some layer violations where tasks that are to be done by
the RFC5444 (de)multiplexer are handled in AODVv2.

UH> This still applies, e.g., in section 5.4, when the RFC5444 parser and
the IP layer are mixed, and where AODVv2 uses RFC2119 language for IP layer
operations such as TTL.

  - There is a mandated order of addresses in RFC5444 messages; I
think this is a bad idea if extensions want to add addresses.
  - Originator address and sequence number are contained in address
block and address block TLV, instead of the message header, so there
is additional overhead.

UH> That still applies. Incidentally, I also don't understand why the
metric type is not encoded as TLV type extension, but rather in a separate
TLV.

  - There is no RREP_ACK or other mechanism to verify bidirectionality
of links.

UH> This has been added as (very short) extension, although it is unclear
how this works in detail, or how interoperability is assured with
deployments not using that message (e.g. one router expecting a RREP_ACK, a
neighbor not supporting it).

  - It is unclear to me how the destination sequence number is used in
RREQ and what it serves for.
  - Intermediate route replies are hard to secure with signatures

UH> This still applies
==============

Conclusion:

UH> I could go again in such great detail through the AODVv2 draft, but I
fear that given the slow progress, this would not be a good investment of
my time. I also notice that so far, implementations and interop tests have
only been promised, but not delivered.

UH> Adrian has selected the AODVv2 text as basis for the reactive protocol.
Two IETFs later, I am personally disappointed with the progress, and
believe that the decision was a wrong one (this is not to blame Adrian,
just an observation of the outcome). There have been many I-Ds and academic
publications produced for LOADng (ask, if you want the details); in
addition, it has been approved by the G3 Alliance to  as routing protocol
standard for PLC.

UH> There are at least four interoperable LOADng implementations with
interop report, MIB document, very readable and close to WGLC-ready draft
of LOADng, large-scale deployments as well as academic experience, a slim
core design without complicated extensions, and several companion drafts.

UH> My recommendation to the WG is to:
   1) Admit defeat on the ability to produce a reactive protocol, and
recharter (or close) the WG
   2) Make LOADng the WG document and appoint new editors for the reactive
protocol.

Best regards
Ulrich

On Sat, Nov 9, 2013 at 5:27 AM, Charles E. Perkins <[email-masked]>wrote:

>> Stan Ratliff asked me to bring some of the comments I made at the mike
>> during the MANET wg meeting yesterday, to the list. I believe that this is
>> a good idea, if for nothing else but to enter them into public record.
>>
>> I realize, though, that the points I raised during the meeting yesterday
>> actually already ARE public record, and have been so since 2010:
>>
>> 1) The detailed review comments that I gave to the reactive protocol (at
>> the time, known under the name DYMO) during the Maastricht IETF'78 (in
>> 2010) still largely apply to the current incarnation of the MANET reactive
>> protocol. My review comments were posted to the MANET mailing list, and are
>> on record in the archives:
>>
>> Around at the same time, other reviews were posted by others. A quick
>> skim through these indicate that many of those review comments have not
>> been addressed either.
>> I believe that it would have behoved the authors to look through these
>> reviews when reviving this activity, and to ensure that the comments were
>> reflected in the document - or, deflected through discussion on the list.
>> Alas, given that such reviews (still) have not been throughly addressed by
>> the most recent WG document, I'm not sure that providing a review again
>> saying the same is any good use of my (or WG) time.
>>
>
>  2) RFC5444 is used wrongly in the document: positional semantics of
>> address, and semantics of  an address given by its mere presence in a
>> message, has as consequence that it is nigh impossible to develop
>> extensions that are backwards compatible. It's a comment that the WG well
>> should be aware of, as it was raised in the context of early versions of
>> DLEP (where it was promptly resolved).
>>
>> 3) The document is extremely unstructured. When I get a message X, then
>> what procedure must I follow? This information is scattered throughout the
>> 60ish pages, and it renders it extremely complicated to even begin to
>> understand how to implement correctly. I've read the document on the way
>> over to Vancouver, and I've read it again this morning. I still can't
>> properly draw the state machines, and there're processing bits that I
>> *think* are not specified (but maybe reading it a 3rd time is required).
>> The point here is, the IETF writes specifications so as to help
>> implementers make correct implementations. This document makes it a lot of
>> work to try to figure out what's supposed to be implemented.
>>
>> 4) The document employs sloppy terminology and invented (and redundant)
>> non-standard terminology. For example, but non-exhaustively, the terms
>> "Routing client" and "node" - why not  the well-defined terms "host" and
>> "router"?
>>
>> 5) I am worrying that there are virtually non-existent security
>> considerations in this document. In part, "in this day and age, this is
>> unacceptable", but more pragmatically, having seen the (justified) scrutiny
>> that the SEC-DIR and SEC ADs apply to documents they review, this won't
>> pass muster.
>>
>> 6) The document is ripe with options, often expressed vaguely "XX should
>> be done, you can do that by, for example ZZ, YY or WW....", and that makes
>> me worried. Options means code branches, which means more test-cases to run
>> through (and, more branches in an interoperability test). It also means,
>> that if an implementation "does XX by way of ZZ", will that, or will that
>> not, interoperate with an implementation that "does XX by way of WW"?
>>
>> I believe that the author presenting implicitly acknowledged that such
>> options make things complicated - by saying that the first implementation
>> that he intended to produce would be very partial and include only a "core"
>> without options.
>>
>
>> 7) Given that the above comments have been made ad infinitum since
>> Maastricht, on the list and in WG meetings, without seeing any improvement
>> of the document, it is hard to justify the efforts of making further
>> reviews or comments: so far, such have been ignored. A good start would be
>> to incorporate those reviews, for the authors to show "good faith" and
>> listen to the WG.
>>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 13 Nov 2013 15:49:38 +0000

Thomas, 

Thank you for taking the time to do this. The editing team will work through the items you list here, and endeavor to make the document better. 

I'd also like to thank Ulrich for his additional comments & review; those items will be looked at as well. 

Regards,
Stan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 13 Nov 2013 16:33:16 +0000

I'm not going to get into most of this. I'm just going to note that were the security considerations section in this draft regarded as adequate by the security ADs, then they would be applying very different standards to those they have applied to OLSRv2.

(I think that's easy to see as a factual statement by consulting the record of what they have required, and then noting that several of these things are not present in this draft. Note that in the case of OLSRv2 that has resulted in the production of additional documents. This are not just trivial additions either.)

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: 09 November 2013 13:27
To: List List
Subject: Re: [manet] Regarding the reactive protocol development.

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hello folks,

-- 
Regards,
Charlie P.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 13 Nov 2013 21:06:35 +0100

I would have expected that the editing team had worked through this already in 2010 when the comments were first raised......or that the current editing team would have done so when appointed. 

Indeed, Mr. Perkins indicated in his reply to my email that he believes that the team has done so already, that no further actions are required on these points, and generally brushes off the comments made.

Past behavior is a good way of predicting future actions.

Given that the author "holding the pen" for this document is the same since 2010, and that that author has gone on record stating that he believes that no further changes are needed to address my comments, I submit that I do not have any confidence that "the editing team will work through the items...and endeavor to make the document better".

It behoves the WG to act accordingly - as Ulrich suggest, by either declaring defeat wrt delivering on a reactive protocol milestone, and recharter to remove this from the charter, or by appointing a different set of authors for this item.

Respectfully,

Thomas

Sent from my iPad

> On 13 nov. 2013, at 16:49, "Stan Ratliff (sratliff)" <[email-masked]> wrote:
> 
> Thomas, 
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 13 Nov 2013 12:42:06 -0800

Hello folks,

The narrative below misrepresents my past actions.

> Indeed, Mr. Perkins indicated in his reply to my email that he believes that the team has done so already, that no further actions are required on these points, and generally brushes off the commen…

What I said was that, after revisions had been proposed to resolve the 
old comments,
no further feedback was received.  If further revision is needed, I am 
certainly ready
to discuss and take action.

That is really quite different than the above-mentioned characterization 
of my
response.  Also please keep in mind that these comments were submitted a 
long
time before I restarted as the active document editor.  I retrieved them 
from the
mailing list archive precisely so that I could be as responsive as 
possible to the
concerns that had been raised.  This is the polar opposite from being 
dismissive.

> Past behavior is a good way of predicting future actions.

Indeed.  Publicly and privately I have always done what I said I would do.

> Given that the author "holding the pen" for this document is the same since 2010, and that that author has gone on record stating that he believes that no further changes are needed to address my comments, ...

Again, this is not at all what I said.  After I made the revisions in an 
effort
to resolve the issues that had been raised, no further response was ever
received and therefore I could not know whether or not my resolution
was successful.  Given recent notifications that more work is needed, I
suggest we identify proper resolutions to the remaining problems.

> It behoves the WG to act accordingly - as Ulrich suggest, by either declaring defeat wrt delivering on a reactive protocol milestone, and recharter to remove this from the charter, or by appointing…

Now that new comments have been received, I suggest that we work through 
them.
It would be nice if the new comments were submitted to the issue 
tracker.  Failing
that, I will identify and isolate the separate issues and put them on 
the issue tracker
myself.

-- 
Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 13 Nov 2013 22:27:33 +0100

AFAIK, there has been no "editor" designation for either iteration of this I-D, but a collective of authors.

Mr. Perkins claims that:
	"Also please keep in mind that these comments were submitted a long 
	  time before I restarted as the active document editor. "

Let me produce some evidence that Mr. Perkins is wrong in that claim:

	2005:
		draft-ietf-manet-dymo-00
		Authors: I. Chakeres, B. Belding-Royer, C. Perkins
			(neither of which is postfixed as "Ed" or "Editor")

	2010:
		draft-ietf-manet-dymo-21
		Authors: I. Chakeres, C. Perkins
			(neither of which is postfixed as "Ed" or "Editor")	

	2013:
		draft-ietf-manet-aodvv2-02
		Authors: C. Perkins, S. Ratliff, J. Dowdell
			(neither of which is postfixed as "Ed" or "Editor")

Thus, Mr. Perkins has been among the authors *continuously* since the inception of the reactive protocol development, and thus carries responsibility for having ignored WG input in the protocol development process.

Also, Mr. Perkins claims:
	"Now that new comments have been received,"

I shall insist that no new comments have been made, and therefore not received, and that Mr. Perkins is factually wrong also here. 

The recent mails by Ulrich and I (and, to some extend, also by Chris) are simply restatements (with pointers) of the reviews/comments that were already made since, at least, 2010.

Thus, there are no misrepresentations in the "narrative", contrary to the claims of Mr. Perkins.

Respectfully,

Thomas

Sent from my iPad

> On 13 nov. 2013, at 21:42, "Charles E. Perkins" <[email-masked]> wrote:
> 
> 
> Hello folks,
> 
> What I said was that, after revisions had been proposed to resolve the old comments,
> no further feedback was received.  If further revision is needed, I am certainly ready
> That is really quite different than the above-mentioned characterization of my
> response.  Also please keep in mind that these comments were submitted a long
> time before I restarted as the active document editor.  I retrieved them from the
> mailing list archive precisely so that I could be as responsive as possible to the
> concerns that had been raised.  This is the polar opposite from being dismissive.
> 
> 
> Again, this is not at all what I said.  After I made the revisions in an effort
> Now that new comments have been received, I suggest that we work through them.
> It would be nice if the new comments were submitted to the issue tracker.  Failing
> that, I will identify and isolate the separate issues and put them on the issue tracker
> myself.
> 
> -- 
> Regards,
> Charlie P.
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 13 Nov 2013 21:47:41 +0000

Actually, on my comment, I'll note that something of the style of the current security considerations section might have flown some years back - compare for example RFC 6130. But won't fly now, unless things change again, which I find unlikely.

So I wouldn't classify my comment from this round as simply a restatement.

(Once you get to deciding you need an actual mechanism, then some other issues arise. But those come later.)

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 15 Nov 2013 01:05:10 +0800

Dear all,

While Thomas Clausen believed that

> TC>>  7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of making further reviews or comments: so far, such have been ignored. A good start would be to incorporate those reviews, for the authors to show "good faith" and listen to the WG.
>
> TC>>  8) Given that the past 12 months, when the effort was "rebooted" by the responsible AD, have yielded no improvement of the document quality, and has seen none of the comments previously made, it's hard to have confidence in this document going forward - and, therefore, it is hard to justify the WG spending further time on this document (across all venues)
Charles Perkins keeps saying:
> CP>> This is a gross misrepresentation of fact.

Without going into every comment that Thomas Clausen made, we can do a 
little "case study" here:
>> <TC>: 2) RFC5444 is used wrongly in the document: positional 
>> semantics of address, and semantics of  an address given by its mere 
>> presence in a message, has as consequence that it is nigh impossible 
>> to develop extensions that are backwards compatible. It's a comment 
>> that the WG well should be aware of, as it was raised in the context 
>> of early versions of DLEP (where it was promptly resolved).
>>
> <CP>: Similarly, I did address these issues and as far as I know the
> <SNIP>

This issue, has been discussed for 1~ year in the working group. Most of 
the participants (if not all the other), including Ulrich, Justin, 
Henning have expressed that the address positions should be independent.

In the previous discussions, Ulrich, Henning, and Thomas have stated why 
this is important. The feedback from Charlie is "I'm not at
all interested in arguing about it, especially right now!" 
http://www.ietf.org/mail-archive/web/manet/current/msg14756.html

Stan also said that

> <SR> For me, the issue here is that working group consensus seems to 
> have solidified around positional independence. If fact, Charlie, you 
> seem to be the only one holding the counter position. Based on 
> Adrian's email on the way forward, the specification needs to reflect 
> the consensus of the WG. As of right now, that means it (the spec) 
> needs to change.
http://www.ietf.org/mail-archive/web/manet/current/msg14763.html

However, if we look back at the latest revision of AODVv2, we still have
http://tools.ietf.org/html/draft-ietf-manet-aodvv2-02#section-3
>      |      AddrBlk[1]     |    The first address slot in AddrBlk     |
>      |      AddrBlk[N]     |     The Nth address slot in AddrBlk      |
>      |       OrigNdx       | The index of OrigNode within the AddrBlk |
>      |       TargNdx       | The index of TargNode within the AddrBlk |
>      |      AddrTLV[1]     |        the first item in AddrTLV         |
>      |      AddrTLV[N]     |         the Nth item in AddrTLV          |
>      |  AddrTLV[OrigNode]  |             AddrTLV[OrigNdx]             |
>      |  AddrTLV[TargNode]  |             AddrTLV[TargNdx]
Defined in "Notational Conventions" section, and used in all over the 
draft.

While Charles Perkins still thinks

> CP>> Similarly, I did address these issues and as far as I know the
=================================================

This is just one example  - I can dig into the mailing list to get 
similar discussions on other issues.
What I observed is that, even the WG group consensus is so obvious, it 
is extremely hard to have it addressed in the WG document (because the 
editor thinks it is addressed).

Therefore, I would say that from my point of view, Thomas Clausen's 
observation is not misrepresented.

Additionally, I'm very shocked when hearing Charlie said

> Also please keep in mind that these comments were submitted a long
> 	  time before I restarted as the active document editor.
who had been listed as co-author of dymo draft since 2005.

Sincerely

Jiazi YI

> Charles E. Perkins <mailto:[email-masked]>
> 14 Nov 2013 04:42
>
> Hello folks,
>
>> I would have expected that the editing team had worked through this 
>> already in 2010 when the comments were first raised......or that the 
>> current editing team would have done so when appointed.
>>
>> Indeed, Mr. Perkins indicated in his reply to my email that he 
>> believes that the team has done so already, that no further actions 
>> are required on these points, and generally brushes off the comments 
>> made.
>
>> Given that the author "holding the pen" for this document is the same 
>> since 2010, and that that author has gone on record stating that he 
>> believes that no further changes are needed to address my comments, ...
>
>> It behoves the WG to act accordingly - as Ulrich suggest, by either 
>> declaring defeat wrt delivering on a reactive protocol milestone, and 
>> recharter to remove this from the charter, or by appointing a 
>> different set of authors for this item.
>
> Stan Ratliff (sratliff) <mailto:[email-masked]>
> 13 Nov 2013 23:49
> Thomas,
>
> Thank you for taking the time to do this. The editing team will work 
> through the items you list here, and endeavor to make the document 
> better.
>
> Thomas Heide Clausen <mailto:[email-masked]>
> 9 Nov 2013 03:44
> during the MANET wg meeting yesterday, to the list. I believe that 
> this is a good idea, if for nothing else but to enter them into public 
> record.
>
> I realize, though, that the points I raised during the meeting 
> yesterday actually already ARE public record, and have been so since 2010:
>
> So, I'll hereby go on public record indicating that I've been on 
> public record with these things since 2010...
>
> 1) The detailed review comments that I gave to the reactive protocol 
> (at the time, known under the name DYMO) during the Maastricht IETF'78 
> (in 2010) still largely apply to the current incarnation of the MANET 
> reactive protocol. My review comments were posted to the MANET mailing 
> list, and are on record in the archives:
>
> skim through these indicate that many of those review comments have 
> not been addressed either.
> reviews when reviving this activity, and to ensure that the comments 
> were reflected in the document - or, deflected through discussion on 
> the list. Alas, given that such reviews (still) have not been 
> throughly addressed by the most recent WG document, I'm not sure that 
> providing a review again saying the same is any good use of my (or WG) 
> time.
>
> extensions that are backwards compatible. It's a comment that the WG 
> well should be aware of, as it was raised in the context of early 
> versions of DLEP (where it was promptly resolved).
>
> 3) The document is extremely unstructured. When I get a message X, 
> then what procedure must I follow? This information is scattered 
> throughout the 60ish pages, and it renders it extremely complicated to 
> even begin to understand how to implement correctly. I've read the 
> document on the way over to Vancouver, and I've read it again this 
> morning. I still can't properly draw the state machines, and there're 
> processing bits that I *think* are not specified (but maybe reading it 
> a 3rd time is required). The point here is, the IETF writes 
> specifications so as to help implementers make correct 
> implementations. This document makes it a lot of work to try to figure 
> out what's supposed to be implemented.
>
> 4) The document employs sloppy terminology and invented (and 
> redundant) non-standard terminology. For example, but 
> non-exhaustively, the terms "Routing client" and "node" - why not the 
> well-defined terms "host" and "router"?
>
> considerations in this document. In part, "in this day and age, this 
> is unacceptable", but more pragmatically, having seen the (justified) 
> scrutiny that the SEC-DIR and SEC ADs apply to documents they review, 
> this won't pass muster.
>
> 6) The document is ripe with options, often expressed vaguely "XX 
> should be done, you can do that by, for example ZZ, YY or WW....", and 
> that makes me worried. Options means code branches, which means more 
> test-cases to run through (and, more branches in an interoperability 
> test). It also means, that if an implementation "does XX by way of 
> ZZ", will that, or will that not, interoperate with an implementation 
> that "does XX by way of WW"?
>
> options make things complicated - by saying that the first 
> implementation that he intended to produce would be very partial and 
> include only a "core" without options.
>
> Maastricht, on the list and in WG meetings, without seeing any 
> improvement of the document, it is hard to justify the efforts of 
> making further reviews or comments: so far, such have been ignored. A 
> good start would be to incorporate those reviews, for the authors to 
> show "good faith" and listen to the WG.
>
> 8) Given that the past 12 months, when the effort was "rebooted" by 
> the responsible AD, have yielded no improvement of the document 
> quality, and has seen none of the comments previously made, it's hard 
> to have confidence in this document going forward - and, therefore, it 
> is hard to justify the WG spending further time on this document 
> (across all venues)
>
> Respectfully,
>
> Thomas
>
> Sent from my iPad

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 14 Nov 2013 18:41:00 +0000

There still time available for new editors to target the milestone given,

Comments/reviews should be reminded on list or in meetings with new
revisions, but not restated after years. Editors and WG both could
be blamed for missing comments in past (I was not in the WG). Past comments
on dymo are related if reposted for new draft.

I remember the current WG decision is that we are starting new
reactive draft by adopting the past work of WG and to use tracker tool.
Also WG continues discussing docs of DYMO and LOADng to help form
together the new WG reactive protocol AODVv2, (I think the first who
recommended the change to new name was not the editors but it was Mr.Thomas
recommend in one past meeting).

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 19 Nov 2013 22:31:02 -0800

Hello Ulrich,

Comments and follow-up inline.

On 11/12/2013 3:41 PM, Ulrich Herberg wrote:
> Hi,
>
> UH> I agree with many points from Thomas' review, and I am sad to see 
> that there was so little progress of AODVv2 (not even a new revision).

There weren't any open issues requiring resolution in a new revision,
and we were busy going about the production of interoperable
implementations.  The current draft expires in January, and before
that time I hope the new discussions will bear fruit.

>
> UH> I went through one of my old reviews to see which of these items 
> have been addressed (there was another one in 2010).

I had responded to the issues that you raised, and I did not get
any notification that the proposed resolutions were insufficient.
I am happy to restart the discussion.

> UH> That is still true. The draft is still very hard to read. The 
> structure makes it very hard for implementers to follow the draft in 
> an easy way (e.g., which steps do I have to perform when I receive a 
> message / generate a message). I much prefer the document structure of 
> the OLSRv2 draft.
> There are several terms specified (e.g., routers client, upstream 
> router) that are unclear how they affect the MANET architecture, and 
> why existing terms (e.g., hosts) would not be sufficient.

I'll look at the need for "router client", but keep in mind that AODVv2 
and AODV
do not require that all nodes participate in the AODV protocol.  An AODV 
router
can serve nodes, and the terminology in question was intended to distinguish
those nodes which receive packets relayed by their first hop router 
which does
run AODVv2.

About upstream and downstream -- if these are really confusing, please 
suggest
alternative terminology.

Underspecification is something that needs to be fixed ASAP.

> how metrics are used, how the TLVs are associated with certain

The calculations for metrics are according to the function Cost(),
which is specified in section 5.6, and used in section 6.2. Blacklisting
works as always, and I didn't see what was wrong with the text.
But you make suggestions below which need to be discussed.

>
> UH> In the black list section, there are many SHOULDs. It is unclear 
> why they are not MUSTs, or what happens if an implementation decides 
> not to do so. Text such as "The IP address of the node" is ambiguous: 
> why node, not router? Which IP address? A router may have many 
> interfaces, and each of them may have multiple IP addresses.

I will look to see, but in every case I am aware of the IP address is
associated with a network interface.  I'll look at the use of node versus
router, but a RREQ can be for a node that isn't a router.  I think that,
if an interface has multiple IP addresses, it may not matter which one
is selected (in the sense that correct results will be obtained either
way).  However, I need to verify that.  Or, if any problems are noted,
we could simply restrict each interface to using only a single IP address
for the purpose of running AODVv2.

> "The time at which Blacklist.Node will be removed from the 
> blacklist.". What does "will" mean? MUST?

I am O.K. to replace "will" by "MUST".

> consensus was not to use that. Also, the text seems to indicate that 
> there is a single address block. That would be against the intended 
> RFC5444 architecture.

Well, there has to be a first address in any such list.  The specification
only needs a single address block.  I'm not aware of the need to allow
multiple such blocks except for optional features.  If you think that the
reactive protocol should define a feature using multiple blocks, that
would be an interesting discussion.  I have mentioned this in connection
with RERR with multiple metrics, but there was no discussion.

> clearly specified how to update forward/reverse routes + the route to

I think this is clear in the text.  Did you look at the recent revision?
Route table timers were confusing in DYMO but I believe they are
much more clear now.  Please let me know what exactly is difficult.
Roughly speaking, a route is either Active, Idle, or Expired (or
Broken).  These have very intuitive meanings, and if they are not
clear in the text please help me to understand why.

> now the Distance field, others don't use it.

...? It is not the purpose of the AODVv2 spec to define all the metrics,
and I doubt you are suggesting this.  They are created according to
the definition of the metric, and only hop-count is specified.
AODVv2 requires strictly monotonically increasing metrics, as
was discussed at length on the mailing list.

I am not exactly sure which field is the "Distance" field...

> assure interoperability. Some of them violate end-to-end security.

This is not specific enough for me to know how to resolve.  However,
the entire question of security deserves closer study.

>
> UH> That still applies (see section 13 of the AODVv2 draft) During 
> IETF86, we have been promised a summary of these options (see 
> http://tools.ietf.org/wg/manet/minutes?item=minutes-86-manet.html), 
> but that has not been delivered. There needs to be a lot more 
> discussion about how these options affect interoperability and 
> security (e.g., the argument that intermediate RREPs make end-to-end 
> security very difficult still applies). I still believe that a slim 
> core without any optional features would be a better approach. Some of 
> these extensions severely affect how message integrity can be 
> provided. That must be discussed in a lot of detail. I also note that 
> none of these extensions are tested in the (yet-to-be-done) AODVv2 
> implementations.

I could have easily supplied this list for the recent IETF.  I'll 
certainly have it
for the next one.

> UH> This still applies (in particular with intermediate RREPs)

Intermediate RREPs are in a different document, at your request.
I would indeed like to re-incorporate it into the main text, but this
is less important than resolving the other issues.

> additional reasons to reject a message as invalid, such as done in

I'll take a look, can't comment right now.

> registries or code points in existing registries, no allocation policy

I think you may be looking at an older version of the document.
Allocation policies do need to be supplied -- thanks for pointing
this out.

> UH> This still applies, e.g., in section 5.4, when the RFC5444 parser 
> and the IP layer are mixed, and where AODVv2 uses RFC2119 language for 
> IP layer operations such as TTL.
>

This was resolved in newer versions of the specification by adopting
a proposal from Henning.

> metric type is not encoded as TLV type extension, but rather in a 
> separate TLV.
>
> UH> This has been added as (very short) extension, although it is 
> unclear how this works in detail, or how interoperability is assured 
> with deployments not using that message (e.g. one router expecting a 
> RREP_ACK, a neighbor not supporting it).
>
>

I don't understand what is wrong with the RREP_ACK description.
It doesn't have to be very long, does it?

The destination sequence number is used to guarantee non-looping
and robustness against out-of-order delivery.  This is exactly the
same as in AODV versions and has been studied extensively.  Anyway,
I will look to see how the explanation can be improved.

I would like to put the issues that can be identified into the
issue tracker.

I did not make any specific comment on your disappointment with
the progress of the draft, but it would have been better to have comments
on the drafts as they were produced.  I remain committed to producing
a clear and implementable specification, and if you can be more specific
in some of the comments about clarity I will definitely appreciate that.

-- 
Regards,
Charlie P.

---

From: Don Sturek <[email-masked]>
Date: Wed, 20 Nov 2013 06:44:12 -0800

I am just wondering if consensus can ever be reached on the AODVv2 draft
given the recent reflector traffic.

Maybe the thing to do is to abandon the work and recharter.

Don

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 20 Nov 2013 16:54:21 +0100

<SNIP>

>> UH> That is still true. The draft is still very hard to read. The structure makes it very hard for implementers to follow the draft in an easy way (e.g., which steps do I have to perform when I receive a message / generate a message). I much prefer the document structure of the OLSRv2 draft.
>> There are several terms specified (e.g., routers client, upstream router) that are unclear how they affect the MANET architecture, and why existing terms (e.g., hosts) would not be sufficient.
> 
> I'll look at the need for "router client", but keep in mind that AODVv2 and AODV
> do not require that all nodes participate in the AODV protocol.  An AODV router
> those nodes which receive packets relayed by their first hop router which does
> run AODVv2.

Hang on......

What would the link model for *that* look like? 

Keeping in mind that applications and protocols (say, Neighbour Discovery) running on hosts typically do have specific expectations of a specific link model, and that those expectations most definitely are *not* satisfied on the interfaces-between-routers in a MANET in the general case. 

This does seem *really* problematic. This architectural point needs to be throughlyre-thought, in a way similar to how it is done in other routing protocols.

> About upstream and downstream -- if these are really confusing, please suggest
> alternative terminology.
> 
>> UH> In the black list section, there are many SHOULDs. It is unclear why they are not MUSTs, or what happens if an implementation decides not to do so. Text such as "The IP address of the node" is ambiguous: why node, not router? Which IP address? A router may have many interfaces, and each of them may have multiple IP addresses.
> 
> router, but a RREQ can be for a node that isn't a router.

No. An RREQ is for an addressable entity, typically called a host (or, "host interface"). That host interface  has an address. If that host interface is present in (aka, reachable by way of a router in) a network, then a router is configured to (i) respond to an RREQ for that address, and (ii) provide connectivity to/from that entity.

"Router" is the right word, we do not know what "node" is, and so an RREQ can't be for one.

> I think that,

That seems to be an extremely constraining restriction, in part because it would mean that you'd not be running IPv6.

I'm *very* surprised that multi-interface/multiple-addresses-per-interface has not been studied and resolved already: it's an almost trivially common case that routers have multiple interfaces, and it's equally trivially common that in IPv6, each interface has multiple addresses.

>> "The time at which Blacklist.Node will be removed from the blacklist.". What does "will" mean? MUST?
> 
>> UH> Notations such as "AddrBlk[1] - The first address slot in AddrBlk" still indicate requirement of address order in an address block. WG consensus was not to use that. Also, the text seems to indicate that there is a single address block. That would be against the intended RFC5444 architecture.
> 

The above is completely and utterly wrong.

When using RFC5444, you are (or rather, your message/packet generator is) able to organise addresses into address blocks so as to be able to do maximum "compression". It may be that this is a single address block, or it may be multiple address blocks. Each address has, then, semantics associated by way of TLVs. Each message/packet generator may do things differently, optimise for different things, but the beauty is that the "semantics associated only by way of a TLV association" ensures that any parser can parse a message correctly, regardless.

A protocol that assumes either positional semantics, or semantics of simple existence of an address in an address block, or that there is only a single address block in a message, is not using RFC5444 correctly (either, it leads to inefficiencies, or it leads to the inability to develop extensions - or, both - or to the inability to use generic packet/message generator/parser libraries).

I'm very surprised that the proper use of RFC5444 has not been assumed, especially since this has been pointed out ad infinitum, for /years/ on end, and is hugely important.

Frankly, I am getting more and more worried, the more of these exchanges that I see on this document. 
It seems that discussions are circling around the same few topics for years, without ever seeing any of them addressed by the author(s) by updating to the document.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Nov 2013 11:17:08 -0800

Hello folks,

Comments inline below...  but right now I'll have to skip over some
of the discussion about what happened in very old emails...

On 11/14/2013 9:05 AM, Jiazi Yi wrote:
> This issue, has been discussed for 1~ year in the working group. Most 
> of the participants (if not all the other), including Ulrich, Justin, 

Indeed, the order dependence for addresses in the AddrBlocks has been 
removed
by incorporating a suggesting by Henning.

>
>
> In the previous discussions, Ulrich, Henning, and Thomas have stated 
> why this is important. The feedback from Charlie is "I'm not at

Well, I went back to look at *that* email, and the interpretation
given is at least unfriendly.  Moreover, as pointed out above, the
requested dependence has been designed out.

> Defined in "Notational Conventions" section, and used in all over the 

I'm not sure exactly what the point is for this excerpt.

>> current specification is in conformance with RFC 5444.

Indeed, I will stand by that.  But that's what I think, and I am certainly
open to further discussion.

> editor thinks it is addressed).

Please do follow up with other issues that remain unresolved.
I have noted some new technical issues that were raised by Ulrich,
and I intend to somehow put them into the issue tracker soon.
If you would like to post specific issues to the issue tracker, that
would be quite welcome.

> who had been listed as co-author of dymo draft since 2005.

Since, Jiazi, you were in the room during the time in Taipei when this was
discussed, I don't think this is a reasonable characterization of the true
situation.

Regarding the activity of co-authors, I can point to many drafts and RFCs
that were published with inactive participants named.  Indeed, when
Mobile IPv6 was published, the lead author had not been active for years.

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Nov 2013 13:04:18 -0800

Hello folks,

I'm trying to identify the issues so that we can go about finding
technical resolutions.  Follow-up below:

> I believe that it would have behoved the authors to look through these reviews when reviving this activity, and to ensure that the comments were reflected in the document - or, deflected through di…

I have recently responded to some email from Ulrich which clearly 
pointed out
some issues.  If your issues overlap with his, then the resolution of 
the issues Ulrich
has raised will also take care of the above.  If not, then please let's 
get the other
issues out for discussion also.

> 	substantially revised to this effect.

The document has been revised to change the way RFC 5444 is used.  I do not
currently know what else needs to be done.  This claim was also made in 
other
emails, but given that the positional dependence has been designed out, 
I am not
sure what else remains.

> 	substantially revised to this effect.

There are only the three messages: RREQ, RREP, and RERR.  I don't think 
that state
machines are the best way to exhibit the simple flow of control for 
these messages,
but an appendix could be added for this purpose.

Since the flow of control is substantially the same as for AODV RFC 
3561, and people
had no trouble with that, I know it's quite easy to do.  I am quite open 
to suggestion
about how to make improvements; text is appreciated.

Would you like an introductory session that simply puts in the signaling
diagrams with no other explanatory material other than cross-references?

> 	substantially revised to this effect.

I really don't think that "client" and "node" are sloppy terminology!  A 
node can be either
a host or a router, so "host" is not an appropriate replacement. The 
number of IETF
documents using "client" and "node" terminology is pretty good 
indication that the
terminology is acceptable.  However, again, I am open to suggestion and 
especially
open to text contributions.

> 	But, I still believe that the document must be  substantially revised to this effect.

Security must be revisited, and I intend to do this.  If it takes a major
document revision, so be it, but first it has to be carefully discussed.
I will begin this process in some follow-on emails.

> 6) The document is ripe with options, often expressed vaguely "XX should be done, you can do that by, for example ZZ, YY or WW....", and that makes me worried. Options means code branches, which me…

Specific examples, please!  Usually, interoperability depends on the
messages sent or received, not the "way" a message is sent or
received.  Do you mean the algorithm by which a message is
produced?

> 	it's miles better to produce a document with that minimal "core", leaving options for a later

The document with mandatory behaviors and some optional behaviors
is a reformulation of features known for quite many years.  The existing
layout was produced in response to your previous request to locate the
optional features in document sections which were separated from the
mandatory features.  Many IETF protocols have various optional features,
and typically interoperability testing does not test them at the very
beginning.  Options are included often based on experience of the engineers
involved, and that is certainly true for the remaining options which are
specified in AODVv2.  Testing the options after testing the mandatory 
features
is simply the most sensible approach.  This is certainly nothing surprising!

> 7) Given that the above comments have been made ad infinitum since Maastricht, on the list and in WG meetings, without seeing any improvement of the document, it is hard to justify the efforts of m…

Indeed, I have incorporated revisions based on comments received,
including the separation of document sections, complete overhaul of
terminology, reduction of acronyms, designing out positional dependence,
simplification of the route table timeout structure, elimination of various
configuration parameters, and on and on.

I intend to be very responsive to current and future such requests.
It will be helpful if you can provide text.  I am sure that my good faith
is continually on display, and I hope you can identify those places
in the document which still need work.  The above comments are
mostly generic claims about past history, and I can't really locate the
parts of the current document to which they are supposed to be
relevant (except for occurrences of node and client).

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Nov 2013 13:23:37 -0800

Hello folks,

Follow-up below.

On 11/20/2013 7:54 AM, Thomas Clausen wrote:
>>> message / generate a message). I much prefer the document structure 
>>> of the OLSRv2 draft.
> Keeping in mind that applications and protocols (say, Neighbour 
> Discovery) running on hosts typically do have specific expectations of 
> a specific link model, and that those expectations most definitely are 
> *not* satisfied on the interfaces-between-routers in a MANET in the 
> general case.
>
> This does seem *really* problematic. This architectural point needs to 
> be throughlyre-thought, in a way similar to how it is done in other 
> routing protocols.

I am not at all sure how link model matters here.
Plus, Neighbor Discovery is not under discussion here, and
I do not see why it is relevant.

>>> not to do so. Text such as "The IP address of the node" is 
>>> ambiguous: why node, not router? Which IP address? A router may have 
>>> many interfaces, and each of them may have multiple IP addresses.
>>
> No. An RREQ is for an addressable entity, typically called a host (or, 
> "host interface"). That host interface  has an address. If that host 
> interface is present in (aka, reachable by way of a router in) a 
> network, then a router is configured to (i) respond to an RREQ for 
> that address, and (ii) provide connectivity to/from that entity.

Since your explanation agrees with my text, I am not sure about the
function of the word "No".

> "Router" is the right word, we do not know what "node" is, and so an 

This does not follow.  A RREQ can be for an address of a host that is 
not a router,
or for a router, so "node" seems quite suitable for this purpose.

However, if a definition for "node" is needed, I will insert one of the 
standard
definitions from other IETF documents.

> That seems to be an extremely constraining restriction, in part 
> because it would mean that you'd not be running IPv6.

No, it means that AODVv2 would only use one of the IPv6 addresses.
But whether or not the restriction would be imposed should be the
topic of additional discussion.  I don't think it needs to be imposed.

>
> I'm *very* surprised that 
> multi-interface/multiple-addresses-per-interface has not been studied 
> and resolved already: it's an almost trivially common case that 
> routers have multiple interfaces, and it's equally trivially common 
> that in IPv6, each interface has multiple addresses.

See above.  It's fine for any router to have multiple addresses.  I only
said that I need to check whether any difficulty arises given the current
document.  In all previous discussions on this point, no difficulties were
raised, and it has been discussed at various times in [manet] for the last
ten years.

>>> UH> Notations such as "AddrBlk[1] - The first address slot in 
>>> AddrBlk" still indicate requirement of address order in an address 
>>> block. WG consensus was not to use that. Also, the text seems to 
>>> indicate that there is a single address block. That would be against 
>>> the intended RFC5444 architecture.
>>

No, it's not.

>
> When using RFC5444, you are (or rather, your message/packet generator 
> is) able to organise addresses into address blocks so as to be able to 
> do maximum "compression". It may be that this is a single address 
> block, or it may be multiple address blocks. Each address has, then, 
> semantics associated by way of TLVs. Each message/packet generator may 
> do things differently, optimise for different things, but the beauty 
> is that the "semantics associated only by way of a TLV association" 
> ensures that any parser can parse a message correctly, regardless.

Basically, RREQ and RREP don't typically need any address compression,
and so we are left with the task of fitting the message requirements into
a packetization facility that was meant for something else.

>
> A protocol that assumes either positional semantics, or semantics of 
> simple existence of an address in an address block, or that there is 
> only a single address block in a message, is not using RFC5444 
> correctly (either, it leads to inefficiencies, or it leads to the 
> inability to develop extensions - or, both - or to the inability to 
> use generic packet/message generator/parser libraries).

How would you suggest that we put in RREQ or RREP addresses into
the packet?  If we're not supposed to put them into an AddrBlk, what
else is appropriate?

>
> I'm very surprised that the proper use of RFC5444 has not been 
> assumed, especially since this has been pointed out ad infinitum, for 
> /years/ on end, and is hugely important.

The proper use of RFC 5444 is that which conforms to the standard. If
there are some processing inefficiencies, that can be discussed.

> It seems that discussions are circling around the same few topics for 
> years, without ever seeing any of them addressed by the author(s) by 
> updating to the document.

Please relax and help to find the proper technical resolutions for the
above-mentioned issues.  I think my follow-up points have been responsive
to your questions, and I hope to get closer to resolution with each round
of discussion.

-- 
Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 20 Nov 2013 23:39:27 +0100

> On 20 nov. 2013, at 22:23, "Charles E. Perkins" <[email-masked]> wrote:
> 
> 
> Hello folks,
> 
> Follow-up below.
> 

ND, and other stuff that runs on a host, has expectations to the nature of the link. ND is an example - a highly relevant one, I'd say. I'm afraid that it's not clear what the authors are saying: if over the same interface a router can see another router AND a host, then the link has to behave as a host (or rather, protocols and applications on the host) expect. Otherwise, it's going to break stuff. For the end-users.

But, I am not even sure if that is what it is the authors are saying since the document (and, your email) is very unclear on also this point. It is, however, necessary to be *very* clear on this point. 

It may be that the authors want to say the right thing, but that the non-standard use of terminology makes it come across wrongly -- or, the authors are doing something very differently, but not defining and describing it.

Either way, this is symptomatic of the document: it requires a lot of interpretation and a lot of "guesses" to be made as to what the authors intended.

This has been brought up many times, by many different people, and we're *still* waiting for an effort to be made on that front....on a document that dates back to 2005....

> function of the word "No".

"No" as in "no, there is no good reason for using the term node".

> This does not follow.  A RREQ can be for an address of a host that is not a router,

No, it doesn't seem suitable at all, it's confusing.

> However, if a definition for "node" is needed, I will insert one of the standard

No. Use host and router, as appropriate. These are well-defined. Node is not.

> raised, and it has been discussed at various times in [manet] for the last

So, what is being said here is "the authors do not know how to do this yet"...in a document that dates back from 2005? 

FWIW, doing multiple-address/multile-interfaces correctly isn't trivial, especially not in MANETs.

>> The above is completely and utterly wrong.

Yes it is.

> a packetization facility that was meant for something else.

That is not at all the case. 

I do, btw., not see where you get "don't typically need any address compression" from, but it would be interesting to see the actual deployments in which you've made that observation.  But that's beyond the point I'm trying to make.

> the packet?  If we're not supposed to put them into an AddrBlk, what

In *an* address block, yes. But its not OK to make assumptions as to where in an address block an address is put, or how many address blocks there are or should be, nor that the simple presence of an address in an address block carries semantics.

> there are some processing inefficiencies, that can be discussed.

You keep stubbornly bringing out "processing inefficiencies that can be discussed".  It is *NOT*, about "inefficiencies"...and it has never been so. Kindly stop spreading such misinformation.

Proper use of RFC5444 is about generic packet/message generation and parsing logic. It is about writing /one/ parser for *all* 5444-messages. It's about designing protocols that are extensible, and extensions to protocols that can co-exist without conflicting.

And this document does - as has been pointed out over and over and over - not use RFC5444 properly.

> above-mentioned issues.
>   I think my follow-up points have been responsive

Reviews, comments have been provided in the past - and the comments given in 2010 have *still* not been taken on board (cf. this email).

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 20 Nov 2013 15:44:15 -0800

Hello again folks,

More follow-up inline...

On 11/20/2013 2:39 PM, Thomas Heide Clausen wrote:
>
> On 20 nov. 2013, at 22:23, "Charles E. Perkins" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>> Hello folks,
>>
>> Follow-up below.
>>
>>>>> structure makes it very hard for implementers to follow the draft 
>>>>> in an easy way (e.g., which steps do I have to perform when I 
>>>>> receive a message / generate a message). I much prefer the 
>>>>> document structure of the OLSRv2 draft.
>>>>> router) that are unclear how they affect the MANET architecture, 
>>>>> and why existing terms (e.g., hosts) would not be sufficient.
>>>>
>>> Discovery) running on hosts typically do have specific expectations 
>>> of a specific link model, and that those expectations most 
>>> definitely are *not* satisfied on the interfaces-between-routers in 
>>> a MANET in the general case.
>>>
>>> This does seem *really* problematic. This architectural point needs 
>>> to be throughlyre-thought, in a way similar to how it is done in 
>>> other routing protocols.
>>
> ND, and other stuff that runs on a host, has expectations to the 
> nature of the link. ND is an example - a highly relevant one, I'd say. 
> I'm afraid that it's not clear what the authors are saying: if over 
> the same interface a router can see another router AND a host, then 
> the link has to behave as a host (or rather, protocols and 
> applications on the host) expect. Otherwise, it's going to break 
> stuff. For the end-users.

This isn't true.  A router can see other routers and hosts over the same 
interface.
Links don't behave as hosts (I do not understand this).  Nodes on a link 
behave
according to whatever protocols they are running.  This does not break 
anything.

>
>
> Either way, this is symptomatic of the document: it requires a lot of 
> interpretation and a lot of "guesses" to be made as to what the 
> authors intended.

Is my statement above unclear?  Oftentimes, misunderstanding is
caused by preconceptions about what one *expects* another to say,
while missing what actually *was* said.

> "No" as in "no, there is no good reason for using the term node".

What about the reason that a node can be either a host or a router?

> No, it doesn't seem suitable at all, it's confusing.

??  I do not understand how to make it simpler.

> No. Use host and router, as appropriate. These are well-defined. Node 

I think the use of node to mean either host or router is well-defined.
http://www.ietf.org/rfc/rfc4294.txt for one example.

Quoting:
>     The goal of this document is to define the common functionality
>     required from both IPv6 hosts and routers.

Anyway, what alternative terminology would you suggest to enable
discussion of an IP addressable network entity in an ad hoc network that
could be either a host or a router?

>>> multi-interface/multiple-addresses-per-interface has not been 
>>> studied and resolved already: it's an almost trivially common case 
>>> that routers have multiple interfaces, and it's equally trivially 
>>> common that in IPv6, each interface has multiple addresses.
>>
> So, what is being said here is "the authors do not know how to do this 
> yet"...in a document that dates back from 2005?

Please do not twist my words.  Plainly, I meant that the issue has been
discussed and decided previously, but upon your request I am willing to
review the current document to see if there are any problems.

> trivial, especially not in MANETs.

I'll keep that in mind.

>
>>> When using RFC5444, you are (or rather, your message/packet 
>>> generator is) able to organise addresses into address blocks so as 
>>> to be able to do maximum "compression". It may be that this is a 
>>> single address block, or it may be multiple address blocks. Each 
>>> address has, then, semantics associated by way of TLVs. Each 
>>> message/packet generator may do things differently, optimise for 
>>> different things, but the beauty is that the "semantics associated 
>>> only by way of a TLV association" ensures that any parser can parse 
>>> a message correctly, regardless.
>>
> I do, btw., not see where you get "don't typically need any address 
> compression" from, but it would be interesting to see the actual 
> deployments in which you've made that observation.  But that's beyond 
> the point I'm trying to make.

Well, if there are only two addresses, and they're not aggregated into
any address prefix, I think the address compression isn't helping.
We are discussing ad hoc networks, and there may not be any subnet
aggregation whatsoever imposed on the nodes of the network.

> In *an* address block, yes. But its not OK to make assumptions as to 
> where in an address block an address is put, or how many address 
> blocks there are or should be, nor that the simple presence of an 
> address in an address block carries semantics.

If the protocol only needs one address block, I don't understand
the problem here.

>>> assumed, especially since this has been pointed out ad infinitum, 
>>> for /years/ on end, and is hugely important.
>>
> You keep stubbornly bringing out "processing inefficiencies that can 
> be discussed".  It is *NOT*, about "inefficiencies"...and it has never 
> been so. Kindly stop spreading such misinformation.
>
> Proper use of RFC5444 is about generic packet/message generation and 
> parsing logic. It is about writing /one/ parser for *all* 
> 5444-messages. It's about designing protocols that are extensible, and 
> extensions to protocols that can co-exist without conflicting.

So you want to know whether your parser can parse AODVv2 packets?
I guess I'll let you know the answer to that as soon as I find out.

> Reviews, comments have been provided in the past - and the comments 
> given in 2010 have *still* not been taken on board (cf. this email).
>

> configuration parameters, and on and on. 

It would be nice to find out how to resolve any remaining points
of difference.  Text will be appreciated.

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Nov 2013 03:30:32 +0100

I think the thing to do is direct thoes who discuss new ideas to work
in a DT with editors for AODVv2, and report the results within 45
days, similar to the DT for DLEP, this way we can get progress for the
charter item/work.

AB