Subject: [Gen-art] Gen-ART LC review of draft-ietf-ospf-manet-or-01

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Dec 2008 15:47:21 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ospf-manet-or-01
Reviewer: Ben Campbell
Review Date: 2008-12-23
IETF LC End Date: 2008-12-24
IESG Telechat date: (if known)

Summary:  This draft is almost ready for publication as an  
experimental RFC. I have a few questions/comments, and a few nits,  
that should be considered prior to publication.

Substantive Comments/Questions:

-- Section 3.1.1, last paragraph:

Why is this a SHOULD and not a MUST? Does anything break if it is not  
followed?

-- Section 3.2.8:, paragraph 2:

How do you identify a wrap around? I can infer how, but better to be  
explicit.

-- Section 3.3.2. paragraph 3: "Each speaker SHOULD select..."

SHOULD use a selection algorithm is vague without some statement of  
the properties of the algorithm. You list an example. Are you saying  
that the speaker SHOULD select an alogorithm with properties similar  
to the example? (I see that you commented on this in section 3.3.4,  
but it is confusing not to find the answer nearer to the normative  
requirement in this section. I suggest moving or replicating that  
statement to this section.)

-- section 3.3.4, last paragraph:

Is the requirement for all nodes in an area to use the same algorithm  
a problem, if the algorithms are implementation specific? Are  
different implementations not expected to interoperate? Do they need  
to negotiate the algorithm selection?

-- Section 4:

Is the lack of any existing mechanism to authenticate and authorize  
nodes to transit packets a show stopper for deployment?

If this was standards track, I would want to see a lot more here, e.g.  
some exposition of threat models implied by the wirelessness, or  
introduced by the extensions and procedures described in this draft.  
(Or rational that there are not any new threat models)  It's probably  
okay for an experimental RFC to have less, as I assume we expect to  
learn such things from experience. But if any thinking has been done  
in that direction, it would be beneficial to document it now.

Nits and editorial comments:

-- Don't forget new boilerplate (I know the boilerplate situation is  
messed up, so I don't know how to proceed on this one. I mention it  
for completeness.)

-- Outdated reference to draft-ietf-ospf-lls-05. Version 06 is out as  
of now.

-- The draft has lots of references to other internal sections by  
title only. This creates extra work for the reader to follow the  
references. It would be helpful to include the section numbers in such  
references.

-- Section 3.1, paragraph 2:

It's not clear to me if the "MAY" constrains protocol, or constrains  
future standards work. If the second, it probably should not use 2119  
language.

-- Section 3.3:

Redundant "only" in 2nd sentence.

-- Section 3.3.10: PushBackInterval

Referring sections mention PushbackInterval + jitter. Jitter is not  
mentioned here--is propagation delay the same thing in this context?  
If so, it would be helpful to be consistent in terminology.

-- Section 3.5.3, paragraph 1:

s/defined synchronized/defined to be synchronized   ; or "defined as  
synchronized"

-- Section 5, LD Options registry creation:"... require IETF standards  
action"

Does that require them to be documented in standards-track RFCs? If  
so, I must point out that _this_ draft is experimental.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art