RE: [manet] comments on draft-ietf-manet-nhdp-04.txt

["Templin, Fred L" <Fred.L.Templin at boeing.com>]

Chris - pls see my followups below:

Fred
fred.l.templin at boeing.com

> -----Original Message-----
> From: Dearlove, Christopher (UK) 
> [mailto:Chris.Dearlove at baesystems.com] 
> Sent: Friday, July 13, 2007 2:21 AM
> To: Templin, Fred L; manet
> Subject: RE: [manet] comments on draft-ietf-manet-nhdp-04.txt
> 
> 
> Thanks again, and inline comments >>> 
> 
> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin at boeing.com] 
> Sent: 12 July 2007 19:21
> To: manet
> Subject: [manet] comments on draft-ietf-manet-nhdp-04.txt
> 
> 
>                *** 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. 
> 
> Comments on this draft follow. By way of disclaimer,
> these comments are not to be considered as endorsement
> of the protocol's correctness and/or its applicability
> for any use-cases.
> 
> Fred
> fred.l.templin at boeing.com
> 
> 1) (semi-substantial) Section 1, first sentence, reference
> for "MANET" should be draft-ietf-autoconf-manetarch-04.txt
> (which in turn cites RFC2501).
> 
> >>> We haven't done this, because this is Standards Track,
> >>> and that's still only an ID. If it were an RFC (i.e.
> >>> been accepted) I'd happily reference it. But I'm not
> >>> sure right now. This we will need to discuss.

I am sure you have already guessed my response, but the
document already cites four works in progress so why not
this one too - especially since it presumably documents
*the* MANET Architecture.
 
> 2) (substantial) Section 2, definitions for {interface, MANET
> interface, link, symmetric link} need to be squared with
> draft-ietf-autoconf-manetarch-04.txt. In particular, there is
> a tension between "link" as "a communications facility at a
> layer below IP..." (per [MANETARCH], RFCs 2460/2461/2753, etc.),
> and "link" as a neighboring relationship between nodes (per this
> document) that needs to be harmonized.
> 
> Specific suggestion for "link" is:
> 
>   "Link
>       A communications facility at a layer below IP, over which nodes
>       exchange IP packets directly without decrementing IP TTL (Hop
>       Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said
>       to exists between two nodes X and Y if at least one node is
>       heard by the other on the underlying communications facility.
>       The term "link" in this document is therefore used to refer to
>       the pairwise links between two nodes unless otherwise noted."
> 
> >>> This one I want to think about. But I don't feel that we
> >>> automatically have to follow manetarch if it causes us
> >>> problems here.

The first part of the definition could cite RFC{2460,2461,3753}
instead, but [MANETARCH] would seem more appropriate.
 
> >>> And that's much too detailed for how we
> >>> need the word here, and is inconsistent with it - that
> >>> definition has a link between nodes, we have (and must
> >>> have) a link as between MANET interfaces.

The issue here is that there is a disparity between the two
uses of the term "link" that needs to be resolved to avoid
ambiguity. Perhaps you would be more amenable to the following
slight re-wording of the proposal:

  "Link
      A communications facility at a layer below IP, over which nodes
      exchange IP packets directly without decrementing IP TTL (Hop
      Limit) [MANETARCH]. A pairwise link (aka an adjacency) is said
      to exist between two MANET interfaces if at least one interface
      is heard by the other. The term "link" in this document is
      therefore used to refer to the pairwise links between two
      MANET interfaces unless otherwise noted."

> 3) (semi-substantial) Section 4.1, second bullet, "links to this
> MANET interface" makes no sense, because an interface is a node's
> attachment to a link; not vice-versa. Change to: "links associated
> with this MANET interface".
> 
> >>> That's not right, because it loses the "to". We only record
> >>> links which are to us, or to and from us (or lost examples
> >>> thereof).

OK to leave this one alone.
 
> 4) (comment) Section 5.1.1, should: "HELLO_INTERVAL" be called:
> "HELLO_MAX_INTERVAL" instead?
> 
> >>> No. Too cumbersome, and HELLO_INTERVAL isn't just the
> >>> maximum, in normal operation when nothing is changing
> >>> it is the HELLO interval.

OK.
 
> 5) (semi-substantial) Section 5.1.1, last paragraph, the term
> "responsive" is not previously defined and its use here seems
> ambiguous, e.g., what exactly is a "responsive HELLO message"?
> The term is used in 4 places throughout the document and seems
> ambiguous in all 4. Suggest adding "responsive" to terminology.
> 
> >>> See Section 4.3.1, second and third bullets.

That doesn't quite do it for me. What would work would be
to change: "As a response," to: "Responsively," in the
second bullet.
 
> 6) (semi-editorial) Section 6, last sentence of first paragraph,
> change: "Two addresses" to: "Two identical addresses".
> 
> >>> I see your point, but that actual change doesn't work for
> >>> me, as at this point what is "identical"? I think if it's
> >>> necessary to change that sentence (borderline in my
> >>> opinion) that's not the change I'd make.

How about:

  "Two addresses are considered equal if and only if they match
   and their associated prefix lengths are also equal."
 
> 7) (semi-substantial) Section 7, change: "links to that MANET
> interface" to: "links associated with that MANET interface".
> (Same comment as 3) above.)
> 
> >>> And see my comment above.

Acceptable.
 
> 8) (semi-editorial) Section 7, final sentence, same comment
> as 6) above.
> 
> >>> Ditto.

See above.
 
> 9) (semi-substantial) Section 15, if this document is to go as
> standards-track, "proposed" should be changed to: "recommended".
> 
> >>> Thanks.

OK.
 
> 10) (comment) Section 15.1, does the recommended HELLO_INTERVAL
> (HELLO_MAX_INTERVAL?) of 2 seconds relate in any way to the
> expected characteristics of the underlying communications
> facility? If so, maybe add a sentence saying so.
> 
> >>> It must (which is I think why we have had the proposed there).
> >>> There should be something.

OK.
 
> 11) (semi-substantial) Section 17, add [MANETARCH] as normative
> reference. 
> 
> >>> See above, I'm not entirely happy with this.

Actually, since [MANETARCH] is going as Informational, perhaps
citing as informative is sufficient?
 
> (end of comments)
> 
> 
> _______________________________________________
> manet mailing list
> manet at ietf.org
> https://www1.ietf.org/mailman/listinfo/manet
> 
> 
> ********************************************************************
> 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
manet at ietf.org
https://www1.ietf.org/mailman/listinfo/manet