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

[Thomas Heide Clausen <[e-mail]>]

All,

On Feb 1, 2008, at 2:02 PM, Dearlove, Christopher (UK) wrote:

>
> Comments inline below as >>
>

Chris, it'd help in the readability department if you could make the  
quoted text start by >, rather than your text -- I constantly find  
myself confused ;)

Comments below - mostly stating my agreement.

<SNIP>

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

Agreed.

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

Yup, but we should be able to handle that.

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

I agree with Chris here, this bullet is important and not redundant.

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

Chris has a good point, which is that an architectural discussion of  
how the different pieces of the MANET wg deliverables fit together,  
and what complications exist, belongs somewhere. The thing is, that  
this is not the place. Nor do I know where would be a good place,  
unfortunately.

But, the above is not the spirit of this bullet-point anyways: what  
this bullet says is, simply, "an implementation of this protocol can  
live entirely in user-space, using nothing other than the ability to  
transmit and receive broadcast packets".


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

I think that it is important to keep in mind that this functionality  
is inheritance from packetbb, which explicitly is designed to allow  
this. That said, I feel that it is useful to repeat since -- indeed  
-- the specification respects that inheritance.

<SNIP -- I'll leave the native English speakers determine the correct  
usage of punctuation and such>

> Section 4.1. I think the last paragraph can be cut.
>
>>> Definitely not, this is important.
>

Agree with Chris here, this is very 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).

Hmm...I think that I know what Ian is saying, or at least aiming at,  
here. The short answer is that "all IP addresses that one wants ones  
neighbours to know about should be advertised", be that MANET or  
other interfaces.  Yup, therefore said that for an interface that one  
does not want seen in that MANET, one simply does not advertise its  
addresses. I guess that Ian is thinking about the "running-multiple- 
protocol-instances-on-a-node" issue here?

I think that a reasonable resolution could be akin to saying (this is  
not proposed text, just the spirit): "all IP addresses of interfaces  
that one wants to be known within the MANET are recorded in the Local  
Interface base" ?

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

I'm not crazy about the suggested change. I definitely think that it  
needs be there -- and I think that a reference to draft-ietf-manet- 
jitter might be what's needed, not additional explanations here?

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

The question has been explicitly asked and so I agree with Chris that  
the answer given by that sentence is important.

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

agreed.

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

I actually like thsi better than this...but it seems that the  
overwhelming hum in the WG disfavours creative spelling, so I'll bend  
to consensus on thatone ;)

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

I agree with Chris -- but maybe we can make this a notch more clear  
by adding a phrase to this effect?

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

Agree with Chris on this matter -- it's part of the inheritance from  
that-other-document.

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

Agree with Chris.

> Section 10. I think that bullets 3&4 should be deleted.
>
>>> I don't agree, especially for bullet 4.
>

I think that both 3&4 are important. They may be obvious when knowing  
the protocols / documents, but I think that they are helpful to avoid  
mistakes. I'd want to keep those.

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

I'd like to ask if Ian could educate me as to why you think that this  
is necessary? I'm not disagreeing, I'm trying to form an informed  
opinion ;)

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

Whoops, no, I think that this would be premature to do so.

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

Agree. Can't remove, will explain ;)

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

Agreed, good catch - thanks.

<SNIP>


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

Again, good catch -- thanks!

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

I'd vote for "as-is". I can see both arguments, but it's more  
coherent with the way the rest is written as it is.

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

I'd add to that that we're sticking to feeding xml2rfc basic xml- 
stuff, and that the rfc-editor when converting to nroff (they still  
do that, right?) make sure that things are coherent. We try to use as  
simple/standard xml to feed xml2rfc since it's easier for our rfc- 
editor-friends to process stuff automatically that way.

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

AND, I think,....thanks!

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

I agree that it can be added among the examples, but as I have  
indicated in another email, an exhaustive list of examples can become  
very very very long.....and not appropriate. If it's just that  
example then sure, why not?

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

I'll leave that to our professional Englishman (that'd be you, Chris)  
to deconvolute that.

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

Agreed.

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

The way I think of App. C is to say that "iff you do something other  
than what comes from the message exchange in this specification, then  
you must ensure that the following is respected -- or you'll  
definitely break stuff".

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

I think that we need to, on the one hand, cross blades with the sec  
ADs / sec-dir, and on the other hand consider the comments the sec- 
dir had to packetbb.

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

I believe that it is right as it is, as per [6].

> Appendix B - /by IP/by the IP header/
>
>>> Not fussed either way myself.

I'll leave this to the native English-speakers ;)

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

I guess that we'll note this, sit on it for now, and make sure to  
check that with the RFC editor down the line.

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

Agree with Chris.

Thomas

_______________________________________________
manet mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/manet