Re: [manet] draft-ietf-manet-nhdp - WGLC - ends Feb 3rd

["Ian Chakeres" <[e-mail]>]

Overall I think the document is in good shape.

I have included my detailed comments on the document below.

Ian Chakeres

Note: I have a few other issues that I will raise in separate emails.

===
Please qualify all uses of - this/these. In several places these words
(this/these) are left hanging with an object.

3rd paragraph of Section 1 is redundant.

Address, with prefix length, should be added to the terminology. This
change would result in less redundancy within the text.

Section 3 - I found the applicability statement a little hard to read
given its bulletized form, but generally agree with the content.

I think bullets 3 can be cut.

Bullet 4 - I feel that this specification should recommend using UDP, and not
specify using the IP protocol number. As Teco has brought up - passing
PacketBB packets directly over IP will likely require some additional
functionality.

Bullet 5 - the second sentence can be cut.

Section 4

/is,/is/

cut " of which ... may be a part"

/Discovers links from adjacent nodes/Discover adjacent nodes/ OR
/Discover links between adjacent nodes/

I am not sure if there is a difference between signaling and
exchanging control messages. Either way, it might be good to remove
signaling or define it.

Section 4.1. I think the last paragraph can be cut.

Section 4.1. I think the term "configured" interface should be
added/referenced. Essentially, I see no reason why NHDP needs to
participate on all possible MANET interfaces. I also see no reason
why NHDP needs to advertise all its interfaces. I think the NHDP
process should be cap cable of operating on less than all physical
interfaces if so configured. This may affect text in other locations.

Section 4.3.1 - When would jittering of hello messages be
"appropriate". Perhaps "SHOULD be used if appropriate" could simply be
removed.

Section 4.3.1 last sentence. I feel the last sentence could be cut.

Section 4.3.2 - Can a default value for VALIDITY TIME be set on nodes
themselves or does it need to be included in every message?

/thsi/this - I think this was reported before

Section 4.3.3 - In several places within the document the constraints
have been placed inline. Why are the constraints for this section
placed in an appendix?

Section 5.4 seems useless. I think C should be defined early on,
perhaps with discussion of VALIDITY_TIME and INTERVAL_TIME.

Section 9.2 last sentence, please place "Afterward," before the start
of the sentence.

Section 9.3 last sentance, please place "Afterward," before the start
of the sentance.

Section 10. I think that bullets 3&4 should be deleted.

The document should specified that the IP.TTL/HopLimit of the
containing packet be set to 255. GTSM methods (RFC 5082) should also
be used for HELLO packets.

Again, I think we should recommend using UDP right now. In the future
we can specify some additional mechanisms for moving packetbb packets
directly over an IP protocol number.

Section 10.1.1 - Please remove or explain the purpose of UNSPEC_IF.

Please change places that say 8-bits to 1-octet. I believe packetbb
only allows octet based values.

If valid messages are received, but they contain duplicate information
how should they be handled? For example, they contain the same address
twice. Perhaps, I missed the mention of handling well-formed but
bad-content messages.

Section 12 is the order of performing the various updates described in
this section important?

Section 13.1 - there is a hanging "are removed." please pull this up
with the previous sentance. I think that sentance can even be pulled
up with the one above it.

Section 13. I became a little confused by the bullets and their
depth. Is there a common scheme to the various bullet styles used? For
example, numbers ordered checks, + secondary checks, - set something,
o event.

Section 13.2 please add OR or AND following "contained in
N_neighbor_iface_addr_list;".

Section 14. I support Omprakash's proposed addition regarding using
unicast success/failure rates.

Section 14.3 - the last sentance in this section is contained in
parenthesis is very complex and not well structured. Please revise it.

Section 14.6 - it might be nice to reference
VALIDITY_TIME/INTERVAL_TIME and the TimeTLV spec in this section. I
think it would be good to explicitly say that C MUST be set the same
on all nodes here.

Section 16, I was confused about how appendix C provides protection. I
think we discussed this briefly once, but I think a little more text
could help.

Section 16. I think there should be some mention of authentication as
all the information contained in HELLO messages should likely be
authenticated in more secure environments.

Section 17.2. Why are all Type extensions reserved? I think these
should be left open for allocation via standard actions. I believe
that is what is recommended, but the term RESERVED seems to indicate
otherwise. I would suggest removing these RESERVED spaces.

Appendix B - /by IP/by the IP header/

Appendix C in the list following Lost Neighbor Table - the third
bullet has some spacing problems - please fix if possible, since "==
true" falls onto the next page.

Appendix D - I think that this section should be re-named "HELLO message
Generation Rate" and be elevated to a normal section.
===




On Jan 18, 2008 12:16 PM, Ian Chakeres <[e-mail]> wrote:
> This note announces the WG Last Call for comments on
> draft-ietf-manet-nhdp-05.txt, "MANET Neighborhood Discovery Protocol
> (NHDP)".
>
> The document can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-05.txt .
>
> The document is intended to be submitted for publication as a proposed
> standard document.
>
> Please review the document carefully and send your comments to the
> MANET list and document authors ASAP.
>
> This last call will end Sunday Feb 3rd.
>
> Thanks,
> Ian Chakeres
>
_______________________________________________
manet mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/manet
From [e-mail]  Fri Feb  1 04:54:52 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id F33F528C1E3;
	Fri,  1 Feb 2008 04:54:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id n4V8gdzFAJIH; Fri,  1 Feb 2008 04:54:51 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C26563A690E;
	Fri,  1 Feb 2008 04:54:50 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3476E3A680E
	for <[e-mail]>; Fri,  1 Feb 2008 04:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 3GVH0B+QOHax for <[e-mail]>;
	Fri,  1 Feb 2008 04:54:49 -0800 (PST)
Received: from hpsmtp-eml15.kpnxchange.com (hpsmtp-eml15.kpnxchange.com
	[213.75.38.115])
	by core3.amsl.com (Postfix) with ESMTP id EF1843A690E
	for <[e-mail]>; Fri,  1 Feb 2008 04:54:48 -0800 (PST)
Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by
	hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Fri, 1 Feb 2008 13:56:23 +0100
Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Feb 2008 13:56:13 +0100
From: "Teco Boot" <[e-mail]>
To: "'Dearlove, Christopher \(UK\)'" <[e-mail]>
References: <[e-mail]>
	<000e01c8632d$26e1ceb0$74a56c10$@nl>
	<[e-mail]>
In-Reply-To: <[e-mail]>
Date: Fri, 1 Feb 2008 13:56:07 +0100
Message-ID: <000601c864d1$d33334b0$79999e10$@nl>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AchZnesn6DZB33F3QyuwVIYSGhGRUwJcz75AAD+ozGAALt6LoA==
Content-Language: nl
X-OriginalArrivalTime: 01 Feb 2008 12:56:14.0245 (UTC)
	FILETIME=[D3AECD50:01C864D1]
Cc: 'manet' <[e-mail]>,
	"'Thomas Heide Clausen \(work\)'" <[e-mail]>
Subject: Re: [manet] draft-ietf-manet-nhdp - WGLC - ends Feb 3rd
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile Ad-hoc Networks  <manet.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/manet>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/manet>,
	<mailto:[e-mail]?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Errors-To: [e-mail]


> > IP & UDP as transport:
> 
> As NHDP isn't a full protocol, this should be devolved to the
> protocol using it. Really this is a higher level WG issue, the
> whole "what is the architecture?" that draft-iana didn't cover.
> 
> > And it affects rules for message aggregation.
> 
> That I don't see at all. Message aggregation is quite separate from
> what transports the packetbb structure.
> 
[Teco:] 
When one protocol uses IP and the other UDP, and we want to use commonly
NHDP and message aggregation and even sharing the same message by adding
TLV, thinks are getting complex.


> > And the missing UDP fields length and checksum when running over IP.
> 
> You're not missing length - IP has a length field.
[Teco:] 
OK. Not as straightforward as UDP length, but it works.

> >Page 28:
> >>> All addresses in a node's Local Interface Set (i.e. in any
> >>> I_local_iface_addr_list) MUST be included in the address blocks in
> >>> all generated HELLO messages with the following exception.
> >Why MUST? Using a single address for NHDP and a summary prefix for TC
> >would work and is more efficient.
> 
> First, TC messages aren't part of NHDP, so you can't build an
> NHDP that relies on TC messages to work. Second, be very careful
> of "would work". A lot of ideas that appear to work actually don't,
> especially with multiple interfaces. (Thomas has an unpublished
> half a dozen ways to do multiple interfaces that superficially
> appear to work, but actually don't.)
[Teco:] 
Assume I want to use NHDP and OLSRv2.
I want to reduce overhead as much as possible.
I assign an address block to the router, each interface has one or more
subnets from the assigned block.
I want to advertise a single aggregation, as this is assigned to the router.
--> OLSRv2 needs support for aggregation
--> NHDP needs a tool for reducing sending lots of prefixes.
NHDP does not use Router Identifiers, correct? 
NHDP neighbors are identified by all their addresses, correct? Is this the
reason for _MUST_?
What about anycast?

> 
> Page 33:
> > On receiving hello messages, do we need a check on sender address,
> > that there is at least a matching prefix assigned on the receiving
> > interface?
> 
> Well, we use the sender address in lieu of a single interface address.
> Yes, we could check that otherwise is the sender address covered by
> one of the sent local interface adddresses with THIS_IF. That may
> be a good idea. We could check sender addresses even more rigorously,
> are they appropriate to the subnet that the receiving node thinks its
> on. That's an alternative to MANET_ID. I don't think NHDP is the right
> place to mention this, except possibly as a MAY aside to checking
> sending address.
[Teco:] 
Maybe NHDP assumes there is a link, but user traffic cannot make use of it
because addresses are not on same subnet.

> 
> > When using maximum prefix length (32 bits IPv4), are we sure there is
> no
> > problem with other protocols (e.g. ARP)?I don't think so.
> 
> I'm not aware of a problem here.
[Teco:] 
Many IPv4 stacks have a restriction on using /32 mask on multi-access
interfaces.
I verified on well known OS and router equipment.

And when configured, protocols could assume that an interface with only a
/32 mask cannot have a link to another host.
I saw problems like this with /32 on a Linux 2.4 IP stack.

Teco.

_______________________________________________
manet mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/manet
From [e-mail]  Fri Feb  1 06:23:29 2008
Return-Path: <[e-mail]>
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3FEC8293888
	for <[e-mail]>; Fri,  1 Feb 2008 06:20:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 53.731
X-Spam-Level: *****************************************************
X-Spam-Status: Yes, score=53.731 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889,
	HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, NORMAL_HTTP_TO_IP=0.001,
	RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5,
	RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905,
	RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1,
	SARE_HELO_EQ_DSL_3=1.022, URIBL_BLACK=20, URIBL_WS_SURBL=10]
X-Spam-Report:
 *  3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
 *      [score: 1.0000]
 *  1.9 FH_HOST_ALMOST_IP The host almost looks like an IP addr.
 *  1.1 HELO_EQ_DSL HELO_EQ_DSL
 *  1.0 SARE_HELO_EQ_DSL_3 SARE_HELO_EQ_DSL_3
 *  5.4 FH_HELO_ALMOST_IP Helo is almost an IP addr.
 *  1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP)
 *  0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL
 *  1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
 *      above 50%
 *      [cf:  95]
 *  0.5 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/)
 *  0.5 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50%
 *      [cf:  95]
 *  0.9 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
 *      [41.244.223.183 listed in dnsbl.sorbs.net]
 *  0.9 RCVD_IN_PBL RBL: Received via a relay in Spamhaus PBL
 *      [41.244.223.183 listed in zen.spamhaus.org]
 *  3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
 *   20 URIBL_BLACK Contains an URL listed in the URIBL blacklist
 *      [URIs: 121.141.196.217]
 *  2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 *      [Blocked - see <http://www.spamcop.net/bl.shtml?41.244.223.183>]
 *   10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
 *      [URIs: 121.141.196.217]
 *  0.1 RDNS_DYNAMIC Delivered to trusted network by host with
 *      dynamic-looking rDNS
Received: from core3.amsl.com ([127.0.0.1])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id nypc1e98ejP1
	for <[e-mail]>;
	Fri,  1 Feb 2008 06:20:16 -0800 (PST)
Received: from dsl-244-223-183.telkomadsl.co.za (dsl-244-223-183.telkomadsl.co.za [41.244.223.183])
	by core3.amsl.com (Postfix) with SMTP id 3948728D71A
	for <[e-mail]>; Fri,  1 Feb 2008 05:51:47 -0800 (PST)
Received: from uazj ([149.97.103.172])
	by dsl-244-223-183.telkomadsl.co.za (8.13.3/8.13.3) with SMTP id m11DsPBw037408;
	Fri, 1 Feb 2008 15:54:25 +0200
Message-ID: <[e-mail]>
Date: Fri, 1 Feb 2008 15:53:20 +0200
From: <[e-mail]>
User-Agent: Thunderbird 1.5.0.13 (Windows/20070809)
MIME-Version: 1.0
To: [e-mail]
Subject: ***SPAM*** 53.731 (5) More inches of pleasure!
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

YourHealth provided here http://121.141.196.217/ebttl/