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

["Dearlove, Christopher (UK)" <[e-mail]>]

Comments inline below as >> 

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: [phone]  Fax: [phone]

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: Ian Chakeres [mailto:[e-mail]] 
Sent: 01 February 2008 12:13
To: manet
Cc: Joe P Macker (home); Dearlove, Christopher (UK); Thomas Heide
Clausen (work); Justin Dean (work)
Subject: Re: draft-ietf-manet-nhdp - WGLC - ends Feb 3rd


               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

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.

>> Almost. The reference to [1] needs to be saved.

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

>> Agree, although a little care needs to be taken because of
>> protocols (such as OLSRv2) which also use addresses (for
>> OLSRv2 originator addresses) without prefix lengths.

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.

>> No, I don't agree. Bullet 3 is saying something (two things
>> in fact) important that should be in this section, and isn't
>> in any of the other bullets.

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.

>> What's the point of our having defined the protocol in
>> draft-iana if we never use it? I agree there's a compatibility
>> issue, and this is part of a whole architecture discussion we
>> haven't had. I disagree with Teco's point and have said so.

Bullet 5 - the second sentence can be cut.

>> Do you mean bullet 6? I think the second sentence adds something
>> that matters for example when using NHDP as part of OLSRv2 (or
>> a DYMO extension).

Section 4

/is,/is/

>> If you mean in the first line, I don't agree.

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

>> Don't agree. Or at least this is an important point to be made
>> somewhere related to this.

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

>> I would suggest Discover links with adjacent nodes. Discovering
>> nodes isn't enough, and the between version isn't clear that this
>> is one of those 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.

>> I think there's no difference, and one term for one thing is good.

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

>> Definitely not, this is important.

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.

>> That wants further thought. Note that if you don't advertise an
>> interface, then to all intents and purposes it doesn't exist
>> externally - you can't get to it. Of course outside NHDP there
>> are alternatives (using TC messages in OLSRv2 for example) but
>> these have a cost (making nodes send TC messages unnecessarily,
>> which is bad).

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

>> When the physical/data link layers need it (802.11 for example).
>> I don't agree with the suggested change, but may want to think
>> about the sentence.

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

>> No, that's important. It's a question an implementor may very
>> well ask, that needs an answer.

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?

>> Needs to be in every message. That's a deliberate design, which
>> dates back to OLSRv1.

/thsi/this - I think this was reported before

>> Everyone's favourite correction. I think we first got it before
>> leaving Vancouver, and I think we're up to about half a dozen
>> spottings. Proves people read it though.

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?

>> This is different. This doesn't specify the constraints, it says
>> that if you follow the instructions then the constraints will be
>> maintained.

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

>> I think 5.4 is presenting this information in the right place.
>> There's a clear development in the document of parameters,
>> data structures, messages, processing, and this is the right
>> place. We also don't intend to discuss the two TLVs in detail
>> - we put them into a separate document to avoid doing that
>> here and again in OLSRv2. But this section also needs an
>> addition to discuss signalled values (HEARD etc.) and PENDING.

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.

>> I don't like that exact way of achieving your point, but I agree
>> that it should be clarified this is afterward.

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

>> I don't agree, especially for bullet 4.

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.

>> I'll reserve comment for now.

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.

>> See comment above.

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

>> Definitely not removing it - we need it in OLSRv2, and defining it
>> without this, then adding it in OLSRv2 would be a real nuisance.
>> But we can explain (without explicit reference to OLSRv2).

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

>> The latter is true, and I think this is a good change.

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.

>> Duplicate information is ill-formed, see packetbb.

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

>> Yes. Your obvious implication, that section 12.0 (to use an
>> obvious notation) should say so, is correct.

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.

>> I'm not going to say yes or no to this one right now, I can see both
>> why it is as it is, and why you may not like 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.

>> It's what xml2rfc gives you, no human control. I have absolutely
>> no idea what algorithm it uses, except different levels have
>> different symbols.

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

>> Good catch. I think it's AND, but will confirm.

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

>> It's appropriate to add it as an example in the first bullet
>> of 14.4, but not more.

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

>> Comment noted.

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.

>> I don't have a 14.6. If you mean 15.6, I think it's appropriate
>> to reference [3], but not the TLVs explicitly. But that C is the
>> same for all nodes - see Section 2.

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.

>> Appendix C is there not for NHDP as implemented by this specification
>> (although it may be informative). It's there because people (from
>> NRL in particular) wanted to be able to modify the protocol sets
based
>> on other information. That permission is there (I'm not going to look
>> for the section). But unrestrained modification could really mess
things
>> up, and Appendix C is there to say "if you change the sets don't do
that".

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.

>> I'll reserve comment for now.

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.

>> See the last sentence in section 17.2.

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

>> Not fussed either way myself.

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.

>> That's what automated tools do for you.

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

>> Everything significant said is already specified in the main
>> sections. This is essentially just a commentary on those, and
>> as such I think an Appendix is right.


********************************************************************
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.
********************************************************************

_______________________________________________
manet mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/manet
From [e-mail]  Fri Feb  1 09:53:03 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 ED62C3A67F2
	for <[e-mail]>; Fri,  1 Feb 2008 09:53:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 57.292
X-Spam-Level: *********************************************************
X-Spam-Status: Yes, score=57.292 tagged_above=-999 required=5
	tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, 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_XBL=3.033,
	RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001, TVD_SPACE_RATIO=2.219,
	URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10]
X-Spam-Report:
 *  3.5 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
 *      [score: 1.0000]
 *  1.1 HELO_EQ_DSL HELO_EQ_DSL
 *  1.5 FH_RELAY_NODNS We could not determine your Reverse DNS
 *  1.4 HELO_DYNAMIC_DHCP Relay HELO'd using suspicious hostname (DHCP)
 *  0.0 STOX_REPLY_TYPE STOX_REPLY_TYPE
 *  0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL
 *  2.2 TVD_SPACE_RATIO BODY: TVD_SPACE_RATIO
 *  1.5 RAZOR2_CF_RANGE_E8_51_100 Razor2 gives engine 8 confidence level
 *      above 50%
 *      [cf: 100]
 *  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: 100]
 *   20 URIBL_BLACK Contains an URL listed in the URIBL blacklist
 *      [URIs: 65.96.224.99]
 *   10 URIBL_WS_SURBL Contains an URL listed in the WS SURBL blocklist
 *      [URIs: 65.96.224.99]
 *   10 URIBL_JP_SURBL Contains an URL listed in the JP SURBL blocklist
 *      [URIs: 65.96.224.99]
 *  2.0 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 *      [Blocked - see <http://www.spamcop.net/bl.shtml?201.221.140.9>]
 *  3.0 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
 *      [201.221.140.9 listed in zen.spamhaus.org]
 *  0.1 RDNS_NONE Delivered to trusted network by a host with no 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 1VRdPiGx6dUL
	for <[e-mail]>;
	Fri,  1 Feb 2008 09:53:03 -0800 (PST)
Received: from adsl-ultra-pool4-221140-9.telebucaramanga.net.co (unknown [201.221.140.9])
	by core3.amsl.com (Postfix) with SMTP id 9F4973A6785
	for <[e-mail]>; Fri,  1 Feb 2008 09:53:02 -0800 (PST)
Received: from ugu ([146.211.219.143]) by adsl-ultra-pool4-221140-9.telebucaramanga.net.co with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Feb 2008 12:51:38 -0500
Message-ID: <001801c864fb$1865e900$8fdbd392@ugu>
From: <[e-mail]>
To: <[e-mail]>
Subject: ***SPAM*** 57.292 (5) Love Remains
Date: Fri, 1 Feb 2008 12:51:38 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Destiny http://65.96.224.99/