Subject: Re: [manet] rfc6622-bis-01 review

From: Henning Rogge <[email-masked]>
Date: Tue, 2 Apr 2013 10:31:56 +0200

On 03/25/2013 10:01 PM, Justin Dean wrote:
> Below I have included my comments in-line tagged with JD.  The new TLV
> subtype assignment confuses the issue of replacement of 6622.  Are there
> situations where ICV TLVs with subtype 1 as defined in 6622 are
>
> more appropriate?  My guess is No. In any case I shouldn't be guessing,
> so that should be made more clear.

I think subtype 2 does only apply to RFC5444 messages that must not be 
forwarded.

The Source-IP of the UDP-packets forwarding the message do change every 
hop, so OLSRv2 TCs (as an example) must use subtype 1.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: James Nguyen <[email-masked]>
Date: Tue, 9 Apr 2013 14:22:57 -0400

RFC6622-bis authors,
Overall, I think this draft is good.  A few editorials (to make it clearer)
would complete its purpose.
Please find my comments starting with [JN].

> Section 5

   For example, and as defined in this document, an ICV TLV with type

   extension = 0 specifies that the <value> field has no pre-defined

   internal structure but is simply a sequence of octets.  An ICV TLV

   with type extension = 1 specifies that the <value> field has a pre-

   defined internal structure and defines its interpretation.  An ICV

   TLV with type extension = 2 specifies a modified version of this

   definition.  (Specifically, with type extension = 1 or type extension

   = 2, the <value> field contains the result of combining a

   cryptographic function and a hash function, calculated over the

   contents of the packet, message or address block, with sub-fields

   indicating which hash function and cryptographic function have been

   used; this is specified in Section 12.  The difference between the

   two type extensions is that the ICV TLV with type extension = 2 is

   calculated also over the source address of the IP datagram carrying

   the packet, message, or address block.)

[JN]  I would break this block of text into a simpler or less text one or
an if-else statement pseudo code.  J

Same as for the following sections:

      12.2.1.  Packet ICV TLV

      12.2.2.  Message ICV TLV

      12.2.3.  Address Block ICV TLV

> Section 7 Timestamp TLV Structure

[JN] time synchronization is an issue in one of my emulation tools.  It
would be an interesting topic to discuss how to sync timestamp in MANET,
but it would be addressed or discussed outside the scope of this draft.

James

On Tue, Apr 2, 2013 at 4:31 AM, Henning Rogge <
[email-masked]> wrote:

> mailto:henning.rogge@fkie.**fraunhofer.de<[email-masked]>
> http://www.fkie.fraunhofer.de
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

-- 
James Nguyen
Email: [email-masked]

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 9 Apr 2013 12:28:26 -0700

James,

thank you for your comments and your support of this document. See below:

> Please find my comments starting with [JN].
[...]
>
>
> [JN]  I would break this block of text into a simpler or less text one or an
> if-else statement pseudo code.  J

I agree that some of the sentences are a bit long and hard to read. I
think we can slightly rewrite it so that it is easier to read.

>       12.2.3.  Address Block ICV TLV

Okay, I will look at these sentences.

> would be an interesting topic to discuss how to sync timestamp in MANET, but
> it would be addressed or discussed outside the scope of this draft.

Time synchronization is indeed not easy in MANETs. I agree that it
should not be addressed inside this document.

Regards
Ulrich

>
>
>
> James
>
> On Tue, Apr 2, 2013 at 4:31 AM, Henning Rogge
> <[email-masked]> wrote:
>>