Subject: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs

From: Thomas Clausen <[email-masked]>
Date: Mon, 28 Jul 2014 15:19:00 +0200

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

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 28 Jul 2014 16:37:36 +0200

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

And, Ulrich just pointed out to me in private that the above should be "draft-ietf-manet-ibs”, of course — I thought I was being clever using email templates, and all. Apologies, and thank you Ulrich for catching my screwup.

Thomas

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 28 Jul 2014 15:58:38 +0000

Thanks Thomas for this. I'm just going to pick up one point for this email (not meaning that I'm disregarding the other points).

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

Unfortunately, no I don't, though I must admit to not trying to look hard. The last interested academic that I spoke to on this matter was interested in our results, rather than providing any results himself.

We have experimental results that I'm reasonably sure show faster signatures and verifications than other forms of IBS we have implemented (at least two others at various times). That's in large part because ECCSI does not use pairings (see the companion RFC 6508 for an algorithm that does) and the expensive operations (both by repute and in our experience) are pairings and exponentiations of elements in the codomain of the pairing. However I don't have a set of crystal clear results comparing the signature only with nothing else changed. In principle we could do this, but for various reasons that would take longer than I have time to spare. (They weren't all created for the same purpose.) Any results would also be dependent on the choice of crypto library, and even decisions made within the library. For example I've had a significant factor speedup using a different option within a library in one case.

So, in short, that paragraph is about what I think I can say without stepping where I couldn't back up comments. I'd like to strengthen it, but I think that's where I can go.

Anyone who has a reference (and I will look a bit further) please let me know. Non-paywalled references in strong preference.

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

From: manet [mailto:[email-masked]] On Behalf Of Thomas Clausen
Sent: 28 July 2014 15:38
To: manet; <[email-masked]>; manet-ads
Cc: Christopher Dearlove
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.

On Jul 28, 2014, at 15:19, Thomas Clausen <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG Chairs,
Dear Chris, all,

And, Ulrich just pointed out to me in private that the above should be "draft-ietf-manet-ibs", of course - I thought I was being clever using email templates, and all. Apologies, and thank you Ulrich for catching my screwup.

Thomas

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

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.

                        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:

                        NEW:

            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.

                        OLD:

                        NEW:

            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.

                        keyed), but that this can be off-line - and probably should be off-line

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

                        OLD:

                        NEW:

            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:

                                    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]

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

Respectfully,

Thomas
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.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.
********************************************************************

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 28 Jul 2014 18:05:37 +0200

Chrism

On Jul 28, 2014, at 17:58, Dearlove, Christopher (UK) <[email-masked]> wrote:

> Thanks Thomas for this. I’m just going to pick up one point for this email (not meaning that I’m disregarding the other points).
>  

Sure thing - I was actually thinking about factoring this out in a separate email as it is of more general interest, then decided against it.

> Unfortunately, no I don’t, though I must admit to not trying to look hard. The last interested academic that I spoke to on this matter was interested in our results, rather than providing any results himself.

Alright, I’ll try to ask around my local crypto wonks — it’d be good if everybody on the list would do the same.

Thomas

>  
> We have experimental results that I’m reasonably sure show faster signatures and verifications than other forms of IBS we have implemented (at least two others at various times). That’s in large part because ECCSI does not use pairings (see the companion RFC 6508 for an algorithm that does) and the expensive operations (both by repute and in our experience) are pairings and exponentiations of elements in the codomain of the pairing. However I don’t have a set of crystal clear results comparing the signature only with nothing else changed. In principle we could do this, but for various reasons that would take longer than I have time to spare. (They weren’t all created for the same purpose.) Any results would also be dependent on the choice of crypto library, and even decisions made within the library. For example I’ve had a significant factor speedup using a different option within a library in one case.
>  
> So, in short, that paragraph is about what I think I can say without stepping where I couldn’t back up comments. I’d like to strengthen it, but I think that’s where I can go.
>  
> [email-masked] | http://www.baesystems.com
> 
> For information regarding Red Flags that you can look out for in emails you receive, clickhere.
> If you feel the email is suspicious, please follow this process.
> 
>  
> I have, therefore, reviewed the document carefully. In my opinion, the author is right —in my opinion this document is ready for WGLC.
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 29 Jul 2014 14:06:51 +0000

From: Thomas Clausen [mailto:[email-masked]]
Sent: 28 July 2014 14:19
To: manet; <[email-masked]>; manet-ads
Cc: Christopher Dearlove
Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs

*** WARNING ***

Issues:

Nits:

                        NEW:

                        OLD:

                        NEW:

                        OLD:

                        NEW:

            o          IANA Considerations:

Respectfully,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 29 Jul 2014 14:17:00 +0000

(Apologies for the previous accidental empty send.)

I'll pick up a separate point this time, namely

7182 contains both symmetric and asymmetric ciphers, on the one hand DSA, HMAC, 3DES, AES, on the other hand RSA, ECDSA.

How the keys are organised is not discussed in 7182, it is rather implicit. In the symmetric case we need to share keys, this
Could be as simple as a single shared key, but as exemplified by 7183 (which uses one of the symmetric cases) this could
Be multiple keys. In the asymmetric case we have pairwise keys, pre-distributed or with public keys certified, and a PKI
On top of that. So 7182 implicitly (but not explicitly) offers us these three options (shared keys, pre-shared pairwise keys,
PKI - and the overhead of certificates).

As this document is about 7182, not 7183 (which is NHDP/OLSRv2 only) I'd rather stick to just referencing and discussing 7182,
But a wording tweak may be in order.

*** WARNING ***

Issues:

Nits:

                        NEW:

                        OLD:

                        NEW:

                        OLD:

                        NEW:

            o          IANA Considerations:

Respectfully,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 29 Jul 2014 15:16:50 +0000

Some additional comments inline. I plan to put out a new version shortly, but technically all will be unchanged.

*** WARNING ***

Issues:

CMD: On the grounds that the biggest wasted effort is taking out, and then maybe putting back in, I'm going to leave as-is until our AD comments. But I'd have done the same if it were the other way round, I'm happy whichever way this is settled.

CMD: I made an earlier post on this. I think that some improvements in wording in the Introduction are indicated.

Nits:

                        NEW:

CMD: I want to keep some of what's lost by that edit, so will propose a third wording.

CMD: Simply removing the parenthesis removes the intended point, which was to say that the
description assumes that the entities involved are routers - which isn't actually the only possibility
using 5444. I'll propose something that borrows from the above to improve it.

                        OLD:

                        NEW:

CMD: Good.

CMD: I prefer to stick with the forward reference, as I think by the time you've said enough, you've duplicated half of Section 6. But adding some words to say particularly regarding the role of the TA/KMS makes sense.

CMD: See previous comments. Trying Google Scholar with ECCSI elliptic curve gets a very small number of hits, none useful here.

                        OLD:

                        NEW:

CMD: I could live with either, but will make the change.

CMD: I'm going to assume it is. I would always write Section X.Y of [Z] (or similar) if making an external reference.

CMD: I'm including to be slightly less radical (and I'm not a fan on hanging text). But I will create another level.

            o          IANA Considerations:

CMD: I think this comes under the heading of hand-holding IANA more than I would feel ought to be necessary. Except sometimes it has been. But this is a straightforward case, so while I agree that making it more explicit that this is a request for two new code points, I'm not going to repeat the full table from 7182 unless IANA really show they need hand-holding. Our previous cases where we had to repeat a whole table were a bit messier. But giving the exact name for the table as on IANA's website is advisable.

Respectfully,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 30 Jul 2014 16:22:15 +0200

Chris,

On Jul 29, 2014, at 16:17, Dearlove, Christopher (UK) <[email-masked]> wrote:

> I’ll pick up a separate point this time, namely
>  
> PKI – and the overhead of certificates).
>  
> As this document is about 7182, not 7183 (which is NHDP/OLSRv2 only) I’d rather stick to just referencing and discussing 7182,

Alright, so I see that there’re two things that can happen: reference 7183, and keep the text unchanged — or word-tweak so that the citation to 7182 can remain. Either can work for me, seems you prefer the latter, so I am looking forward to seeing an update.

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 30 Jul 2014 16:32:28 +0200

Chris,

> Some additional comments inline. I plan to put out a new version shortly, but technically all will be unchanged.

Comments below, but yes, what I suggest are in the “nits” category, which is why I would have been happy to see the current version WGLCed. If you have a new version that addresses my nits, then the WGLC will be even easier for me, though....

Below (snipping out the parts where we agree and stuff).
> Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs

<SNIP>

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

<SNIP>

> CMD: On the grounds that the biggest wasted effort is taking out, and then maybe putting back in, I’m going to leave as-is until our AD comments. But I’d have done the same if it were the other way round, I’m happy whichever way this is settled. 

I’m entirely aligned with you on this point. If we do not get an ADs input before, we just need to make sure that this will be included in the document write-up and dealt with then.

> CMD: I made an earlier post on this. I think that some improvements in wording in the Introduction are indicated.

Acknowledged, and that’s quite satisfactory.

> CMD: I want to keep some of what’s lost by that edit, so will propose a third wording.

Looking forward to seeing that.

> description assumes that the entities involved are routers – which isn’t actually the only possibility
> using 5444. I’ll propose something that borrows from the above to improve it.

OK, looking forward to seeing that, too.

<SNIP>

> CMD: I prefer to stick with the forward reference, as I think by the time you’ve said enough, you’ve duplicated half of Section 6. But adding some words to say particularly regarding the role of the TA/KMS makes sense.

I think that we are aligned, that that’s what the last sentence in my comment seeks to capture. So, I look forward to seeing your proposal to this, too.

> CMD: See previous comments. Trying Google Scholar with ECCSI elliptic curve gets a very small number of hits, none useful here.

I’ve asked around, but I am not hopeful. Will let you know if I get something citable — most I spoke to said “this aligns with my intuition/experience/*” though.

<SNIP>

> CMD: I could live with either, but will make the change.

I think it makes it clearer, so thank you for that.

> CMD: I’m going to assume it is. I would always write Section X.Y of [Z] (or similar) if making an external reference.

OK, this was a throw-away comment, not important
 
> CMD: I’m including to be slightly less radical (and I’m not a fan on hanging text). But I will create another level.

Thank you, that will work nicely.

> CMD: I think this comes under the heading of hand-holding IANA more than I would feel ought to be necessary. Except sometimes it has been. But this is a straightforward case, so while I agree that making it more explicit that this is a request for two new code points, I’m not going to repeat the full table from 7182 unless IANA really show they need hand-holding. Our previous cases where we had to repeat a whole table were a bit messier. But giving the exact name for the table as on IANA’s website is advisable.
>  

True, but…there’s perhaps something to be said for “the table being as complete as possible” for the reader, also? Well, your call, of course.

Once a new version hits the servers, I’ll let you know if I see any pending nits.

Cheers,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 30 Jul 2014 15:29:54 +0000

I have submitted an -02 based on Thomas's comments, as I proposed addressing them. Any further comments welcome.

Technically, nothing has changed.

From: Thomas Clausen [mailto:[email-masked]]
Sent: 30 July 2014 15:32
To: Dearlove, Christopher (UK)
Cc: manet; <[email-masked]>; manet-ads; Christopher Dearlove
Subject: Re: [manet] Ready for WGLC: Advancing draft-ietf-manet-ibs

*** WARNING ***

On Jul 29, 2014, at 17:16, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

Comments below, but yes, what I suggest are in the "nits" category, which is why I would have been happy to see the current version WGLCed. If you have a new version that addresses my nits, then the WGLC will be even easier for me, though....

From: Thomas Clausen [mailto:[email-masked]]
Sent: 28 July 2014 14:19
To: manet; <[email-masked]<mailto:[email-masked]>>; manet-ads
Cc: Christopher Dearlove
Subject: Ready for WGLC: Advancing draft-ietf-manet-ibs

<SNIP>

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

<SNIP>

Issues:

I'm entirely aligned with you on this point. If we do not get an ADs input before, we just need to make sure that this will be included in the document write-up and dealt with then.

Acknowledged, and that's quite satisfactory.

Nits:

                        NEW:

<SNIP>

I think that we are aligned, that that's what the last sentence in my comment seeks to capture. So, I look forward to seeing your proposal to this, too.

I've asked around, but I am not hopeful. Will let you know if I get something citable - most I spoke to said "this aligns with my intuition/experience/*" though.

<SNIP>

                        OLD:

                        NEW:

            o          IANA Considerations:

True, but...there's perhaps something to be said for "the table being as complete as possible" for the reader, also? Well, your call, of course.

Once a new version hits the servers, I'll let you know if I see any pending nits.

Cheers,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 30 Jul 2014 18:27:58 +0200

Chris,

Wow, you're quick ;)

Thanks for addressing my comments. I am perfectly happy with this -02, and have no new comments, nits, and issues to raise. 

I recommend that this I-D be WGLCed promptly

Outstanding, for me, is only the Updates/not-Updates issue -- which is a trivial fix once an AD has provided due guidance as to what is "the right thing to do".

Best,

Thomas

Sent from my iPad

> On 30 Jul 2014, at 17:29, "Dearlove, Christopher (UK)" <[email-masked]> wrote:
> 
> I have submitted an -02 based on Thomas’s comments, as I proposed addressing them. Any further comments welcome.
>  
> For information regarding Red Flags that you can look out for in emails you receive, click here.