Re: [dtn-interest] [Fwd: IRSG review of draft-irtf-dtnrg-bundle-metadata-block]

["Symington, Susan F." <[e-mail]>]

All, 

I have posted a revised DTN Metadata Extension Block I-D (now version 7) in response to Lixia Zhang's comments. See the posting notice below.

-susan
--
A new version of I-D, draft-irtf-dtnrg-bundle-metadata-block-07.txt has been successfuly submitted by Susan Symington and posted to the IETF repository.

Filename:	 draft-irtf-dtnrg-bundle-metadata-block
Revision:	 07
Title:		 Delay-Tolerant Networking Metadata Extension Block
Creation_date:	 2010-02-17
WG ID:		 Independent Submission
Number_of_pages: 13

Abstract:
This document defines an extension block that may be used with the
DTN Bundle Protocol.  This Metadata Extension Block is designed to
carry additional information that DTN nodes can use to make
processing decisions regarding bundles, such as deciding whether to
store a bundle or determining to which nodes to forward a bundle.
The metadata that is carried in a metadata block must be formatted
according to the metadata type that is identified in the block's
metadata type field.  One specific metadata type, for carrying URIs
as metadata, is defined in this document.  Other metadata types may
be defined in separate documents.  This document is a product of the
Delay Tolerant Networking Research Group and has been reviewed by
that group.  No objections to its publication as an RFC were raised.
                                                                                  


The IETF Secretariat.


>-----Original Message-----
>From: [e-mail] [mailto:dtn-interest-
>[e-mail]] On Behalf Of Elwyn Davies
>Sent: Thursday, February 04, 2010 1:11 PM
>To: Delay Tolerant Networking Interest List
>Subject: [dtn-interest] [Fwd: IRSG review of draft-irtf-dtnrg-bundle-metadata-
>block]
>
>Hi.
>
>Please take a look at Lixia Zhang's review of
>draft-irtf-dtnrg-bundle-metadata-block attached below.
>
>If you have any responses or further comments please send them to the
>list before Weds 17th |February.  Thereafter Susan will generate a new
>version for the IRSG to approve (hopefully!).
>
>We now have the IRSG reviews of the 5 documents, and should be able to
>progress them soon.
>
>Regards,
>Elwyn
>
>
>
>-------- Original Message --------
>Subject: 	Re: DTNRG review: RE-PROD!
>Date: 	Wed, 3 Feb 2010 16:08:52 -0800
>From: 	Lixia Zhang <[e-mail]>
>To: 	Elwyn Davies <[e-mail]>
>References: 	<[e-mail]>
>
>
>
>On Feb 2, 2010, at 1:54 PM, Elwyn Davies wrote:
>
>>
>>
>> Hi, Lixia.
>>
><<snip>>
>Now I'm just writing down my review in this reply.
>
>Lixia
>
>--------------
>
>First, I only reviewed this draft, not the companion ones.  I do not
>have full knowledge about the Bundle stuff (I did see a paper titled
>"A bundle of problems", seems there are controversial views...).  Thus
>I was unable to make evaluations on Section 5 "Security Considerations".
>
>With that: I reviewed this draft for clarity and readability.  All the
>comments below are formating related minor issues.
>
>1/ Personally I'd move the first paragraph in intro to a later place
>(not wrong, but it looks odd by starting a draft/rfc with key words
>definitions)
>
>2/ there seem some repeated sentences between the 2nd and 3nd
>paragraphs:
>
>   This document defines an extension block that may be used with the
>   Bundle Protocol [refs.DTNBP] within the context of a Delay-Tolerant
>   Network architecture [refs.DTNarch].  The DTN bundle protocol
>   [refs.DTNBP] defines the bundle as its protocol data unit.  This
>   document defines a bundle block called a Metadata Block.  This block
>   is designed to carry additional information that DTN nodes can use
>to
>   make processing decisions regarding bundles.
>
>   The metadata block has been deliberately defined to be flexible
>   enough that it would be capable of supporting a variety of metadata
>   types and formats.  However, as mentioned, it is the intention that
>   the metadata that is carried in this block be additional
>application-
>   related information.  For example, the metadata might be information
>   that is associated with the payload of a bundle.  Additional
>   extension blocks could be (and have been) defined for carrying
>   additional network-related information.
>
>Furthermore, I did not see clearly where in the design that showed
>"deliberately defined to be flexible".  Might be helpful to either add
>a forward pointer here, or mention it later where the flexibility
>showed up.
>
>3/ A few later paragraphs in the intro seem better fitted into a later
>section, e.g. the meta data structure details, for example:
>
>   A bundle may contain multiple metadata extension blocks.  In some
>   cases, multiple metadata blocks may be carried in the bundle,
>   possibly with each being encrypted separately from each other and
>   from the payload.  Such separate encryption of metadata from payload
>   would enable bundle nodes to perform content-based searching and
>   routing on bundle metadata that they are able to decrypt, even if
>   they are not able to decrypt the bundle payload.
>
>this does not seem belonging to intro.
>
>4/ In Section 2, I would suggest that the author shows Figure-1 first,
>before discussing each field showing in Fig-1.
>
>Much of the detail about the metadata format is missing, e.g.
>- how many bytes/bits for the Flags field?
>
>- how can one tell whether the "EID Reference Count and
>  List (optional)" is/not present?  and how long is it if it is there?
>
>- the length question applies to all subsequent fields as well.
>
>- I found the following quite confusing:
>
>         - Metadata field - contains the metadata itself, formatted
>         according to the metadata type that has been specified for
>this
>         block.
>
>It is perfectly fine to have the format as a function of the type, but
>where are they defined???
>
>
>
>
>
>_______________________________________________
>dtn-interest mailing list
>[e-mail]
>http://maillists.intel-research.net/mailman/listinfo/dtn-interest