Subject: [manet] AD review of draft-ietf-manet-olsrv2

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Jul 2012 19:45:55 +0100

Hi,

Don't be alarmed!

I have done an AD review of this document. The principal purpose of my
review is to catch issues that I find in the document and to ensure that
the work will get a smoother and more rapid progression through IETF
last call and IESG review.

My congratulations to the working group, and especially the editors, for
an extremely clear and readable document. I have only minor comments
that I suggest you handle along with any comments you receive during IETF
last call (which I will start shortly).

Thanks,
Adrian

===

Section 1

After the discussion on the list about the impact on the status of
RFC 3626, I suggest adding the following sentence to the end of the
first paragraph in Section 1

   This document does not obsolete [RFC3626] which is left in place for
   further experimentation.

---

Section 2

      Anycast
      addresses MAY be considered as routable addresses.

This is fine, but it would be helpful to explain why this is "MAY" not
may. The upper case gives a feeling that anycast addresses can be
present and normally not considered as routable, but sometimes (for some
unspecified reason) and implementation/deployment will consider them as
routable.

---

I like the appendixes and the fact that you have taken the time to
create examples. But appendix D contains 2119 language and this jars a
bit.

Is appendix D part of the normative text but moved to an appendix
because it is a meaty piece of text that would get in the way of the
flow of the main text (i.e. section 22 bullet 1)? If so, the appendix
should start with a statement that this appendix forms a normative part
of the specification, and a back pointer to section 22.

To a lesser extent, appendix E bothered me and I wondered whether you
would consider moving it to be a main section of the document.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 28 Jul 2012 12:30:04 -0700

Dear Adrian,

Detailed comments below.

Begin forwarded message:

> From: "Adrian Farrel" <[email-masked]>
> Subject: [manet] AD review of draft-ietf-manet-olsrv2
> Date: July 25, 2012 11:45:55 PDT
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked]
> 
> Hi,
> 
> Don't be alarmed!
> 

Thank you for your review, and for those kind words; we aim to please.

>   This document does not obsolete [RFC3626] which is left in place for

Sensible and reasonable suggestion, which we shall include.

> unspecified reason) and implementation/deployment will consider them as

Right; I do not really think that there's any good reason why it is "MAY" and not "may" - would it help to simply make this lower-case?

> create examples. But appendix D contains 2119 language and this jars a

As a first comment, this is done in OLSRv2 exactly as it was in RFC6130 (where the corresponding appendix is B, and we would much prefer to keep those two documents as similar in structure as possible.

That said, for appendix D, note that:

	o	The processing specified in the normative sections (1-27 -- i.e. non-appendices) ensures that
		these constraints are met. Thus, if one goes ahead and implements the protocol as specified,
		these constraints are satisfied.

	o	If any external process is modifying the recorded information, then that external process
		should be such that these constraints are not violated. Note that this specification does not
		specify such a process, just gives constraints that must be satisfied so as to not break OLSRv2

	o	An implementation, wanting to run sanity-checks on the recorded information, can do so according
		to this appendix; if a constraint is not met, then something in the processing code has borked up, 
		be that either the implementation of the processing in sections 1-27, or some external process
		updating the same information sets.

Another way of putting the above is, that appendix D doesn't prescribe behaviour of the protocol specified in this document, but rather provides constraints which must be respected for the case where another process/protocol wishes to update the information sets used by this protocol.

> of the specification, and a back pointer to section 22.

The answer is No.  

This wasn't a piece of text moved to an appendix so that it wouldn't get in the way, but rather because it's providing a framework of constraints for guiding "extensions"/external processes wanting to interact with OLSRv2. The processing in the numbered sections respect these constraints already.

Thus, appendix D does IMO not belong in the main part of the text (the numbered sections), but definitely in an appendix. Also, I do think that this precisely is one of the (very few) cases where 2119-language is appropriate in an appendix.

> would consider moving it to be a main section of the document.

As a first comment, this is done in OLSRv2 exactly as it was in RFC6130 (where the corresponding appendix is D, and we would much prefer to keep those two documents as similar in structure as possible.

As a second comment, this appendix definitely isn't prescriptive in nature, but rather reflects on the signalling nature of the protocol (and exists since, eons ago, there was a requirement that all protocol specifications have a "Flow and Congestion Control" appendix).

Best,

Thomas

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet