Dear WG Chairs, 
Dear Chris, all,

As the author indicated by email recently, he believes that draft-ietf-manet-olsrv2-management-snapshot is ready for WGLC. 

As a reminder, this document aims for publication as a Proposed Standard.

I have, therefore, reviewed the document carefully. In my opinion, the author is right — in my opinion this document is ready for WGLC.

Moreover, I believe that it is a highly important document for the WG to produce, as it fills a real need, and does so by relying on already-published crypto RFCs, rather than by coming up with something esoteric.

I have two issues, and handful nits, that I expect the author will consider along with any other WGLC comments they may receive. Of course, if a new version is spun before WGLC is requested, then I’ll gladly review that, also. Point being: let’s get a call started on this document, none of my nits and issues are of the sort that should be blocking.

One of the issues is “need a non-jetlagged ADs advice to be sure we do the right thing”, the other is — I think — a minor mix-up with a trivial editorial resolution and zero technical impact on this specification.

Either way, for information, I include all issues and nits that I’ve found in the below.

Issues:

	o	In my opinion, “Updates 7182” is inappropriate. What this document does is:
			(i) 	only things permissible by RFC7182, and 
			(ii) 	makes registration from IANA registries set up by RFC7182
				(noting, of course, that RFC7181 doesn’t “Updates 5444” 
			 	 when making registrations for TC messages from the repositories 
				 set up by RFC5444 as a case of precedent)
		Consequently, I believe that the abstract, introduction, and document 
		header, needs updates to reflect that this is not an update.
		
		Caveat Lector: I have bounced this around with the author, and I 
				think that the conclusion is that we need just a friendly 
				ADs opinion — my understanding is that the author
				“wants this out, but wants it done right, also”, something
				to which I can but adhere.
		
				I believe that we should WGLC the document. If the AD
				finds the time to address this issue during WGLC, great -
				otherwise, we can reflect this in the “Document Writeup”
				that the AD will consider with the publication request — as
				this (imo) is procedural/editorial, and certainly not technical.

	o	Introduction, 4th paragraph:

		Isn’t it RFC7183 which does shared-secret-key ICVs? I just did a quick
		grep through of “shared” in 7182, and found just a few mentions, notably
		setting a side a value for key-id-length in that case. And “secret” is not
		mentioned anywhere in 7182


Nits:
	o	Introduction, 1st paragraph:
		OLD:
			This specification extends the TLV definitions
			therein by defining two new cryptographic function code points that
			allow the use of an identity-based signature (IBS) as an ICV.

		NEW:
			This specification defines two new cryptographic function 
			code points from within the registries set up by [RFC7182], 
			that allow the use of an identity-based signature (IBS) as an ICV.

	o	Introduction, 2nd paragraph, 1st line:
		I took a double-take when I saw the parenthesis 
		“(protocol participant)” — that seems a little odd, and I am on a crusade
		against redundant and hard-to-parse terminology ;)

		I think that what is meant is “router, which is running a routing 
		protocol which is based on RFC5444”, so could the document not say
		that?

		In any event, I do not see “protocol participant” defined or anywhere else,
		and so it seems unfortunate to *not* be explicit here.

	o	Introduction, 3rd paragraph:

		OLD:
			Two options for the choice of identity are supported (the two code
			points allocated).

		NEW:
			Two options for the choice of identity are supported (as reflected
			by the two code points allocated).


	o	Introduction, 7th paragraph:
		Caveating that using this introduces the danger that “if you catch the 
		trusted authority, then you’re screwed” is awesome. I see that 
		this is repeated and reworded in the Security Considerations section,
		and I approve. 

		Now, my question is then, if this should not be stated in the Applicability 
		statement, also? Something to the effect of that this applies to networks
		where all routers can (at some point) be in contact with the TA (to be
		keyed), but that this can be off-line — and probably should be off-line
		since the TA really, really should be protected.

		It might be argued that the forward-reference to Section 6 captures
		this — I still think, that a few choice words in the applicability statement
		would help greatly.

	o	Introduction, 9th paragraph:
		Any [academic? otherwise] work that you can cite to quantify the 
		computational load? I asked a crypto-wonk-colleague, who said
		something to the effect of “the document is perfectly right, on this
		point, but I do not have a paper just off the top of my head with 
		interesting data to offer”. For that reason alone, it’d be interesting 
		if you did ;)

	o	Throw-away comment, I appreciate particularly the last
		paragraph of the introduction.

	o	Section 4.1, first bullet

		OLD:
		   o  The ICV is not calculated as cryptographic-function(hash-
		       function(content)) as defined in [RFC7182], but (like the HMAC
		       ICVs defined there) uses the hash function within the
		       cryptographic function.  The option "none" is not permitted for
		       hash-function, and the hash function must have a known fixed
		       length of N octets, as specified in Section 4.2.

		NEW:
		   o  The ICV is not calculated as cryptographic-function(hash-
		       function(content)) as defined in [RFC7182], but (like the HMAC
		       ICVs defined in [RFC7182]) uses the hash function within the
		       cryptographic function.  The option "none" is not permitted for
		       hash-function, and the hash function must have a known fixed
		       length of N octets, as specified in Section 4.2.

	o	While we are at it, it it crystal-clear to everybody that “Section 4.2” in
		the bullet above is to *this* document, as not RFC7182?

	o	Section 4.3, 2nd bullet
		There’s a LOT of information embedded in this bullet, and reading it
		suggests that it, readability-wise, might benefit from embedding a:
			<list style=“hanging”>
				<t hangText=“Packet TLVs”>…</t>
				<t hangText=“Message TLVs”>…</t>
				<t hangText=“Address Block TLVs”>…</t>
			</list>

	o	IANA Considerations:

		Given recent experiences in this WG and with requesting IANA 
		registrations, may I suggest that this be modified to say, more
		explicitly:

			1)	IANA is requested to reserve ECCSI with description ___ 
				and reference “This Specification”

			2)	IANA is requested to reserve ECCSI-ADDR…. (similar)

			3)	The “Cryptographic Functions Registry”, defined in 
				[RFC7182], with these registrations made, will look
				like Table 1, which replaces Table 11 of [RFC7182]

			4)	Obviously, include in Table 1 the registrations from
				RFC7182.

			5)	That this document does not modify the expert
				review guidelines as set forth in RFC7182 for
				future allocations.

That’s all. Thanks for writing this document, Chris.	


Respectfully,

Thomas