From shijunxiao at email.arizona.edu  Tue Jul  1 23:52:39 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 2 Jul 2014 14:52:39 +0800
Subject: [Nfd-dev] Fwd: [ndn] NFD version 0.2.0 release candidate 1
In-Reply-To: <B584D5D3-3269-4D75-93EA-3D55C57E02A3@ucla.edu>
References: <B584D5D3-3269-4D75-93EA-3D55C57E02A3@ucla.edu>
Message-ID: <CAOFH+OY2dVXau7K-DYk19o1a+bEA3rp1-zOh5jw-K73rkJK8PQ@mail.gmail.com>

This announcement deserves an archive entry in nfd-dev as well.

---------- Forwarded message ----------
From: Alex Afanasyev <alexander.afanasyev at ucla.edu>
Date: Wed, Jul 2, 2014 at 2:46 PM
Subject: [ndn] NFD version 0.2.0 release candidate 1
To: ndn <ndn at lists.cs.ucla.edu>


Hello everybody,

We would like to announce our first release candidate for version 0.2.0 of
NFD.

The list of changes since previous release is available on NFD website (
http://named-data.net/doc/NFD/0.2.0/RELEASE_NOTES.html) and is also copied
at the bottom of this email.

One of the main features of this release is NFD developer guide (
http://named-data.net/wp-content/uploads/2014/07/NFD-developer-guide.pdf),
which explains in detail internals of NFD implementation and is aimed to
help extend current functionality of the forwarder.


* Official website for NFD version 0.2.0:
http://named-data.net/doc/NFD/0.2.0/

Source release
==============

* The source code is available on Github: https://github.com/named-data/NFD

* Instructions to install NFD from source:
http://named-data.net/doc/NFD/0.2.0/getting-started.html

* NFD Wiki / User knowledge:
http://redmine.named-data.net/projects/nfd/wiki#User-Knowledge-Base

Binary release
==============

* For Ubuntu 12.04 and 14.04

Binary packages for NFD, library, and tools are available in NDN-dev PPA
archive:https://launchpad.net/~named-data/+archive/ppa-dev

Follow these instructions:
http://named-data.net/doc/NFD/0.2.0/FAQ.html#how-to-start-using-ndn-ppa-repository-on-ubuntu-linux

Note: you need to use "sudo add-apt-repository ppa:named-data/ppa-dev"
instead of the suggested add-apt-repository command (binaries will be
released via the official channel after the final release).

* For OSX with Macports (pending)

Follow these instructions:
http://named-data.net/doc/NFD/0.2.0/FAQ.html#how-to-start-using-ndn-macports-repository-on-osx

Feedback
========

Feature requests and bug reports are welcome on our NDN Redmine:
http://redmine.named-data.net/projects/nfd


Changes since version 0.1.0
===========================

? Documentation
        ? "NFD Developer's Guide" by NFD authors (
http://named-data.net/wp-content/uploads/2014/07/NFD-developer-guide.pdf)
that explains NFD's internals including the overall design, major modules,
their implementation, and their interactions
        ? New detailed instructions on how to enable auto-start of NFD
using OSX launchd and Ubuntu's upstart (see contrib/ folder)
? Core
        ? Add support for temporary privilege drop and elevation (Issue
#1370)
        ? Add support to reinitialize multicast Faces and (partially)
reload config file (Issue #1584)
        ? Randomization routines are now uniform across all NFD modules
(Issue #1369)
? Faces
        ? WebSocket Face support (Issue #1468)
        ? Fix Ethernet Face support on Linux with libpcap version >=1.5.0
(Issue #1511)
        ? Fix to recognize IPv4-mapped IPv6 addresses in FaceUri (Issue
#1635)
        ? Fix to avoid multiple onFail events (Issue #1497)
        ? Fix broken support of multicast UDP Faces on OSX (Issue #1668)
        ? On Linux, path MTU discovery on unicast UDPv4 faces is now
disabled (Issue #1651)
? Forwarding
        ? Outgoing Interest pipeline now allows strategies to request a
fresh Nonce (e.g., when the strategy needs to re-express the Interest)
(Issue #1596)
        ? Fix in the incoming Data pipeline to avoid sending packets to the
incoming Face (Issue #1556)
        ? New RttEstimator class that implements the Mean-Deviation RTT
estimator to be used in forwarding strategies
? Tables
        ? Fix in ContentStore to properly adjust internal structure when
Cs::setLimit is called (Issue #1646)
        ? New option in configuration file to set an upper bound on
ContentStore size (Issue #1623)
        ? Fix to prevent infinite lifetime of Measurement entries (Issue
#1665)
? Management
        ? RibManager now fully support CHILD_INHERIT and CAPTURE flags
(Issue #1325)
        ? Fix in FaceManager to respond with canonical form of Face URI for
Face creation command (Issue #1619)
        ? Fix to prevent creation of duplicate TCP/UDP Faces due to async
calls (Issue #1680)
? Tools
        ? Extended functionality of nfd-status

                ? -x to output in XML format, see nfd-status xml schema
                ? -c to retrieve channel status information (enabled by
default)
                ? -s to retrieve configured strategy choice for NDN
namespaces (enabled by default)
                ? Face status now includes reporting of Face flags (local
and on-demand)
                ? On-demand UDP Faces now report remaining lifetime
(expirationPeriod)
        ? Several fixes in ndn-autoconfig tool (Issue #1595)
        ? Extended options in nfdc:
                ? -e to set expiration time for registered routes
                ? -o to specify origin for registration and unregistration
commands
? Build
        ? Enable support of precompiled headers for clang and gcc to speed
up compilation
? Other small fixes and extensions (
https://github.com/named-data/NFD/compare/NFD-0.1.0...NFD-0.2.0-rc1)


---
NFD Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140702/b214e9ec/attachment.html>

From alexander.afanasyev at ucla.edu  Mon Jul  7 22:08:13 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 7 Jul 2014 22:08:13 -0700
Subject: [Nfd-dev] Feedback request for public release text
Message-ID: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>

Hi guys,

I just finished making the first draft for the public release text that suppose to go to several public mailing lists.

Please take a look and give your comments asap.

Questions I have so far:
1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?
2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?

---
Alex

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nfd-public-draft1.txt
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140707/8e396f8f/attachment.txt>
-------------- next part --------------



From lanwang at memphis.edu  Tue Jul  8 08:58:53 2014
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 8 Jul 2014 15:58:53 +0000
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>
References: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>
Message-ID: <57A2F521-BEAB-45B4-8D93-A2853E10262D@memphis.edu>


On Jul 8, 2014, at 12:08 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> Hi guys,
> 
> I just finished making the first draft for the public release text that suppose to go to several public mailing lists.
> 
> Please take a look and give your comments asap.
> 
> Questions I have so far:
> 1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?

The level of details looks good to me.  It's good to have some details in the email announcement (at least for record keeping) as the website may be updated later.

> 2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?

I'm not sure if the timing is good right now ? maybe wait until when the testbed is updated with the new code and is relatively stable.

By the way, why is this "the initial public release (version 0.2.0)"?  what about 0.1.0?

Lan
> 
> ---
> Alex
> 
> <nfd-public-draft1.txt>
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From alexander.afanasyev at UCLA.EDU  Tue Jul  8 09:31:46 2014
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Tue, 8 Jul 2014 09:31:46 -0700
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <57A2F521-BEAB-45B4-8D93-A2853E10262D@memphis.edu>
References: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>
	<57A2F521-BEAB-45B4-8D93-A2853E10262D@memphis.edu>
Message-ID: <B8051CB6-885B-456F-A46B-5051B5C44FAB@ucla.edu>

On Jul 8, 2014, at 8:58 AM, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:
> 
> 
>> On Jul 8, 2014, at 12:08 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
>> 
>> Hi guys,
>> 
>> I just finished making the first draft for the public release text that suppose to go to several public mailing lists.
>> 
>> Please take a look and give your comments asap.
>> 
>> Questions I have so far:
>> 1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?
> 
> The level of details looks good to me.  It's good to have some details in the email announcement (at least for record keeping) as the website may be updated later.
> 
>> 2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?
> 
> I'm not sure if the timing is good right now ? maybe wait until when the testbed is updated with the new code and is relatively stable.

Hi Lan,

Thanks for the comments.

The announcement suppose to go out after nfd is deployed on testbed. So, my question is whether this fact needs to be emphasized or not.


> By the way, why is this "the initial public release (version 0.2.0)"?  what about 0.1.0

0.2.0 is the first _public_ release.  0.1.0 was only out internal release.

---
Alex

> Lan
>> 
>> ---
>> Alex
>> 
>> <nfd-public-draft1.txt>
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 



From jdd at seas.wustl.edu  Tue Jul  8 11:18:37 2014
From: jdd at seas.wustl.edu (John DeHart)
Date: Tue, 8 Jul 2014 13:18:37 -0500
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>
References: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>
Message-ID: <53BC35FD.4010306@seas.wustl.edu>


Alex,

Nice job pulling this all together.

I would tend to agree that it may be a bit much for an announcement.
I would certainly take the list of per-module features out of the
announcement and just link to that info on a website.

John


On 7/8/14, 12:08 AM, Alex Afanasyev wrote:
> Hi guys,
>
> I just finished making the first draft for the public release text 
> that suppose to go to several public mailing lists.
>
> Please take a look and give your comments asap.
>
> Questions I have so far:
> 1. Isn't it too much for the announcement?  Would it better to just 
> refer to website where we would have similar text?
> 2. Shall we refer our testbed deployment?  If yes, then should we add 
> a join invitation like "if you want to join our Testbed, here is the 
> link to the joining policy..." ?
>
> ---
> Alex
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140708/a5a091c9/attachment.html>

From jburke at remap.ucla.edu  Wed Jul  9 07:44:45 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Wed, 9 Jul 2014 14:44:45 +0000
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <53BC35FD.4010306@seas.wustl.edu>
Message-ID: <CFE2A348.1515F3%jburke@remap.ucla.edu>

Hi,

I agree with John's suggestions.

What is the timeline for deployment on the testbed?

Thanks,
Jeff


From: John DeHart <jdd at seas.wustl.edu<mailto:jdd at seas.wustl.edu>>
Date: Tue, 8 Jul 2014 13:18:37 -0500
To: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>, "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Feedback request for public release text


Alex,

Nice job pulling this all together.

I would tend to agree that it may be a bit much for an announcement.
I would certainly take the list of per-module features out of the
announcement and just link to that info on a website.

John


On 7/8/14, 12:08 AM, Alex Afanasyev wrote:
Hi guys,

I just finished making the first draft for the public release text that suppose to go to several public mailing lists.

Please take a look and give your comments asap.

Questions I have so far:
1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?
2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?

---
Alex



_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140709/6458f3b9/attachment.html>

From jdd at seas.wustl.edu  Wed Jul  9 08:02:06 2014
From: jdd at seas.wustl.edu (John DeHart)
Date: Wed, 9 Jul 2014 10:02:06 -0500
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <CFE2A348.1515F3%jburke@remap.ucla.edu>
References: <CFE2A348.1515F3%jburke@remap.ucla.edu>
Message-ID: <53BD596E.7070701@seas.wustl.edu>


All:

I'm running an 8 node test with NFD and NLSR in ONL (our local network 
testbed)
which is configured just like the western part of the NDN Testbed.
It includes nodes for Arizona, CSU, REMAP, UCLA, UCI, UCSD, PKU and TONGJI.

It is not completely working yet. I am working with the Memphis folks
to figure out what is going wrong. When we get this working I am
hopeful that we can make a fairly quick transition to the Testbed.
By doing this testing on ONL with Testbed-like configurations
I should already have the configuration files needed for the actual Testbed.

John


On 7/9/14, 9:44 AM, Burke, Jeff wrote:
> Hi,
>
> I agree with John's suggestions.
>
> What is the timeline for deployment on the testbed?
>
> Thanks,
> Jeff
>
>
> From: John DeHart <jdd at seas.wustl.edu <mailto:jdd at seas.wustl.edu>>
> Date: Tue, 8 Jul 2014 13:18:37 -0500
> To: Alex Afanasyev <alexander.afanasyev at ucla.edu 
> <mailto:alexander.afanasyev at ucla.edu>>, "<nfd-dev at lists.cs.ucla.edu 
> <mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu 
> <mailto:nfd-dev at lists.cs.ucla.edu>>
> Subject: Re: [Nfd-dev] Feedback request for public release text
>
>
>     Alex,
>
>     Nice job pulling this all together.
>
>     I would tend to agree that it may be a bit much for an announcement.
>     I would certainly take the list of per-module features out of the
>     announcement and just link to that info on a website.
>
>     John
>
>
>     On 7/8/14, 12:08 AM, Alex Afanasyev wrote:
>>     Hi guys,
>>
>>     I just finished making the first draft for the public release
>>     text that suppose to go to several public mailing lists.
>>
>>     Please take a look and give your comments asap.
>>
>>     Questions I have so far:
>>     1. Isn't it too much for the announcement? Would it better to
>>     just refer to website where we would have similar text?
>>     2. Shall we refer our testbed deployment?  If yes, then should we
>>     add a join invitation like "if you want to join our Testbed, here
>>     is the link to the joining policy..." ?
>>
>>     ---
>>     Alex
>>
>>
>>
>>     _______________________________________________
>>     Nfd-dev mailing list
>>     Nfd-dev at lists.cs.ucla.edu
>>     http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>     _______________________________________________ Nfd-dev mailing
>     list Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>     http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140709/8ae81a6a/attachment.html>

From lixia at CS.UCLA.EDU  Wed Jul  9 08:02:41 2014
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Wed, 9 Jul 2014 08:02:41 -0700
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <CFE2A348.1515F3%jburke@remap.ucla.edu>
References: <CFE2A348.1515F3%jburke@remap.ucla.edu>
Message-ID: <4953DA32-CB10-44E7-8D93-D79BC7CF0869@cs.ucla.edu>


On Jul 9, 2014, at 7:44 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> Hi, 
> 
> I agree with John's suggestions. 
> 
> What is the timeline for deployment on the testbed? 

my understanding is that John is working towards it as we speak.

yesterday at NFD daily call we also discussed what might be the timing for a public NFD announcement, perhaps depending on the speed/results of the testbed rollout experience.


> 
> Thanks,
> Jeff
> 
> 
> From: John DeHart <jdd at seas.wustl.edu>
> Date: Tue, 8 Jul 2014 13:18:37 -0500
> To: Alex Afanasyev <alexander.afanasyev at ucla.edu>, "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Feedback request for public release text
> 
>> 
>> Alex,
>> 
>> Nice job pulling this all together.
>> 
>> I would tend to agree that it may be a bit much for an announcement.
>> I would certainly take the list of per-module features out of the
>> announcement and just link to that info on a website.
>> 
>> John
>> 
>> 
>> On 7/8/14, 12:08 AM, Alex Afanasyev wrote:
>>> Hi guys,
>>> 
>>> I just finished making the first draft for the public release text that suppose to go to several public mailing lists.
>>> 
>>> Please take a look and give your comments asap.
>>> 
>>> Questions I have so far:
>>> 1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?
>>> 2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?
>>> 
>>> ---
>>> Alex
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>> _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140709/98c5be35/attachment.html>

From alexander.afanasyev at ucla.edu  Wed Jul  9 15:32:57 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 9 Jul 2014 15:32:57 -0700
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <4953DA32-CB10-44E7-8D93-D79BC7CF0869@cs.ucla.edu>
References: <CFE2A348.1515F3%jburke@remap.ucla.edu>
	<4953DA32-CB10-44E7-8D93-D79BC7CF0869@cs.ucla.edu>
Message-ID: <6B8B9B70-CB02-4C80-A3C2-267C5F693EB0@ucla.edu>

I got several more questions related to the public announcement.

- Given that we are going to have testbed deployment before the public announcement/release, do we have other objectives besides just deploying NFD on the testbed?  Anything that we would test?  On what scale?  For how long?

- Would the release of NFD coincide with NDN platform release?  If yes, then what is actually included?

---
Alex

On Jul 9, 2014, at 8:02 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:

> 
> On Jul 9, 2014, at 7:44 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> 
>> Hi, 
>> 
>> I agree with John's suggestions. 
>> 
>> What is the timeline for deployment on the testbed? 
> 
> my understanding is that John is working towards it as we speak.
> 
> yesterday at NFD daily call we also discussed what might be the timing for a public NFD announcement, perhaps depending on the speed/results of the testbed rollout experience.
> 
> 
>> 
>> Thanks,
>> Jeff
>> 
>> 
>> From: John DeHart <jdd at seas.wustl.edu>
>> Date: Tue, 8 Jul 2014 13:18:37 -0500
>> To: Alex Afanasyev <alexander.afanasyev at ucla.edu>, "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
>> Subject: Re: [Nfd-dev] Feedback request for public release text
>> 
>>> 
>>> Alex,
>>> 
>>> Nice job pulling this all together.
>>> 
>>> I would tend to agree that it may be a bit much for an announcement.
>>> I would certainly take the list of per-module features out of the
>>> announcement and just link to that info on a website.
>>> 
>>> John
>>> 
>>> 
>>> On 7/8/14, 12:08 AM, Alex Afanasyev wrote:
>>>> Hi guys,
>>>> 
>>>> I just finished making the first draft for the public release text that suppose to go to several public mailing lists.
>>>> 
>>>> Please take a look and give your comments asap.
>>>> 
>>>> Questions I have so far:
>>>> 1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?
>>>> 2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?
>>>> 
>>>> ---
>>>> Alex
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Nfd-dev mailing list
>>>> Nfd-dev at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> 
>>> _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.eduhttp://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140709/8e7899aa/attachment.html>

From lixia at CS.UCLA.EDU  Wed Jul  9 15:38:43 2014
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Wed, 9 Jul 2014 15:38:43 -0700
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <6B8B9B70-CB02-4C80-A3C2-267C5F693EB0@ucla.edu>
References: <CFE2A348.1515F3%jburke@remap.ucla.edu>
	<4953DA32-CB10-44E7-8D93-D79BC7CF0869@cs.ucla.edu>
	<6B8B9B70-CB02-4C80-A3C2-267C5F693EB0@ucla.edu>
Message-ID: <96F4CC95-9550-4D98-95AE-ACACD3B5427B@cs.ucla.edu>


On Jul 9, 2014, at 3:32 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> I got several more questions related to the public announcement.
> 
> - Given that we are going to have testbed deployment before the public announcement/release, do we have other objectives besides just deploying NFD on the testbed?  Anything that we would test?  On what scale?  For how long?

once NFD starts running on NDN testbed, I think we need to start playing with some apps, maybe the first/easiest could be Arizona's traffic generator (easily controlled)
then the chat?  ndnrtc?

> - Would the release of NFD coincide with NDN platform release?  If yes, then what is actually included?

this one is for Jeff.

> 
> On Jul 9, 2014, at 8:02 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
> 
>> 
>> On Jul 9, 2014, at 7:44 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>> 
>>> Hi, 
>>> 
>>> I agree with John's suggestions. 
>>> 
>>> What is the timeline for deployment on the testbed? 
>> 
>> my understanding is that John is working towards it as we speak.
>> 
>> yesterday at NFD daily call we also discussed what might be the timing for a public NFD announcement, perhaps depending on the speed/results of the testbed rollout experience.
>> 
>> 
>>> 
>>> Thanks,
>>> Jeff
>>> 
>>> 
>>> From: John DeHart <jdd at seas.wustl.edu>
>>> Date: Tue, 8 Jul 2014 13:18:37 -0500
>>> To: Alex Afanasyev <alexander.afanasyev at ucla.edu>, "<nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu>
>>> Subject: Re: [Nfd-dev] Feedback request for public release text
>>> 
>>>> 
>>>> Alex,
>>>> 
>>>> Nice job pulling this all together.
>>>> 
>>>> I would tend to agree that it may be a bit much for an announcement.
>>>> I would certainly take the list of per-module features out of the
>>>> announcement and just link to that info on a website.
>>>> 
>>>> John
>>>> 
>>>> 
>>>> On 7/8/14, 12:08 AM, Alex Afanasyev wrote:
>>>>> Hi guys,
>>>>> 
>>>>> I just finished making the first draft for the public release text that suppose to go to several public mailing lists.
>>>>> 
>>>>> Please take a look and give your comments asap.
>>>>> 
>>>>> Questions I have so far:
>>>>> 1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?
>>>>> 2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?
>>>>> 
>>>>> ---
>>>>> Alex
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Nfd-dev mailing list
>>>>> Nfd-dev at lists.cs.ucla.edu
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>> 
>>>> _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.eduhttp://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140709/48e126f7/attachment.html>

From bzhang at cs.arizona.edu  Thu Jul 10 08:33:01 2014
From: bzhang at cs.arizona.edu (Beichuan Zhang)
Date: Thu, 10 Jul 2014 08:33:01 -0700
Subject: [Nfd-dev] Feedback request for public release text
In-Reply-To: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>
References: <CBDF5954-3143-4F59-975B-F406481115B5@ucla.edu>
Message-ID: <86B0EFCB-3A4A-45F2-B06A-6F9315CB3FB7@cs.arizona.edu>

Hi Alex,

Thanks for the draft. My 2 cents are: drop the detailed feature list, add a couple of sentences about we?re committing to open source and encourage community involvement in future development.

Beichuan

On Jul 7, 2014, at 10:08 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> Hi guys,
> 
> I just finished making the first draft for the public release text that suppose to go to several public mailing lists.
> 
> Please take a look and give your comments asap.
> 
> Questions I have so far:
> 1. Isn't it too much for the announcement?  Would it better to just refer to website where we would have similar text?
> 2. Shall we refer our testbed deployment?  If yes, then should we add a join invitation like "if you want to join our Testbed, here is the link to the joining policy..." ?
> 
> ---
> Alex
> 
> <nfd-public-draft1.txt>
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From shijunxiao at email.arizona.edu  Tue Jul 15 00:02:56 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 15 Jul 2014 15:02:56 +0800
Subject: [Nfd-dev] repo-ng protocol: ChildSelector
Message-ID: <CAOFH+OaABy_AaR0wCfhvHCUV2xGfOMeXXYAFySPyxpgHJPEbwQ@mail.gmail.com>

Dear folks

I have difficulty understanding how repo-ng is expected to process
ChildSelector in the delete command.

Repo protocol <
http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors>
states:

   -
   - The concrete definitions of both standard NDN selectors and repo
   command selectors are the same.
   - the standard NDN selectors just matches one data packet that conforms
   to the selector conditions, but repo command selectors would matches any
   data packets.
   - Repo command supports parts of standard NDN interests including
   MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator,
   Exclude, ChildSelector.
   - selectors are just supported in delete command.

NDN-TLV spec <http://named-data.net/doc/ndn-tlv/interest.html#childselector>
states:

   - Often a given Interest can match more than one Data within a given
   content store. The ChildSelector provides a way of expressing a preference
   for which of these should be returned.

As I understand from these rules, an implementation is required to process
Selectors in a delete command, which is used as a filter to determine
whether a stored Data under the name prefix should be erased or not.
However, ChildSelector is different from other selectors in that it does
not provide a filter, but expresses a preference about which one Data
should be picked among multiple equally-admissible Data.

My question is: if ChildSelector is present in a delete command, should a
repo implementation evaluate the preference rules and erase only one Data,
or should this field be ignored?

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140715/981216fc/attachment.html>

From alexander.afanasyev at ucla.edu  Tue Jul 15 15:35:37 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 15 Jul 2014 15:35:37 -0700
Subject: [Nfd-dev] repo-ng protocol: ChildSelector
In-Reply-To: <CAOFH+OaABy_AaR0wCfhvHCUV2xGfOMeXXYAFySPyxpgHJPEbwQ@mail.gmail.com>
References: <CAOFH+OaABy_AaR0wCfhvHCUV2xGfOMeXXYAFySPyxpgHJPEbwQ@mail.gmail.com>
Message-ID: <5D611FA4-8077-4A33-A49E-EE1A47858FC2@ucla.edu>

My opinion is that semantics of delete operation in repo is different from semantics of search operation (given that only one packet can be returned).   When deleting, you suppose to already know what you're deleting and if you specify prefix (or prefix with child selector, which in turn also defines some prefix), then the whole subtree of this prefix should be deleted.

So, I'm voting for the following repo semantics:

- selector match in normal Interest is to retrieve any Data that matches selectors
- selector match for delete Interest is to delete all Data packet that matche selects

---
Alex

On Jul 15, 2014, at 12:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> I have difficulty understanding how repo-ng is expected to process ChildSelector in the delete command.
> 
> Repo protocol <http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors> states:
> The concrete definitions of both standard NDN selectors and repo command selectors are the same.
> the standard NDN selectors just matches one data packet that conforms to the selector conditions, but repo command selectors would matches any data packets.
> Repo command supports parts of standard NDN interests including MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator, Exclude, ChildSelector.
> selectors are just supported in delete command.
> NDN-TLV spec <http://named-data.net/doc/ndn-tlv/interest.html#childselector> states:
> Often a given Interest can match more than one Data within a given content store. The ChildSelector provides a way of expressing a preference for which of these should be returned.
> As I understand from these rules, an implementation is required to process Selectors in a delete command, which is used as a filter to determine whether a stored Data under the name prefix should be erased or not.
> However, ChildSelector is different from other selectors in that it does not provide a filter, but expresses a preference about which one Data should be picked among multiple equally-admissible Data.
> 
> My question is: if ChildSelector is present in a delete command, should a repo implementation evaluate the preference rules and erase only one Data, or should this field be ignored?
> 
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140715/ecab5203/attachment.html>

From chenatu2006 at gmail.com  Tue Jul 15 20:41:04 2014
From: chenatu2006 at gmail.com (Shuo Chen)
Date: Wed, 16 Jul 2014 11:41:04 +0800
Subject: [Nfd-dev] repo-ng protocol: ChildSelector
In-Reply-To: <5D611FA4-8077-4A33-A49E-EE1A47858FC2@ucla.edu>
References: <CAOFH+OaABy_AaR0wCfhvHCUV2xGfOMeXXYAFySPyxpgHJPEbwQ@mail.gmail.com>
	<5D611FA4-8077-4A33-A49E-EE1A47858FC2@ucla.edu>
Message-ID: <CADJo4H=qmzR2Mc2YFGZLvaA_3Gf3w+Bc4=iNvEd=13LHyK2nsA@mail.gmail.com>

The original design is like this:
Selector match for delete Interest is to delete all Data packet that match
selects. If you suppose delete one data, childselector should be added.
If delete command just contains names without any selector, repo will
delete all the data under this prefix.

----
Shuo Chen



On Wed, Jul 16, 2014 at 6:35 AM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

> My opinion is that semantics of delete operation in repo is different from
> semantics of search operation (given that only one packet can be returned).
>   When deleting, you suppose to already know what you're deleting and if
> you specify prefix (or prefix with child selector, which in turn also
> defines some prefix), then the whole subtree of this prefix should be
> deleted.
>
> So, I'm voting for the following repo semantics:
>
> - selector match in normal Interest is to retrieve any Data that matches
> selectors
> - selector match for delete Interest is to delete all Data packet that
> matche selects
>
> ---
> Alex
>
> On Jul 15, 2014, at 12:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Dear folks
>
> I have difficulty understanding how repo-ng is expected to process
> ChildSelector in the delete command.
>
> Repo protocol <
> http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors>
> states:
>
>    -
>    - The concrete definitions of both standard NDN selectors and repo
>    command selectors are the same.
>    - the standard NDN selectors just matches one data packet that
>    conforms to the selector conditions, but repo command selectors would
>    matches any data packets.
>    - Repo command supports parts of standard NDN interests including
>    MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator,
>    Exclude, ChildSelector.
>    - selectors are just supported in delete command.
>
> NDN-TLV spec <
> http://named-data.net/doc/ndn-tlv/interest.html#childselector> states:
>
>    - Often a given Interest can match more than one Data within a given
>    content store. The ChildSelector provides a way of expressing a preference
>    for which of these should be returned.
>
> As I understand from these rules, an implementation is required to process
> Selectors in a delete command, which is used as a filter to determine
> whether a stored Data under the name prefix should be erased or not.
> However, ChildSelector is different from other selectors in that it does
> not provide a filter, but expresses a preference about which one Data
> should be picked among multiple equally-admissible Data.
>
> My question is: if ChildSelector is present in a delete command, should a
> repo implementation evaluate the preference rules and erase only one Data,
> or should this field be ignored?
>
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140716/6348550c/attachment.html>

From alexander.afanasyev at ucla.edu  Tue Jul 15 21:46:05 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 15 Jul 2014 21:46:05 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
Message-ID: <578B7015-321F-4BF2-B469-D6FB9C6B2CA8@ucla.edu>

Hi Jeff and all,

We had a follow up discussion today about naming conventions and in particular we got to one question about "sequence numbers".   The CCNx naming convention that we going to revert for now defines markers for segments (sequential and non-sequential) and marker for version.  What this convention is missing is the marker for sequential sequence numbers for "infinite" collection.  Examples of this could be stream of generated notifications n NFD, dataset in ChronoSync, frames in webrtc (?).  In the past, we kind of used "segment" convention to represent such numbers, but during our discussion we agreed that there is different semantics for "segments" and "sequence numbers" and it is useful to explicitly distinguish between them:

- "Segment" is a Data packet that is a part of a bigger data blob (e.g., segments of one frame).  If third party (repo, cache, library?) understands this semantics, than it can try request all the segments and stop when finished.

- "Sequence number" (for "infinite" collections) denotes that the particular Data object is part of the collection, but is independent piece of this collection (individual frame).   It is also possible that such a piece can be further segmented.   If third parties understand this semantics, they can perform very different actions compared to segments.   

The proposal at hand is that we not just define markers for "segment" (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new notion of sequence numbers (say, %FE for now).

This definition doesn't imply we need to do any immediate change in any of the application we have.  It is just for the future applications/updates we use a more semantically correct ways to mark out sequence numbers.  This will also prepare libraries for any convention change later.  The place where we plan to use it right away is in NFD notification stream protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).

Can you give opinions about this proposal?

---
Alex




From alexander.afanasyev at ucla.edu  Tue Jul 15 22:10:32 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 15 Jul 2014 22:10:32 -0700
Subject: [Nfd-dev] repo-ng protocol: ChildSelector
In-Reply-To: <CADJo4H=qmzR2Mc2YFGZLvaA_3Gf3w+Bc4=iNvEd=13LHyK2nsA@mail.gmail.com>
References: <CAOFH+OaABy_AaR0wCfhvHCUV2xGfOMeXXYAFySPyxpgHJPEbwQ@mail.gmail.com>
	<5D611FA4-8077-4A33-A49E-EE1A47858FC2@ucla.edu>
	<CADJo4H=qmzR2Mc2YFGZLvaA_3Gf3w+Bc4=iNvEd=13LHyK2nsA@mail.gmail.com>
Message-ID: <6AB7D7D5-5F84-4C99-9316-6B55125DB8EA@ucla.edu>

Hi Shuo,

We talked today with Junxiao, Beichuan, Steve, and Lixia and I got convinced that ChildSelector is a special case.  While it makes a huge sense for Data retrieval, especially for discovery purposes, it has not a clear meaning for the deletion purposes.  When deleting, one better knows exactly what is being deleted (all data under prefix, all data that satisfy min/max suffix components within prefix, all data that satisfies exclude filter).   If we implement deletion of one Data packet when processing child selector, it could have nondeterministic behavior (which exactly "rightmost" data is deleted?).   Another angle to this is that multiple repeated deletion commands with the same selector should leave repo in the same state.  This is true for all selectors, except ChildSelector.

The conclusion that we made and I hope you can agree with :) is that we should remove ChildSelector in the repo deletion spec.  This would simplify implementation and eliminate some confusions.

--
Alex


On Jul 15, 2014, at 8:41 PM, Shuo Chen <chenatu2006 at gmail.com> wrote:

> The original design is like this:
> Selector match for delete Interest is to delete all Data packet that match selects. If you suppose delete one data, childselector should be added.
> If delete command just contains names without any selector, repo will delete all the data under this prefix.
> 
> ----
> Shuo Chen
> 
> 
> 
> On Wed, Jul 16, 2014 at 6:35 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> My opinion is that semantics of delete operation in repo is different from semantics of search operation (given that only one packet can be returned).   When deleting, you suppose to already know what you're deleting and if you specify prefix (or prefix with child selector, which in turn also defines some prefix), then the whole subtree of this prefix should be deleted.
> 
> So, I'm voting for the following repo semantics:
> 
> - selector match in normal Interest is to retrieve any Data that matches selectors
> - selector match for delete Interest is to delete all Data packet that matche selects
> 
> ---
> Alex
> 
> On Jul 15, 2014, at 12:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
>> Dear folks
>> 
>> I have difficulty understanding how repo-ng is expected to process ChildSelector in the delete command.
>> 
>> Repo protocol <http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors> states:
>> The concrete definitions of both standard NDN selectors and repo command selectors are the same.
>> the standard NDN selectors just matches one data packet that conforms to the selector conditions, but repo command selectors would matches any data packets.
>> Repo command supports parts of standard NDN interests including MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator, Exclude, ChildSelector.
>> selectors are just supported in delete command.
>> NDN-TLV spec <http://named-data.net/doc/ndn-tlv/interest.html#childselector> states:
>> Often a given Interest can match more than one Data within a given content store. The ChildSelector provides a way of expressing a preference for which of these should be returned.
>> As I understand from these rules, an implementation is required to process Selectors in a delete command, which is used as a filter to determine whether a stored Data under the name prefix should be erased or not.
>> However, ChildSelector is different from other selectors in that it does not provide a filter, but expresses a preference about which one Data should be picked among multiple equally-admissible Data.
>> 
>> My question is: if ChildSelector is present in a delete command, should a repo implementation evaluate the preference rules and erase only one Data, or should this field be ignored?
>> 
>> Yours, Junxiao
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140715/74f74653/attachment.html>

From chenatu2006 at gmail.com  Tue Jul 15 22:30:39 2014
From: chenatu2006 at gmail.com (Shuo Chen)
Date: Wed, 16 Jul 2014 13:30:39 +0800
Subject: [Nfd-dev] repo-ng protocol: ChildSelector
In-Reply-To: <6AB7D7D5-5F84-4C99-9316-6B55125DB8EA@ucla.edu>
References: <CAOFH+OaABy_AaR0wCfhvHCUV2xGfOMeXXYAFySPyxpgHJPEbwQ@mail.gmail.com>
	<5D611FA4-8077-4A33-A49E-EE1A47858FC2@ucla.edu>
	<CADJo4H=qmzR2Mc2YFGZLvaA_3Gf3w+Bc4=iNvEd=13LHyK2nsA@mail.gmail.com>
	<6AB7D7D5-5F84-4C99-9316-6B55125DB8EA@ucla.edu>
Message-ID: <CADJo4HmzDfLbF_w1vieWnYCB8WEk8VgPd_4qpPmF_DwQ_KygBQ@mail.gmail.com>

OK, I will revise that in redmine

--
Shuo Chen


On Wed, Jul 16, 2014 at 1:10 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

> Hi Shuo,
>
> We talked today with Junxiao, Beichuan, Steve, and Lixia and I got
> convinced that ChildSelector is a special case.  While it makes a huge
> sense for Data retrieval, especially for discovery purposes, it has not a
> clear meaning for the deletion purposes.  When deleting, one better knows
> exactly what is being deleted (all data under prefix, all data that satisfy
> min/max suffix components within prefix, all data that satisfies exclude
> filter).   If we implement deletion of one Data packet when processing
> child selector, it could have nondeterministic behavior (which exactly
> "rightmost" data is deleted?).   Another angle to this is that multiple
> repeated deletion commands with the same selector should leave repo in the
> same state.  This is true for all selectors, except ChildSelector.
>
> The conclusion that we made and I hope you can agree with :) is that we
> should remove ChildSelector in the repo deletion spec.  This would simplify
> implementation and eliminate some confusions.
>
> --
> Alex
>
>
> On Jul 15, 2014, at 8:41 PM, Shuo Chen <chenatu2006 at gmail.com> wrote:
>
> The original design is like this:
> Selector match for delete Interest is to delete all Data packet that match
> selects. If you suppose delete one data, childselector should be added.
> If delete command just contains names without any selector, repo will
> delete all the data under this prefix.
>
> ----
> Shuo Chen
>
>
>
> On Wed, Jul 16, 2014 at 6:35 AM, Alex Afanasyev <
> alexander.afanasyev at ucla.edu> wrote:
>
>> My opinion is that semantics of delete operation in repo is different
>> from semantics of search operation (given that only one packet can be
>> returned).   When deleting, you suppose to already know what you're
>> deleting and if you specify prefix (or prefix with child selector, which in
>> turn also defines some prefix), then the whole subtree of this prefix
>> should be deleted.
>>
>> So, I'm voting for the following repo semantics:
>>
>> - selector match in normal Interest is to retrieve any Data that matches
>> selectors
>> - selector match for delete Interest is to delete all Data packet that
>> matche selects
>>
>> ---
>> Alex
>>
>> On Jul 15, 2014, at 12:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>> Dear folks
>>
>> I have difficulty understanding how repo-ng is expected to process
>> ChildSelector in the delete command.
>>
>> Repo protocol <
>> http://redmine.named-data.net/projects/repo-ng/wiki/Repo_Protocol_Specification#Repo-Command-Selectors>
>> states:
>>
>>    -
>>    - The concrete definitions of both standard NDN selectors and repo
>>    command selectors are the same.
>>    - the standard NDN selectors just matches one data packet that
>>    conforms to the selector conditions, but repo command selectors would
>>    matches any data packets.
>>    - Repo command supports parts of standard NDN interests including
>>    MinSuffixComponents, MaxSuffixComponents, PublisherPublicKeyLocator,
>>    Exclude, ChildSelector.
>>    - selectors are just supported in delete command.
>>
>> NDN-TLV spec <
>> http://named-data.net/doc/ndn-tlv/interest.html#childselector> states:
>>
>>    - Often a given Interest can match more than one Data within a given
>>    content store. The ChildSelector provides a way of expressing a preference
>>    for which of these should be returned.
>>
>> As I understand from these rules, an implementation is required to
>> process Selectors in a delete command, which is used as a filter to
>> determine whether a stored Data under the name prefix should be erased or
>> not.
>> However, ChildSelector is different from other selectors in that it does
>> not provide a filter, but expresses a preference about which one Data
>> should be picked among multiple equally-admissible Data.
>>
>> My question is: if ChildSelector is present in a delete command, should a
>> repo implementation evaluate the preference rules and erase only one Data,
>> or should this field be ignored?
>>
>> Yours, Junxiao
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140716/f78f76f9/attachment.html>

From lanwang at memphis.EDU  Wed Jul 16 05:10:31 2014
From: lanwang at memphis.EDU (Lan Wang (lanwang))
Date: Wed, 16 Jul 2014 12:10:31 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <578B7015-321F-4BF2-B469-D6FB9C6B2CA8@ucla.edu>
References: <578B7015-321F-4BF2-B469-D6FB9C6B2CA8@ucla.edu>
Message-ID: <CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>

Alex,

What is the difference between Version and Sequence number?  Is Version based on timestamps?  If so, it seems that Version should be explicitly called Timestamp.  

Lan
On Jul 15, 2014, at 11:46 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> Hi Jeff and all,
> 
> We had a follow up discussion today about naming conventions and in particular we got to one question about "sequence numbers".   The CCNx naming convention that we going to revert for now defines markers for segments (sequential and non-sequential) and marker for version.  What this convention is missing is the marker for sequential sequence numbers for "infinite" collection.  Examples of this could be stream of generated notifications n NFD, dataset in ChronoSync, frames in webrtc (?).  In the past, we kind of used "segment" convention to represent such numbers, but during our discussion we agreed that there is different semantics for "segments" and "sequence numbers" and it is useful to explicitly distinguish between them:
> 
> - "Segment" is a Data packet that is a part of a bigger data blob (e.g., segments of one frame).  If third party (repo, cache, library?) understands this semantics, than it can try request all the segments and stop when finished.
> 
> - "Sequence number" (for "infinite" collections) denotes that the particular Data object is part of the collection, but is independent piece of this collection (individual frame).   It is also possible that such a piece can be further segmented.   If third parties understand this semantics, they can perform very different actions compared to segments.   
> 
> The proposal at hand is that we not just define markers for "segment" (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new notion of sequence numbers (say, %FE for now).
> 
> This definition doesn't imply we need to do any immediate change in any of the application we have.  It is just for the future applications/updates we use a more semantically correct ways to mark out sequence numbers.  This will also prepare libraries for any convention change later.  The place where we plan to use it right away is in NFD notification stream protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).
> 
> Can you give opinions about this proposal?
> 
> ---
> Alex
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From alexander.afanasyev at UCLA.EDU  Wed Jul 16 10:21:03 2014
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Wed, 16 Jul 2014 10:21:03 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>
References: <578B7015-321F-4BF2-B469-D6FB9C6B2CA8@ucla.edu>
	<CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>
Message-ID: <69FC1FCA-AEF2-4C5E-A7C1-EB5CE62C1AE0@ucla.edu>

Hi Lan,

Sequence number is not exactly a version.  A Data packet with the larger version should represent the same data, but just newer copy (say, two versions of nytimes webpage).  Sequence number is for completely different purposes, to represent independent Data items within a single data set/stream. Segments are for one data split into multiple chunks, e.g., for delivery purposes.

My take on markers is that their primary purpose is not describe the specific value, rather than define semantics of the value (which also implies specific syntax for the value).  If we name the version just "timestamp", then it wouldn't really mean anything for anybody outside the application. One would only know that this name component hold timestamp, but will be able only to guess the intention of the application to use timestamp in this component.

---
Alex

On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:

> Alex,
> 
> What is the difference between Version and Sequence number?  Is Version based on timestamps?  If so, it seems that Version should be explicitly called Timestamp.  
> 
> Lan
> On Jul 15, 2014, at 11:46 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
>> Hi Jeff and all,
>> 
>> We had a follow up discussion today about naming conventions and in particular we got to one question about "sequence numbers".   The CCNx naming convention that we going to revert for now defines markers for segments (sequential and non-sequential) and marker for version.  What this convention is missing is the marker for sequential sequence numbers for "infinite" collection.  Examples of this could be stream of generated notifications n NFD, dataset in ChronoSync, frames in webrtc (?).  In the past, we kind of used "segment" convention to represent such numbers, but during our discussion we agreed that there is different semantics for "segments" and "sequence numbers" and it is useful to explicitly distinguish between them:
>> 
>> - "Segment" is a Data packet that is a part of a bigger data blob (e.g., segments of one frame).  If third party (repo, cache, library?) understands this semantics, than it can try request all the segments and stop when finished.
>> 
>> - "Sequence number" (for "infinite" collections) denotes that the particular Data object is part of the collection, but is independent piece of this collection (individual frame).   It is also possible that such a piece can be further segmented.   If third parties understand this semantics, they can perform very different actions compared to segments.   
>> 
>> The proposal at hand is that we not just define markers for "segment" (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new notion of sequence numbers (say, %FE for now).
>> 
>> This definition doesn't imply we need to do any immediate change in any of the application we have.  It is just for the future applications/updates we use a more semantically correct ways to mark out sequence numbers.  This will also prepare libraries for any convention change later.  The place where we plan to use it right away is in NFD notification stream protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>> 
>> Can you give opinions about this proposal?
>> 
>> ---
>> Alex
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 




From jburke at remap.ucla.edu  Wed Jul 16 10:25:53 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Wed, 16 Jul 2014 17:25:53 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <69FC1FCA-AEF2-4C5E-A7C1-EB5CE62C1AE0@ucla.edu>
Message-ID: <CFEC0363.1541DF%jburke@remap.ucla.edu>

Hi, 

In practice this is ambiguous: The next frame in a video is both a newer
copy of the same data (update from the camera/sensor) if you are looking
at it as "live" but also the next item in a sequence when it is a record.

I'll be able to respond to the proposal later, this is really interesting
to consider. 

Jeff


On 7/16/14, 10:21 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

>Hi Lan,
>
>Sequence number is not exactly a version.  A Data packet with the larger
>version should represent the same data, but just newer copy (say, two
>versions of nytimes webpage).  Sequence number is for completely
>different purposes, to represent independent Data items within a single
>data set/stream. Segments are for one data split into multiple chunks,
>e.g., for delivery purposes.
>
>My take on markers is that their primary purpose is not describe the
>specific value, rather than define semantics of the value (which also
>implies specific syntax for the value).  If we name the version just
>"timestamp", then it wouldn't really mean anything for anybody outside
>the application. One would only know that this name component hold
>timestamp, but will be able only to guess the intention of the
>application to use timestamp in this component.
>
>---
>Alex
>
>On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
>wrote:
>
>> Alex,
>> 
>> What is the difference between Version and Sequence number?  Is Version
>>based on timestamps?  If so, it seems that Version should be explicitly
>>called Timestamp.
>> 
>> Lan
>> On Jul 15, 2014, at 11:46 PM, Alex Afanasyev
>><alexander.afanasyev at ucla.edu> wrote:
>> 
>>> Hi Jeff and all,
>>> 
>>> We had a follow up discussion today about naming conventions and in
>>>particular we got to one question about "sequence numbers".   The CCNx
>>>naming convention that we going to revert for now defines markers for
>>>segments (sequential and non-sequential) and marker for version.  What
>>>this convention is missing is the marker for sequential sequence
>>>numbers for "infinite" collection.  Examples of this could be stream of
>>>generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>>(?).  In the past, we kind of used "segment" convention to represent
>>>such numbers, but during our discussion we agreed that there is
>>>different semantics for "segments" and "sequence numbers" and it is
>>>useful to explicitly distinguish between them:
>>> 
>>> - "Segment" is a Data packet that is a part of a bigger data blob
>>>(e.g., segments of one frame).  If third party (repo, cache, library?)
>>>understands this semantics, than it can try request all the segments
>>>and stop when finished.
>>> 
>>> - "Sequence number" (for "infinite" collections) denotes that the
>>>particular Data object is part of the collection, but is independent
>>>piece of this collection (individual frame).   It is also possible that
>>>such a piece can be further segmented.   If third parties understand
>>>this semantics, they can perform very different actions compared to
>>>segments.   
>>> 
>>> The proposal at hand is that we not just define markers for "segment"
>>>(%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>>notion of sequence numbers (say, %FE for now).
>>> 
>>> This definition doesn't imply we need to do any immediate change in
>>>any of the application we have.  It is just for the future
>>>applications/updates we use a more semantically correct ways to mark
>>>out sequence numbers.  This will also prepare libraries for any
>>>convention change later.  The place where we plan to use it right away
>>>is in NFD notification stream protocol
>>>(http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>> 
>>> Can you give opinions about this proposal?
>>> 
>>> ---
>>> Alex
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>




From lixia at CS.UCLA.EDU  Wed Jul 16 10:35:07 2014
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Wed, 16 Jul 2014 10:35:07 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>
References: <578B7015-321F-4BF2-B469-D6FB9C6B2CA8@ucla.edu>
	<CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>
Message-ID: <BFF42C59-B7FE-4DAD-8BC7-BDF5A66F4787@cs.ucla.edu>


On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:

> Alex,
> 
> What is the difference between Version and Sequence number?  Is Version based on timestamps?  If so, it seems that Version should be explicitly called Timestamp.  
> 
> Lan

there are cases one is preferred over the other depending on app needs.
there are cases both are used: see RFC 3550 (RTP) as an example: it uses both timestamp and seq#
the former can tell the time gaps between data
the latter can tell whether any piece is missing


> On Jul 15, 2014, at 11:46 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
>> Hi Jeff and all,
>> 
>> We had a follow up discussion today about naming conventions and in particular we got to one question about "sequence numbers".   The CCNx naming convention that we going to revert for now defines markers for segments (sequential and non-sequential) and marker for version.  What this convention is missing is the marker for sequential sequence numbers for "infinite" collection.  Examples of this could be stream of generated notifications n NFD, dataset in ChronoSync, frames in webrtc (?).  In the past, we kind of used "segment" convention to represent such numbers, but during our discussion we agreed that there is different semantics for "segments" and "sequence numbers" and it is useful to explicitly distinguish between them:
>> 
>> - "Segment" is a Data packet that is a part of a bigger data blob (e.g., segments of one frame).  If third party (repo, cache, library?) understands this semantics, than it can try request all the segments and stop when finished.
>> 
>> - "Sequence number" (for "infinite" collections) denotes that the particular Data object is part of the collection, but is independent piece of this collection (individual frame).   It is also possible that such a piece can be further segmented.   If third parties understand this semantics, they can perform very different actions compared to segments.   
>> 
>> The proposal at hand is that we not just define markers for "segment" (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new notion of sequence numbers (say, %FE for now).
>> 
>> This definition doesn't imply we need to do any immediate change in any of the application we have.  It is just for the future applications/updates we use a more semantically correct ways to mark out sequence numbers.  This will also prepare libraries for any convention change later.  The place where we plan to use it right away is in NFD notification stream protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>> 
>> Can you give opinions about this proposal?
>> 
>> ---
>> Alex
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From alexander.afanasyev at ucla.edu  Wed Jul 16 14:00:52 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 16 Jul 2014 14:00:52 -0700
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
Message-ID: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>

Hi guys,

I have a proposal to slightly modify the current policy for branching in our repos to partially match the git flow model described http://nvie.com/posts/a-successful-git-branching-model/.

The part I'm not entirely agreeing with is the role that devoted to master branch in this model: it always points to the latest release.  Personally, 'master' branch for me is the place for development, while there could be other "release" branch to track latest releases.   The rest of the workflow generally follows what we have been doing in the past, just formalized operations a little.

If agreed, I will create "release-0.2.0" branch in both repos that will fix all the features for the upcoming release.  All pending/approved commits on gerrit then can be merged into master, which will track further development.

Any objections?

---
Alex




From shijunxiao at email.arizona.edu  Wed Jul 16 15:10:34 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 17 Jul 2014 06:10:34 +0800
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
In-Reply-To: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
References: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
Message-ID: <CAOFH+OYjDRUPn8pUTUWNU57gxq3B8U85jT2vGmdMCX7ZGPqBaQ@mail.gmail.com>

Dear folks

As I understand, the git flow model + change of master role results in the
following:

* releases are tagged, and also have branches with prefix "release-"
* features need feature branches
* feature branches are merged into master branch, which reflects latest
developments

This differs from current practice in that:

* release branches add "release-" prefix
* feature branches are used

I agree with adding a "release-" prefix to release branches.

I disagree with using feature branches, because merging conflicts would be
a problem.
Every Change should still target to master branch.

Yours, Junxiao
On Jul 17, 2014 5:01 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

> Hi guys,
>
> I have a proposal to slightly modify the current policy for branching in
> our repos to partially match the git flow model described
> http://nvie.com/posts/a-successful-git-branching-model/.
>
> The part I'm not entirely agreeing with is the role that devoted to master
> branch in this model: it always points to the latest release.  Personally,
> 'master' branch for me is the place for development, while there could be
> other "release" branch to track latest releases.   The rest of the workflow
> generally follows what we have been doing in the past, just formalized
> operations a little.
>
> If agreed, I will create "release-0.2.0" branch in both repos that will
> fix all the features for the upcoming release.  All pending/approved
> commits on gerrit then can be merged into master, which will track further
> development.
>
> Any objections?
>
> ---
> Alex
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140717/3e593733/attachment.html>

From alexander.afanasyev at UCLA.EDU  Wed Jul 16 16:03:18 2014
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Wed, 16 Jul 2014 16:03:18 -0700
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
In-Reply-To: <CAOFH+OYjDRUPn8pUTUWNU57gxq3B8U85jT2vGmdMCX7ZGPqBaQ@mail.gmail.com>
References: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
	<CAOFH+OYjDRUPn8pUTUWNU57gxq3B8U85jT2vGmdMCX7ZGPqBaQ@mail.gmail.com>
Message-ID: <C9E20DA2-3D08-4A83-B7DE-A9A1150459FB@ucla.edu>

My understanding is slightly different, but in any case it aligns with your concern about the feature branches.  I don't think that the described git flow requires you to use feature branches for everything.  It allows you to do this, but doesn't mandate (I have used it a few times before).  Given that we also have code review system in place, it in most cases replaces this process ( "feature branch" is basically a series of patch sets).

Also, as I understand the flow, the release-* branches are temporary and they go away as soon as the release is finalized and tagged.

So, the short list of proposed updates:

- we will create "release-<version>" branch for preparation for <version> release.  When the release is finalized, we tag the release and remove the branch.

- we will have "release" branch that will track the latest release (release = latest release tag)

- for problems discovered for the released <version>, we can use "hotfix-<version>+" branch, which is merged back to "master" and "release" branches, and then tagged as then next minor release

- feature branches can be used (if a complex feature needs to be separated in multiple inter-dependent commits before merged to master), but they mostly replaced by the code review process.

---
Alex

On Jul 16, 2014, at 3:10 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> As I understand, the git flow model + change of master role results in the following:
> 
> * releases are tagged, and also have branches with prefix "release-"
> * features need feature branches
> * feature branches are merged into master branch, which reflects latest developments
> 
> This differs from current practice in that:
> 
> * release branches add "release-" prefix
> * feature branches are used
> 
> I agree with adding a "release-" prefix to release branches.
> 
> I disagree with using feature branches, because merging conflicts would be a problem.
> Every Change should still target to master branch.
> 
> Yours, Junxiao
> 
> On Jul 17, 2014 5:01 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
> Hi guys,
> 
> I have a proposal to slightly modify the current policy for branching in our repos to partially match the git flow model described http://nvie.com/posts/a-successful-git-branching-model/.
> 
> The part I'm not entirely agreeing with is the role that devoted to master branch in this model: it always points to the latest release.  Personally, 'master' branch for me is the place for development, while there could be other "release" branch to track latest releases.   The rest of the workflow generally follows what we have been doing in the past, just formalized operations a little.
> 
> If agreed, I will create "release-0.2.0" branch in both repos that will fix all the features for the upcoming release.  All pending/approved commits on gerrit then can be merged into master, which will track further development.
> 
> Any objections?
> 
> ---
> Alex
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140716/0eceea39/attachment.html>

From davide.pesavento at lip6.fr  Wed Jul 16 16:04:26 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Thu, 17 Jul 2014 01:04:26 +0200
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
In-Reply-To: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
References: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
Message-ID: <CADfzvvY7LfBY-F7o2ThrX85dTRCwPpfqKfLmfsQHpFFbMhL38A@mail.gmail.com>

Hi Alex,

I've been waiting for this, thanks.

In general I agree with moving to a more formalized git branching
model, however I'm not sure if the model you're proposing is
appropriate for our workflow. I find it a bit too complex and
heavyweight for small/medium-sized projects such as NFD. Moreover,
that model doesn't take gerrit and the CI into account, and has been
designed with the requirement that the master branch must contain code
that is deployable on a production server at any time, which is not
relevant for us.

I think that the following is enough for our use cases:

* patches usually target the master branch and are sent to gerrit for
review and integration testing
* some time before releasing version-N (1-2-3 weeks?) a release-N
branch is created from the master branch
* from that point, master will contain the code for release-N+1 and
all patches intended for version N+1 are submitted to the master
branch
* fixes or other urgent patches needed for version-N must be
retargeted to the release-N branch (i.e. rebased and resubmitted to
gerrit)
* when version-N is released, the release-N branch is tagged with the
"vN" tag, and is then merged back to the master branch
* if need be, the release-N branch can be used for "point" releases,
i.e. vN.1, vN.2, and so on, or alternatively we can create another
branch release-N.1

I hope I didn't forget something.

Thanks,
Davide

On Wed, Jul 16, 2014 at 11:00 PM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
> Hi guys,
>
> I have a proposal to slightly modify the current policy for branching in our repos to partially match the git flow model described http://nvie.com/posts/a-successful-git-branching-model/.
>
> The part I'm not entirely agreeing with is the role that devoted to master branch in this model: it always points to the latest release.  Personally, 'master' branch for me is the place for development, while there could be other "release" branch to track latest releases.   The rest of the workflow generally follows what we have been doing in the past, just formalized operations a little.
>
> If agreed, I will create "release-0.2.0" branch in both repos that will fix all the features for the upcoming release.  All pending/approved commits on gerrit then can be merged into master, which will track further development.
>
> Any objections?
>
> ---
> Alex
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



From alexander.afanasyev at ucla.edu  Wed Jul 16 16:12:20 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 16 Jul 2014 16:12:20 -0700
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
In-Reply-To: <CADfzvvY7LfBY-F7o2ThrX85dTRCwPpfqKfLmfsQHpFFbMhL38A@mail.gmail.com>
References: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
	<CADfzvvY7LfBY-F7o2ThrX85dTRCwPpfqKfLmfsQHpFFbMhL38A@mail.gmail.com>
Message-ID: <C98A8BDA-5A8C-4637-9FA6-51F4112894D7@ucla.edu>

Thanks, Davide.  I think we are on the same page.  I also want "master" branch to track all current development, not just releases.  I can forget about the "release" branch I mentioned in the reply to Junxiao, but it is a minor convenience branch that we can still have without any strings attached.

I agree with all other points.

---
Alex

On Jul 16, 2014, at 4:04 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> Hi Alex,
> 
> I've been waiting for this, thanks.
> 
> In general I agree with moving to a more formalized git branching
> model, however I'm not sure if the model you're proposing is
> appropriate for our workflow. I find it a bit too complex and
> heavyweight for small/medium-sized projects such as NFD. Moreover,
> that model doesn't take gerrit and the CI into account, and has been
> designed with the requirement that the master branch must contain code
> that is deployable on a production server at any time, which is not
> relevant for us.
> 
> I think that the following is enough for our use cases:
> 
> * patches usually target the master branch and are sent to gerrit for
> review and integration testing
> * some time before releasing version-N (1-2-3 weeks?) a release-N
> branch is created from the master branch
> * from that point, master will contain the code for release-N+1 and
> all patches intended for version N+1 are submitted to the master
> branch
> * fixes or other urgent patches needed for version-N must be
> retargeted to the release-N branch (i.e. rebased and resubmitted to
> gerrit)
> * when version-N is released, the release-N branch is tagged with the
> "vN" tag, and is then merged back to the master branch
> * if need be, the release-N branch can be used for "point" releases,
> i.e. vN.1, vN.2, and so on, or alternatively we can create another
> branch release-N.1
> 
> I hope I didn't forget something.
> 
> Thanks,
> Davide
> 
> On Wed, Jul 16, 2014 at 11:00 PM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> Hi guys,
>> 
>> I have a proposal to slightly modify the current policy for branching in our repos to partially match the git flow model described http://nvie.com/posts/a-successful-git-branching-model/.
>> 
>> The part I'm not entirely agreeing with is the role that devoted to master branch in this model: it always points to the latest release.  Personally, 'master' branch for me is the place for development, while there could be other "release" branch to track latest releases.   The rest of the workflow generally follows what we have been doing in the past, just formalized operations a little.
>> 
>> If agreed, I will create "release-0.2.0" branch in both repos that will fix all the features for the upcoming release.  All pending/approved commits on gerrit then can be merged into master, which will track further development.
>> 
>> Any objections?
>> 
>> ---
>> Alex
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From davide.pesavento at lip6.fr  Wed Jul 16 16:21:00 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Thu, 17 Jul 2014 01:21:00 +0200
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
In-Reply-To: <C9E20DA2-3D08-4A83-B7DE-A9A1150459FB@ucla.edu>
References: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
	<CAOFH+OYjDRUPn8pUTUWNU57gxq3B8U85jT2vGmdMCX7ZGPqBaQ@mail.gmail.com>
	<C9E20DA2-3D08-4A83-B7DE-A9A1150459FB@ucla.edu>
Message-ID: <CADfzvvZn_3YUCDGo1zcXW8Q=nqzPbJXRpG9K6x6enhAAOLXGLw@mail.gmail.com>

On Thu, Jul 17, 2014 at 1:03 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
> My understanding is slightly different, but in any case it aligns with your
> concern about the feature branches.  I don't think that the described git
> flow requires you to use feature branches for everything.  It allows you to
> do this, but doesn't mandate (I have used it a few times before).  Given
> that we also have code review system in place, it in most cases replaces
> this process ( "feature branch" is basically a series of patch sets).

Are you talking about remote (i.e. server-side) feature branches?

>
> Also, as I understand the flow, the release-* branches are temporary and
> they go away as soon as the release is finalized and tagged.
>

Yes, or you can keep them in order to make hotfix releases if needed,
in which case the "release" branch would be unnecessary. I don't have
a strong opinion either way.

> So, the short list of proposed updates:
>
> - we will create "release-<version>" branch for preparation for <version>
> release.  When the release is finalized, we tag the release and remove the
> branch.

Remember to merge back to master after tagging.

>
> - we will have "release" branch that will track the latest release (release
> = latest release tag)
>

Yes or, as I said, keep the various release-N branches. But probably a
single branch generates less noise and less confusion...?

Another question is: what is the default branch that gets checked out
when cloning? master or release?

> - for problems discovered for the released <version>, we can use
> "hotfix-<version>+" branch, which is merged back to "master" and "release"
> branches, and then tagged as then next minor release
>

Just call it "release-X.1", "release-X.2", etc... less confusion in my opinion.

> - feature branches can be used (if a complex feature needs to be separated
> in multiple inter-dependent commits before merged to master), but they
> mostly replaced by the code review process.
>
> ---
> Alex
>
> On Jul 16, 2014, at 3:10 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Dear folks
>
> As I understand, the git flow model + change of master role results in the
> following:
>
> * releases are tagged, and also have branches with prefix "release-"
> * features need feature branches
> * feature branches are merged into master branch, which reflects latest
> developments
>
> This differs from current practice in that:
>
> * release branches add "release-" prefix
> * feature branches are used
>
> I agree with adding a "release-" prefix to release branches.
>
> I disagree with using feature branches, because merging conflicts would be a
> problem.
> Every Change should still target to master branch.
>
> Yours, Junxiao
>
> On Jul 17, 2014 5:01 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
> wrote:
>>
>> Hi guys,
>>
>> I have a proposal to slightly modify the current policy for branching in
>> our repos to partially match the git flow model described
>> http://nvie.com/posts/a-successful-git-branching-model/.
>>
>> The part I'm not entirely agreeing with is the role that devoted to master
>> branch in this model: it always points to the latest release.  Personally,
>> 'master' branch for me is the place for development, while there could be
>> other "release" branch to track latest releases.   The rest of the workflow
>> generally follows what we have been doing in the past, just formalized
>> operations a little.
>>
>> If agreed, I will create "release-0.2.0" branch in both repos that will
>> fix all the features for the upcoming release.  All pending/approved commits
>> on gerrit then can be merged into master, which will track further
>> development.
>>
>> Any objections?
>>
>> ---
>> Alex
>>
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From alexander.afanasyev at ucla.edu  Wed Jul 16 18:50:03 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 16 Jul 2014 18:50:03 -0700
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
In-Reply-To: <CADfzvvZn_3YUCDGo1zcXW8Q=nqzPbJXRpG9K6x6enhAAOLXGLw@mail.gmail.com>
References: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
	<CAOFH+OYjDRUPn8pUTUWNU57gxq3B8U85jT2vGmdMCX7ZGPqBaQ@mail.gmail.com>
	<C9E20DA2-3D08-4A83-B7DE-A9A1150459FB@ucla.edu>
	<CADfzvvZn_3YUCDGo1zcXW8Q=nqzPbJXRpG9K6x6enhAAOLXGLw@mail.gmail.com>
Message-ID: <42A60F6F-BE80-4D78-9352-9EC49869C3FF@ucla.edu>


On Jul 16, 2014, at 4:21 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> On Thu, Jul 17, 2014 at 1:03 AM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> My understanding is slightly different, but in any case it aligns with your
>> concern about the feature branches.  I don't think that the described git
>> flow requires you to use feature branches for everything.  It allows you to
>> do this, but doesn't mandate (I have used it a few times before).  Given
>> that we also have code review system in place, it in most cases replaces
>> this process ( "feature branch" is basically a series of patch sets).
> 
> Are you talking about remote (i.e. server-side) feature branches?

If needed, either can be used.  But only if really needed.

>> 
>> Also, as I understand the flow, the release-* branches are temporary and
>> they go away as soon as the release is finalized and tagged.
>> 
> 
> Yes, or you can keep them in order to make hotfix releases if needed,
> in which case the "release" branch would be unnecessary. I don't have
> a strong opinion either way.
> 
>> So, the short list of proposed updates:
>> 
>> - we will create "release-<version>" branch for preparation for <version>
>> release.  When the release is finalized, we tag the release and remove the
>> branch.
> 
> Remember to merge back to master after tagging.
> 
>> 
>> - we will have "release" branch that will track the latest release (release
>> = latest release tag)
>> 
> 
> Yes or, as I said, keep the various release-N branches. But probably a
> single branch generates less noise and less confusion...?
> 
> Another question is: what is the default branch that gets checked out
> when cloning? master or release?

This will remain "master" (where most development happens).

>> - for problems discovered for the released <version>, we can use
>> "hotfix-<version>+" branch, which is merged back to "master" and "release"
>> branches, and then tagged as then next minor release
>> 
> 
> Just call it "release-X.1", "release-X.2", etc... less confusion in my opinion.

I already create release-0.2.0 this time.  Next time we could remove the last zero.

---
Alex

>> - feature branches can be used (if a complex feature needs to be separated
>> in multiple inter-dependent commits before merged to master), but they
>> mostly replaced by the code review process.
>> 
>> ---
>> Alex
>> 
>> On Jul 16, 2014, at 3:10 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>> 
>> Dear folks
>> 
>> As I understand, the git flow model + change of master role results in the
>> following:
>> 
>> * releases are tagged, and also have branches with prefix "release-"
>> * features need feature branches
>> * feature branches are merged into master branch, which reflects latest
>> developments
>> 
>> This differs from current practice in that:
>> 
>> * release branches add "release-" prefix
>> * feature branches are used
>> 
>> I agree with adding a "release-" prefix to release branches.
>> 
>> I disagree with using feature branches, because merging conflicts would be a
>> problem.
>> Every Change should still target to master branch.
>> 
>> Yours, Junxiao
>> 
>> On Jul 17, 2014 5:01 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
>> wrote:
>>> 
>>> Hi guys,
>>> 
>>> I have a proposal to slightly modify the current policy for branching in
>>> our repos to partially match the git flow model described
>>> http://nvie.com/posts/a-successful-git-branching-model/.
>>> 
>>> The part I'm not entirely agreeing with is the role that devoted to master
>>> branch in this model: it always points to the latest release.  Personally,
>>> 'master' branch for me is the place for development, while there could be
>>> other "release" branch to track latest releases.   The rest of the workflow
>>> generally follows what we have been doing in the past, just formalized
>>> operations a little.
>>> 
>>> If agreed, I will create "release-0.2.0" branch in both repos that will
>>> fix all the features for the upcoming release.  All pending/approved commits
>>> on gerrit then can be merged into master, which will track further
>>> development.
>>> 
>>> Any objections?
>>> 
>>> ---
>>> Alex
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From davide.pesavento at lip6.fr  Thu Jul 17 04:39:21 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Thu, 17 Jul 2014 13:39:21 +0200
Subject: [Nfd-dev] Small branching policy change for NFD and ndn-cxx
	(proposal)
In-Reply-To: <42A60F6F-BE80-4D78-9352-9EC49869C3FF@ucla.edu>
References: <F8121BCA-CBC9-4B12-B189-F79AC05244CF@ucla.edu>
	<CAOFH+OYjDRUPn8pUTUWNU57gxq3B8U85jT2vGmdMCX7ZGPqBaQ@mail.gmail.com>
	<C9E20DA2-3D08-4A83-B7DE-A9A1150459FB@ucla.edu>
	<CADfzvvZn_3YUCDGo1zcXW8Q=nqzPbJXRpG9K6x6enhAAOLXGLw@mail.gmail.com>
	<42A60F6F-BE80-4D78-9352-9EC49869C3FF@ucla.edu>
Message-ID: <CADfzvvZnreReSfv85aeUqpAR2Z=_T3cExCoh6ZU1=yyZvjUu0Q@mail.gmail.com>

On Thu, Jul 17, 2014 at 3:50 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
>
> On Jul 16, 2014, at 4:21 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
>
>> On Thu, Jul 17, 2014 at 1:03 AM, Alex Afanasyev
>> <alexander.afanasyev at ucla.edu> wrote:
>>> My understanding is slightly different, but in any case it aligns with your
>>> concern about the feature branches.  I don't think that the described git
>>> flow requires you to use feature branches for everything.  It allows you to
>>> do this, but doesn't mandate (I have used it a few times before).  Given
>>> that we also have code review system in place, it in most cases replaces
>>> this process ( "feature branch" is basically a series of patch sets).
>>
>> Are you talking about remote (i.e. server-side) feature branches?
>
> If needed, either can be used.  But only if really needed.
>

Well, as far as local feature branches are concerned, I use them all
the time and then push to refs/for/master. I don't think we should
mandate how developers are supposed to work locally on their machines,
as long as they push to master or release-N for review...

>>>
>>> Also, as I understand the flow, the release-* branches are temporary and
>>> they go away as soon as the release is finalized and tagged.
>>>
>>
>> Yes, or you can keep them in order to make hotfix releases if needed,
>> in which case the "release" branch would be unnecessary. I don't have
>> a strong opinion either way.
>>
>>> So, the short list of proposed updates:
>>>
>>> - we will create "release-<version>" branch for preparation for <version>
>>> release.  When the release is finalized, we tag the release and remove the
>>> branch.
>>
>> Remember to merge back to master after tagging.
>>
>>>
>>> - we will have "release" branch that will track the latest release (release
>>> = latest release tag)
>>>
>>
>> Yes or, as I said, keep the various release-N branches. But probably a
>> single branch generates less noise and less confusion...?
>>
>> Another question is: what is the default branch that gets checked out
>> when cloning? master or release?
>
> This will remain "master" (where most development happens).
>
>>> - for problems discovered for the released <version>, we can use
>>> "hotfix-<version>+" branch, which is merged back to "master" and "release"
>>> branches, and then tagged as then next minor release
>>>
>>
>> Just call it "release-X.1", "release-X.2", etc... less confusion in my opinion.
>
> I already create release-0.2.0 this time.  Next time we could remove the last zero.

Ah no sorry, what I meant was to call it "release-<something>" rather
than "hotfix-<something>". The final .0 is fine, I don't care.

Thanks,
Davide


From alexander.afanasyev at ucla.edu  Fri Jul 18 14:14:52 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 18 Jul 2014 14:14:52 -0700
Subject: [Nfd-dev] Question about test / dependencies
Message-ID: <3F4F0D04-9A6C-4D6F-BF61-2AACB233EDBD@ucla.edu>

Hi everybody,

Given that we are no longer using master branch for ndn-cxx and NFD (e.g., for preparation of the release, we are using now release-* branches),  how exactly jenkins checks should be organized?  Should we somehow manually in jenkins script match branches or should we introduce explicit notion of dependencies?

What I have in mind is that we include .jenkins build script(s) inside the repo, instead of keeping it(them) in just jenkins config.  This way, all test dependencies can be explicitly defined.  Is that reasonable?

Alternative is to use git submodules to track specific version of the library, but I don't really like this idea.

---
Alex




From lanwang at memphis.EDU  Sat Jul 19 05:05:18 2014
From: lanwang at memphis.EDU (Lan Wang (lanwang))
Date: Sat, 19 Jul 2014 12:05:18 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <BFF42C59-B7FE-4DAD-8BC7-BDF5A66F4787@cs.ucla.edu>
References: <578B7015-321F-4BF2-B469-D6FB9C6B2CA8@ucla.edu>
	<CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>
	<BFF42C59-B7FE-4DAD-8BC7-BDF5A66F4787@cs.ucla.edu>
Message-ID: <836FC0EB-3188-4E25-A8E5-DC0DEF007EA0@memphis.edu>


On Jul 16, 2014, at 12:35 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:

> 
> On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
> 
>> Alex,
>> 
>> What is the difference between Version and Sequence number?  Is Version based on timestamps?  If so, it seems that Version should be explicitly called Timestamp.  
>> 
>> Lan
> 
> there are cases one is preferred over the other depending on app needs.
> there are cases both are used: see RFC 3550 (RTP) as an example: it uses both timestamp and seq#
> the former can tell the time gaps between data
> the latter can tell whether any piece is missing

Yes, agree that timestamp and seq# can be both useful.  I was just trying to point out that the Version concept is vague and I agree with Jeff that there's a no clear distinction between version and sequence number.  So instead of trying to define the semantic of version and sequence, why not just use timestamp (which doesn't have to be sequential) and seq# (which has to be sequential)?  The application can use either one or both to differentiate between different pieces of data.

Lan
> 
> 
>> On Jul 15, 2014, at 11:46 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
>> 
>>> Hi Jeff and all,
>>> 
>>> We had a follow up discussion today about naming conventions and in particular we got to one question about "sequence numbers".   The CCNx naming convention that we going to revert for now defines markers for segments (sequential and non-sequential) and marker for version.  What this convention is missing is the marker for sequential sequence numbers for "infinite" collection.  Examples of this could be stream of generated notifications n NFD, dataset in ChronoSync, frames in webrtc (?).  In the past, we kind of used "segment" convention to represent such numbers, but during our discussion we agreed that there is different semantics for "segments" and "sequence numbers" and it is useful to explicitly distinguish between them:
>>> 
>>> - "Segment" is a Data packet that is a part of a bigger data blob (e.g., segments of one frame).  If third party (repo, cache, library?) understands this semantics, than it can try request all the segments and stop when finished.
>>> 
>>> - "Sequence number" (for "infinite" collections) denotes that the particular Data object is part of the collection, but is independent piece of this collection (individual frame).   It is also possible that such a piece can be further segmented.   If third parties understand this semantics, they can perform very different actions compared to segments.   
>>> 
>>> The proposal at hand is that we not just define markers for "segment" (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new notion of sequence numbers (say, %FE for now).
>>> 
>>> This definition doesn't imply we need to do any immediate change in any of the application we have.  It is just for the future applications/updates we use a more semantically correct ways to mark out sequence numbers.  This will also prepare libraries for any convention change later.  The place where we plan to use it right away is in NFD notification stream protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>> 
>>> Can you give opinions about this proposal?
>>> 
>>> ---
>>> Alex
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 




From lixia at CS.UCLA.EDU  Sat Jul 19 06:30:40 2014
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sat, 19 Jul 2014 06:30:40 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <836FC0EB-3188-4E25-A8E5-DC0DEF007EA0@memphis.edu>
References: <578B7015-321F-4BF2-B469-D6FB9C6B2CA8@ucla.edu>
	<CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>
	<BFF42C59-B7FE-4DAD-8BC7-BDF5A66F4787@cs.ucla.edu>
	<836FC0EB-3188-4E25-A8E5-DC0DEF007EA0@memphis.edu>
Message-ID: <410C2C9F-97F7-42BA-A5A3-72A3B16047C2@cs.ucla.edu>


On Jul 19, 2014, at 5:05 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:

> 
> On Jul 16, 2014, at 12:35 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
> 
>> 
>> On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
>> 
>>> Alex,
>>> 
>>> What is the difference between Version and Sequence number?  Is Version based on timestamps?  If so, it seems that Version should be explicitly called Timestamp.  
>>> 
>>> Lan
>> 
>> there are cases one is preferred over the other depending on app needs.
>> there are cases both are used: see RFC 3550 (RTP) as an example: it uses both timestamp and seq#
>> the former can tell the time gaps between data
>> the latter can tell whether any piece is missing
> 
> Yes, agree that timestamp and seq# can be both useful.  I was just trying to point out that the Version concept is vague and I agree with Jeff that there's a no clear distinction between version and sequence number.  So instead of trying to define the semantic of version and sequence, why not just use timestamp (which doesn't have to be sequential) and seq# (which has to be sequential)?  The application can use either one or both to differentiate between different pieces of data.
> 
> Lan

We agree; I misunderstood your original msg.
as far as I understand, the current definition of version value is timestamp.  
Alex's original msg simply argues for a need to be able to distinctively mark seq# in addition to that (timestamp).
If we mark timestamp as timestamp, then do we still need a "version" marker?

Lixia


From jburke at remap.UCLA.EDU  Sat Jul 19 07:42:41 2014
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sat, 19 Jul 2014 14:42:41 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <410C2C9F-97F7-42BA-A5A3-72A3B16047C2@cs.ucla.edu>
Message-ID: <CFEFD1BA.15466F%jburke@remap.ucla.edu>

Semantically, seems like versions could skip values; could a sequence?
(Again not sure the distinctions are needed in the conventions, but I
think these definitions should accommodate fuzziness...)

Jeff


On 7/19/14, 6:30 AM, "Lixia Zhang" <lixia at CS.UCLA.EDU> wrote:

>
>On Jul 19, 2014, at 5:05 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
>wrote:
>
>> 
>> On Jul 16, 2014, at 12:35 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
>> 
>>> 
>>> On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
>>>wrote:
>>> 
>>>> Alex,
>>>> 
>>>> What is the difference between Version and Sequence number?  Is
>>>>Version based on timestamps?  If so, it seems that Version should be
>>>>explicitly called Timestamp.
>>>> 
>>>> Lan
>>> 
>>> there are cases one is preferred over the other depending on app needs.
>>> there are cases both are used: see RFC 3550 (RTP) as an example: it
>>>uses both timestamp and seq#
>>> the former can tell the time gaps between data
>>> the latter can tell whether any piece is missing
>> 
>> Yes, agree that timestamp and seq# can be both useful.  I was just
>>trying to point out that the Version concept is vague and I agree with
>>Jeff that there's a no clear distinction between version and sequence
>>number.  So instead of trying to define the semantic of version and
>>sequence, why not just use timestamp (which doesn't have to be
>>sequential) and seq# (which has to be sequential)?  The application can
>>use either one or both to differentiate between different pieces of data.
>> 
>> Lan
>
>We agree; I misunderstood your original msg.
>as far as I understand, the current definition of version value is
>timestamp.  
>Alex's original msg simply argues for a need to be able to distinctively
>mark seq# in addition to that (timestamp).
>If we mark timestamp as timestamp, then do we still need a "version"
>marker?
>
>Lixia
>_______________________________________________
>Nfd-dev mailing list
>Nfd-dev at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From jburke at remap.UCLA.EDU  Sun Jul 20 07:59:34 2014
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sun, 20 Jul 2014 14:59:34 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <410C2C9F-97F7-42BA-A5A3-72A3B16047C2@cs.ucla.edu>
Message-ID: <CFF12754.15486E%jburke@remap.ucla.edu>


We do need versions that are not timestamps, I think. Not sure exactly why
yet, though.  


On 7/19/14, 6:30 AM, "Lixia Zhang" <lixia at CS.UCLA.EDU> wrote:

>
>On Jul 19, 2014, at 5:05 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
>wrote:
>
>> 
>> On Jul 16, 2014, at 12:35 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
>> 
>>> 
>>> On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
>>>wrote:
>>> 
>>>> Alex,
>>>> 
>>>> What is the difference between Version and Sequence number?  Is
>>>>Version based on timestamps?  If so, it seems that Version should be
>>>>explicitly called Timestamp.
>>>> 
>>>> Lan
>>> 
>>> there are cases one is preferred over the other depending on app needs.
>>> there are cases both are used: see RFC 3550 (RTP) as an example: it
>>>uses both timestamp and seq#
>>> the former can tell the time gaps between data
>>> the latter can tell whether any piece is missing
>> 
>> Yes, agree that timestamp and seq# can be both useful.  I was just
>>trying to point out that the Version concept is vague and I agree with
>>Jeff that there's a no clear distinction between version and sequence
>>number.  So instead of trying to define the semantic of version and
>>sequence, why not just use timestamp (which doesn't have to be
>>sequential) and seq# (which has to be sequential)?  The application can
>>use either one or both to differentiate between different pieces of data.
>> 
>> Lan
>
>We agree; I misunderstood your original msg.
>as far as I understand, the current definition of version value is
>timestamp.  
>Alex's original msg simply argues for a need to be able to distinctively
>mark seq# in addition to that (timestamp).
>If we mark timestamp as timestamp, then do we still need a "version"
>marker?
>
>Lixia
>_______________________________________________
>Nfd-dev mailing list
>Nfd-dev at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From jburke at remap.UCLA.EDU  Sun Jul 20 08:01:27 2014
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sun, 20 Jul 2014 15:01:27 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <CF617A8D-502B-4376-B6D3-0F3408A65DBD@memphis.edu>
Message-ID: <CFF122B9.15481D%jburke@remap.ucla.edu>


Hi,

As I mentioned before, I think this is a really useful conversation.

I'd suggest that conventions be captured and proposed in a spec document
rather than by email, so that there can be examples / motivations and a
little deeper discussion.  I think this is also a good way to share the
results of the dialogue.

For example, it may also be necessary (and interesting) to define a
convention for the FinalBlockId depending on whether something is a
sequence or a segment, if we indeed make that distinction. (As an aside, I
notice that the tlv 0.2 spec still shows "NumberComponent" as a potential
type for FinalBlockID.  From talking with Lixia, I thought that we have
decided that there will not be typed components in the architecture.  If
that is true, then all such references should be removed.  If not, this
should be discussed, too.)

Some thoughts below in addition to the ones sent earlier.


>>Hi Jeff and all,
>> 
>> We had a follow up discussion today about naming conventions and in
>>particular we got to one question about "sequence numbers".   The CCNx
>>naming convention that we going to revert for now defines markers for
>>segments (sequential and non-sequential) and marker for version.  What
>>this convention is missing is the marker for sequential sequence numbers
>>for "infinite" collection.  Examples of this could be stream of
>>generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>(?).  In the past, we kind of used "segment" convention to represent
>>such numbers, but during our discussion we agreed that there is
>>different semantics for "segments" and "sequence numbers" and it is
>>useful to explicitly distinguish between them:
>> 
>> - "Segment" is a Data packet that is a part of a bigger data blob
>>(e.g., segments of one frame).  If third party (repo, cache, library?)
>>understands this semantics, than it can try request all the segments and
>>stop when finished.

Yes, this makes sense to me.  And then FinalBlockID indicates the end
segment if known?  

>> 
>> - "Sequence number" (for "infinite" collections) denotes that the
>>particular Data object is part of the collection, but is independent
>>piece of this collection (individual frame).   It is also possible that
>>such a piece can be further segmented.   If third parties understand
>>this semantics, they can perform very different actions compared to
>>segments.  

So is the idea that individual segments are not useful, but sequence
elements are?  Or that segments *could* be useful on their own, but the
application does not declare them that way?

Another useful thing here would be whether ordering matters - sequence
implies ordering, perhaps we need a notion of an unordered collection?
Would be nice to perhaps sketch out a paper with these conventions and
elaborate on them and potential use cases.

>> 
>> 
>> The proposal at hand is that we not just define markers for "segment"
>>(%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>notion of sequence numbers (say, %FE for now).
>> 
>> This definition doesn't imply we need to do any immediate change in any
>>of the application we have.  It is just for the future
>>applications/updates we use a more semantically correct ways to mark out
>>sequence numbers.


How is "semantically correct" defined?  Maybe we need use cases to be
discussed? 


Thanks,
Jeff


>>This will also prepare libraries for any convention change later.  The
>>place where we plan to use it right away is in NFD notification stream
>>protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>> 
>> Can you give opinions about this proposal?
>> 
>> ---
>> Alex
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>




From alexander.afanasyev at ucla.edu  Sun Jul 20 18:46:05 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sun, 20 Jul 2014 18:46:05 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <CFF122B9.15481D%jburke@remap.ucla.edu>
References: <CFF122B9.15481D%jburke@remap.ucla.edu>
Message-ID: <BDA0CA9B-C2FE-41FB-B415-4D9E58763CD4@ucla.edu>

Please check the first draft for the naming conventions memo (http://redmine.named-data.net/attachments/download/100/convention.pdf  or  git at git.irl.cs.ucla.edu:papers/ndn-memos-naming-conventions.git)

The primary intention for the document is to just define the encoding format and several (4 to be exact) markers.  In future we may include more discussions, motivations, and examples.

---
Alex

On Jul 20, 2014, at 8:01 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> 
> Hi,
> 
> As I mentioned before, I think this is a really useful conversation.
> 
> I'd suggest that conventions be captured and proposed in a spec document
> rather than by email, so that there can be examples / motivations and a
> little deeper discussion.  I think this is also a good way to share the
> results of the dialogue.
> 
> For example, it may also be necessary (and interesting) to define a
> convention for the FinalBlockId depending on whether something is a
> sequence or a segment, if we indeed make that distinction. (As an aside, I
> notice that the tlv 0.2 spec still shows "NumberComponent" as a potential
> type for FinalBlockID.  From talking with Lixia, I thought that we have
> decided that there will not be typed components in the architecture.  If
> that is true, then all such references should be removed.  If not, this
> should be discussed, too.)
> 
> Some thoughts below in addition to the ones sent earlier.
> 
> 
>>> Hi Jeff and all,
>>> 
>>> We had a follow up discussion today about naming conventions and in
>>> particular we got to one question about "sequence numbers".   The CCNx
>>> naming convention that we going to revert for now defines markers for
>>> segments (sequential and non-sequential) and marker for version.  What
>>> this convention is missing is the marker for sequential sequence numbers
>>> for "infinite" collection.  Examples of this could be stream of
>>> generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>> (?).  In the past, we kind of used "segment" convention to represent
>>> such numbers, but during our discussion we agreed that there is
>>> different semantics for "segments" and "sequence numbers" and it is
>>> useful to explicitly distinguish between them:
>>> 
>>> - "Segment" is a Data packet that is a part of a bigger data blob
>>> (e.g., segments of one frame).  If third party (repo, cache, library?)
>>> understands this semantics, than it can try request all the segments and
>>> stop when finished.
> 
> Yes, this makes sense to me.  And then FinalBlockID indicates the end
> segment if known?  
> 
>>> 
>>> - "Sequence number" (for "infinite" collections) denotes that the
>>> particular Data object is part of the collection, but is independent
>>> piece of this collection (individual frame).   It is also possible that
>>> such a piece can be further segmented.   If third parties understand
>>> this semantics, they can perform very different actions compared to
>>> segments.  
> 
> So is the idea that individual segments are not useful, but sequence
> elements are?  Or that segments *could* be useful on their own, but the
> application does not declare them that way?
> 
> Another useful thing here would be whether ordering matters - sequence
> implies ordering, perhaps we need a notion of an unordered collection?
> Would be nice to perhaps sketch out a paper with these conventions and
> elaborate on them and potential use cases.
> 
>>> 
>>> 
>>> The proposal at hand is that we not just define markers for "segment"
>>> (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>> notion of sequence numbers (say, %FE for now).
>>> 
>>> This definition doesn't imply we need to do any immediate change in any
>>> of the application we have.  It is just for the future
>>> applications/updates we use a more semantically correct ways to mark out
>>> sequence numbers.
> 
> 
> How is "semantically correct" defined?  Maybe we need use cases to be
> discussed? 
> 
> 
> Thanks,
> Jeff
> 
> 
>>> This will also prepare libraries for any convention change later.  The
>>> place where we plan to use it right away is in NFD notification stream
>>> protocol (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>> 
>>> Can you give opinions about this proposal?
>>> 
>>> ---
>>> Alex
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> 




From jburke at remap.ucla.edu  Sun Jul 20 22:37:05 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Mon, 21 Jul 2014 05:37:05 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <BDA0CA9B-C2FE-41FB-B415-4D9E58763CD4@ucla.edu>
Message-ID: <CFF1F40D.1549E6%jburke@remap.ucla.edu>


Thanks.  Could you clarify the semantics of the proposed conventions a bit
further? For example:

	
		
		
	
	
		
			
				
"Segmenting is used when the application wants to cut a large data into
small pieces"

=> Are the individual segments not really usable on their own, or is this
irrelevant to the convention?


"Versioning is necessary if the application wants to update previously
published data and publish again under the same name."

=> Would our current use of versions as frame timestamps make sense?  If
so, there may be a way to phrase this more inclusively than just talked
about updating previously published data... If not, perhaps we do want a
timestamp convention...

=> What about non-time-based versioning?

"While the sequence number value in these collections is syntactically
similar to sequence-based segmentation, the sequence number has a very
different meaning."

=> What is that meaning?  (This is the one I'm least clear on.  There is
an implicit definition of sequence but it's probably best to make it
explicit... monotonically increasing non-negative integer?)


As I mentioned in a previous email, perhaps the specific role of
FinalBlockID in each case should be explained?


Jeff

				
			
		
	



				
			
		
	






On 7/20/14, 6:46 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:

>Please check the first draft for the naming conventions memo
>(http://redmine.named-data.net/attachments/download/100/convention.pdf
>or  git at git.irl.cs.ucla.edu:papers/ndn-memos-naming-conventions.git)
>
>The primary intention for the document is to just define the encoding
>format and several (4 to be exact) markers.  In future we may include
>more discussions, motivations, and examples.
>
>---
>Alex
>
>On Jul 20, 2014, at 8:01 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>
>> 
>> Hi,
>> 
>> As I mentioned before, I think this is a really useful conversation.
>> 
>> I'd suggest that conventions be captured and proposed in a spec document
>> rather than by email, so that there can be examples / motivations and a
>> little deeper discussion.  I think this is also a good way to share the
>> results of the dialogue.
>> 
>> For example, it may also be necessary (and interesting) to define a
>> convention for the FinalBlockId depending on whether something is a
>> sequence or a segment, if we indeed make that distinction. (As an
>>aside, I
>> notice that the tlv 0.2 spec still shows "NumberComponent" as a
>>potential
>> type for FinalBlockID.  From talking with Lixia, I thought that we have
>> decided that there will not be typed components in the architecture.  If
>> that is true, then all such references should be removed.  If not, this
>> should be discussed, too.)
>> 
>> Some thoughts below in addition to the ones sent earlier.
>> 
>> 
>>>> Hi Jeff and all,
>>>> 
>>>> We had a follow up discussion today about naming conventions and in
>>>> particular we got to one question about "sequence numbers".   The CCNx
>>>> naming convention that we going to revert for now defines markers for
>>>> segments (sequential and non-sequential) and marker for version.  What
>>>> this convention is missing is the marker for sequential sequence
>>>>numbers
>>>> for "infinite" collection.  Examples of this could be stream of
>>>> generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>>> (?).  In the past, we kind of used "segment" convention to represent
>>>> such numbers, but during our discussion we agreed that there is
>>>> different semantics for "segments" and "sequence numbers" and it is
>>>> useful to explicitly distinguish between them:
>>>> 
>>>> - "Segment" is a Data packet that is a part of a bigger data blob
>>>> (e.g., segments of one frame).  If third party (repo, cache, library?)
>>>> understands this semantics, than it can try request all the segments
>>>>and
>>>> stop when finished.
>> 
>> Yes, this makes sense to me.  And then FinalBlockID indicates the end
>> segment if known?
>> 
>>>> 
>>>> - "Sequence number" (for "infinite" collections) denotes that the
>>>> particular Data object is part of the collection, but is independent
>>>> piece of this collection (individual frame).   It is also possible
>>>>that
>>>> such a piece can be further segmented.   If third parties understand
>>>> this semantics, they can perform very different actions compared to
>>>> segments.  
>> 
>> So is the idea that individual segments are not useful, but sequence
>> elements are?  Or that segments *could* be useful on their own, but the
>> application does not declare them that way?
>> 
>> Another useful thing here would be whether ordering matters - sequence
>> implies ordering, perhaps we need a notion of an unordered collection?
>> Would be nice to perhaps sketch out a paper with these conventions and
>> elaborate on them and potential use cases.
>> 
>>>> 
>>>> 
>>>> The proposal at hand is that we not just define markers for "segment"
>>>> (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>>> notion of sequence numbers (say, %FE for now).
>>>> 
>>>> This definition doesn't imply we need to do any immediate change in
>>>>any
>>>> of the application we have.  It is just for the future
>>>> applications/updates we use a more semantically correct ways to mark
>>>>out
>>>> sequence numbers.
>> 
>> 
>> How is "semantically correct" defined?  Maybe we need use cases to be
>> discussed? 
>> 
>> 
>> Thanks,
>> Jeff
>> 
>> 
>>>> This will also prepare libraries for any convention change later.  The
>>>> place where we plan to use it right away is in NFD notification stream
>>>> protocol 
>>>>(http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>>> 
>>>> Can you give opinions about this proposal?
>>>> 
>>>> ---
>>>> Alex
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Nfd-dev mailing list
>>>> Nfd-dev at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> 
>> 
>




From alexander.afanasyev at ucla.edu  Mon Jul 21 19:10:10 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 21 Jul 2014 19:10:10 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <CFF1F40D.1549E6%jburke@remap.ucla.edu>
References: <CFF1F40D.1549E6%jburke@remap.ucla.edu>
Message-ID: <8645B4F3-8D29-49D0-B0FD-657B9A9950AE@ucla.edu>

Please take a look at the updated memo: http://redmine.named-data.net/attachments/download/102/convention.pdf

I tried to address these and some other questions that we have discussed during NFD call today.

As for FinalBlockId I don't see how it is relevant to the naming conventions document.  For me, it is directly related to segmentation (and may be other) protocol(s), which deserve its(their) own memo(s).   In the naming convention we just defined how to represent segmenting, but not how the whole protocol works.  Also, as we discussed long ago, FinalBlockId is not the only (not the best either) way to implement segmentation...

---
Alex


On Jul 20, 2014, at 10:37 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> 
> Thanks.  Could you clarify the semantics of the proposed conventions a bit
> further? For example:
> 
> 				
> "Segmenting is used when the application wants to cut a large data into
> small pieces"
> 
> => Are the individual segments not really usable on their own, or is this
> irrelevant to the convention?
> 
> 
> "Versioning is necessary if the application wants to update previously
> published data and publish again under the same name."
> 
> => Would our current use of versions as frame timestamps make sense?  If
> so, there may be a way to phrase this more inclusively than just talked
> about updating previously published data... If not, perhaps we do want a
> timestamp convention...
> 
> => What about non-time-based versioning?
> 
> "While the sequence number value in these collections is syntactically
> similar to sequence-based segmentation, the sequence number has a very
> different meaning."
> 
> => What is that meaning?  (This is the one I'm least clear on.  There is
> an implicit definition of sequence but it's probably best to make it
> explicit... monotonically increasing non-negative integer?)
> 
> 
> As I mentioned in a previous email, perhaps the specific role of
> FinalBlockID in each case should be explained?
> 
> 
> Jeff
> 
> On 7/20/14, 6:46 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
> 
>> Please check the first draft for the naming conventions memo
>> (http://redmine.named-data.net/attachments/download/100/convention.pdf
>> or  git at git.irl.cs.ucla.edu:papers/ndn-memos-naming-conventions.git)
>> 
>> The primary intention for the document is to just define the encoding
>> format and several (4 to be exact) markers.  In future we may include
>> more discussions, motivations, and examples.
>> 
>> ---
>> Alex
>> 
>> On Jul 20, 2014, at 8:01 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>> 
>>> 
>>> Hi,
>>> 
>>> As I mentioned before, I think this is a really useful conversation.
>>> 
>>> I'd suggest that conventions be captured and proposed in a spec document
>>> rather than by email, so that there can be examples / motivations and a
>>> little deeper discussion.  I think this is also a good way to share the
>>> results of the dialogue.
>>> 
>>> For example, it may also be necessary (and interesting) to define a
>>> convention for the FinalBlockId depending on whether something is a
>>> sequence or a segment, if we indeed make that distinction. (As an
>>> aside, I
>>> notice that the tlv 0.2 spec still shows "NumberComponent" as a
>>> potential
>>> type for FinalBlockID.  From talking with Lixia, I thought that we have
>>> decided that there will not be typed components in the architecture.  If
>>> that is true, then all such references should be removed.  If not, this
>>> should be discussed, too.)
>>> 
>>> Some thoughts below in addition to the ones sent earlier.
>>> 
>>> 
>>>>> Hi Jeff and all,
>>>>> 
>>>>> We had a follow up discussion today about naming conventions and in
>>>>> particular we got to one question about "sequence numbers".   The CCNx
>>>>> naming convention that we going to revert for now defines markers for
>>>>> segments (sequential and non-sequential) and marker for version.  What
>>>>> this convention is missing is the marker for sequential sequence
>>>>> numbers
>>>>> for "infinite" collection.  Examples of this could be stream of
>>>>> generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>>>> (?).  In the past, we kind of used "segment" convention to represent
>>>>> such numbers, but during our discussion we agreed that there is
>>>>> different semantics for "segments" and "sequence numbers" and it is
>>>>> useful to explicitly distinguish between them:
>>>>> 
>>>>> - "Segment" is a Data packet that is a part of a bigger data blob
>>>>> (e.g., segments of one frame).  If third party (repo, cache, library?)
>>>>> understands this semantics, than it can try request all the segments
>>>>> and
>>>>> stop when finished.
>>> 
>>> Yes, this makes sense to me.  And then FinalBlockID indicates the end
>>> segment if known?
>>> 
>>>>> 
>>>>> - "Sequence number" (for "infinite" collections) denotes that the
>>>>> particular Data object is part of the collection, but is independent
>>>>> piece of this collection (individual frame).   It is also possible
>>>>> that
>>>>> such a piece can be further segmented.   If third parties understand
>>>>> this semantics, they can perform very different actions compared to
>>>>> segments.  
>>> 
>>> So is the idea that individual segments are not useful, but sequence
>>> elements are?  Or that segments *could* be useful on their own, but the
>>> application does not declare them that way?
>>> 
>>> Another useful thing here would be whether ordering matters - sequence
>>> implies ordering, perhaps we need a notion of an unordered collection?
>>> Would be nice to perhaps sketch out a paper with these conventions and
>>> elaborate on them and potential use cases.
>>> 
>>>>> 
>>>>> 
>>>>> The proposal at hand is that we not just define markers for "segment"
>>>>> (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>>>> notion of sequence numbers (say, %FE for now).
>>>>> 
>>>>> This definition doesn't imply we need to do any immediate change in
>>>>> any
>>>>> of the application we have.  It is just for the future
>>>>> applications/updates we use a more semantically correct ways to mark
>>>>> out
>>>>> sequence numbers.
>>> 
>>> 
>>> How is "semantically correct" defined?  Maybe we need use cases to be
>>> discussed? 
>>> 
>>> 
>>> Thanks,
>>> Jeff
>>> 
>>> 
>>>>> This will also prepare libraries for any convention change later.  The
>>>>> place where we plan to use it right away is in NFD notification stream
>>>>> protocol 
>>>>> (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>>>> 
>>>>> Can you give opinions about this proposal?
>>>>> 
>>>>> ---
>>>>> Alex
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Nfd-dev mailing list
>>>>> Nfd-dev at lists.cs.ucla.edu
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>> 
>>> 
>> 
> 




From shijunxiao at email.arizona.edu  Tue Jul 22 01:10:02 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 22 Jul 2014 16:10:02 +0800
Subject: [Nfd-dev] size_t vs std::size_t
In-Reply-To: <CAOFH+OZ52K7A5z_1jdGyPvs4LyRCgNMFBG+yrQVUZtV=qiWm2w@mail.gmail.com>
References: <CAOFH+OZ52K7A5z_1jdGyPvs4LyRCgNMFBG+yrQVUZtV=qiWm2w@mail.gmail.com>
Message-ID: <CAOFH+Oap=P84qrJfKJ4nhpid40L8F8nn7uXCRGu_QNs1pskmnQ@mail.gmail.com>

Dear folks

A question is raised in code review regarding whether we should use size_t
or std::size_t in our code.

According to answers in <
http://stackoverflow.com/questions/5813700/difference-between-size-t-and-stdsize-t
>:

* std::size_t is in C++ standard, defined in <cstddef> header
* size_t is from C standard, defined in <stddef.h> header
* C++ standard requires, if an implementation defines size_t, it must be
same as std::size_t
* all major compilers define both size_t and std::size_t in <cstddef>
* our code includes <cstddef>

Therefore, there is no functional difference between these two types.

My opinion is: we should use size_t because it's more concise.
To fully support C++ standard, we should also add "using std::size_t"
statement in common.hpp.

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140722/dc0fb46b/attachment.html>

From davide.pesavento at lip6.fr  Tue Jul 22 10:16:09 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 22 Jul 2014 19:16:09 +0200
Subject: [Nfd-dev] size_t vs std::size_t
In-Reply-To: <CAOFH+Oap=P84qrJfKJ4nhpid40L8F8nn7uXCRGu_QNs1pskmnQ@mail.gmail.com>
References: <CAOFH+OZ52K7A5z_1jdGyPvs4LyRCgNMFBG+yrQVUZtV=qiWm2w@mail.gmail.com>
	<CAOFH+Oap=P84qrJfKJ4nhpid40L8F8nn7uXCRGu_QNs1pskmnQ@mail.gmail.com>
Message-ID: <CADfzvvZnOjQXW4EWmu2RZhw6Ybb6drvN5nBGhE85-o=+8OcEpA@mail.gmail.com>

On Tue, Jul 22, 2014 at 10:10 AM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Dear folks
>
> A question is raised in code review regarding whether we should use size_t
> or std::size_t in our code.
>
> According to answers in
> <http://stackoverflow.com/questions/5813700/difference-between-size-t-and-stdsize-t>:
>
> * std::size_t is in C++ standard, defined in <cstddef> header
> * size_t is from C standard, defined in <stddef.h> header
> * C++ standard requires, if an implementation defines size_t, it must be
> same as std::size_t
> * all major compilers define both size_t and std::size_t in <cstddef>
> * our code includes <cstddef>

Where? I see only <stddef.h> in ndn-cxx's common.hpp (which is
included by NFD's common.hpp). Should we switch to the C++ variant?

>
> Therefore, there is no functional difference between these two types.
>
> My opinion is: we should use size_t because it's more concise.

+1

> To fully support C++ standard, we should also add "using std::size_t"
> statement in common.hpp.

Yes, but only if we change ndn-cxx to include <cstddef> rather than <stddef.h>.

Thanks,
Davide


From alexander.afanasyev at UCLA.EDU  Tue Jul 22 10:33:09 2014
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Tue, 22 Jul 2014 10:33:09 -0700
Subject: [Nfd-dev] size_t vs std::size_t
In-Reply-To: <CADfzvvZnOjQXW4EWmu2RZhw6Ybb6drvN5nBGhE85-o=+8OcEpA@mail.gmail.com>
References: <CAOFH+OZ52K7A5z_1jdGyPvs4LyRCgNMFBG+yrQVUZtV=qiWm2w@mail.gmail.com>
	<CAOFH+Oap=P84qrJfKJ4nhpid40L8F8nn7uXCRGu_QNs1pskmnQ@mail.gmail.com>
	<CADfzvvZnOjQXW4EWmu2RZhw6Ybb6drvN5nBGhE85-o=+8OcEpA@mail.gmail.com>
Message-ID: <612E60E4-179E-47AE-AA71-3E6E127A622A@ucla.edu>

I have no objections of using size_t in most cases.  The place from which this question arises is boost::asio.  Boost.Asio documentation specify "WriteHandle" to use std::size_t, so I don't see a big contradiction of using std::size_t in boost-asio related things, while using size_t for other places.

---
Alex

On Jul 22, 2014, at 10:16 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> On Tue, Jul 22, 2014 at 10:10 AM, Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>> Dear folks
>> 
>> A question is raised in code review regarding whether we should use size_t
>> or std::size_t in our code.
>> 
>> According to answers in
>> <http://stackoverflow.com/questions/5813700/difference-between-size-t-and-stdsize-t>:
>> 
>> * std::size_t is in C++ standard, defined in <cstddef> header
>> * size_t is from C standard, defined in <stddef.h> header
>> * C++ standard requires, if an implementation defines size_t, it must be
>> same as std::size_t
>> * all major compilers define both size_t and std::size_t in <cstddef>
>> * our code includes <cstddef>
> 
> Where? I see only <stddef.h> in ndn-cxx's common.hpp (which is
> included by NFD's common.hpp). Should we switch to the C++ variant?
> 
>> 
>> Therefore, there is no functional difference between these two types.
>> 
>> My opinion is: we should use size_t because it's more concise.
> 
> +1
> 
>> To fully support C++ standard, we should also add "using std::size_t"
>> statement in common.hpp.
> 
> Yes, but only if we change ndn-cxx to include <cstddef> rather than <stddef.h>.
> 
> Thanks,
> Davide



From alexander.afanasyev at ucla.edu  Wed Jul 23 17:32:03 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 23 Jul 2014 17:32:03 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <8645B4F3-8D29-49D0-B0FD-657B9A9950AE@ucla.edu>
References: <CFF1F40D.1549E6%jburke@remap.ucla.edu>
	<8645B4F3-8D29-49D0-B0FD-657B9A9950AE@ucla.edu>
Message-ID: <01E77C53-28AC-42F7-AA7B-DFCC2C713CC7@ucla.edu>

Hi guys,

We need to have an approval for the naming convention spec before we can proceed with changes to the libraries.  Given the testbed deployment is scheduled this Friday, the spec (at least on conceptual level, we can correct wordings later) needs to be approved before that

Just in case, link to the latest version: http://redmine.named-data.net/attachments/download/102/convention.pdf

---
Alex

On Jul 21, 2014, at 7:10 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> Please take a look at the updated memo: http://redmine.named-data.net/attachments/download/102/convention.pdf
> 
> I tried to address these and some other questions that we have discussed during NFD call today.
> 
> As for FinalBlockId I don't see how it is relevant to the naming conventions document.  For me, it is directly related to segmentation (and may be other) protocol(s), which deserve its(their) own memo(s).   In the naming convention we just defined how to represent segmenting, but not how the whole protocol works.  Also, as we discussed long ago, FinalBlockId is not the only (not the best either) way to implement segmentation...
> 
> ---
> Alex
> 
> 
> On Jul 20, 2014, at 10:37 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> 
>> 
>> Thanks.  Could you clarify the semantics of the proposed conventions a bit
>> further? For example:
>> 
>> 				
>> "Segmenting is used when the application wants to cut a large data into
>> small pieces"
>> 
>> => Are the individual segments not really usable on their own, or is this
>> irrelevant to the convention?
>> 
>> 
>> "Versioning is necessary if the application wants to update previously
>> published data and publish again under the same name."
>> 
>> => Would our current use of versions as frame timestamps make sense?  If
>> so, there may be a way to phrase this more inclusively than just talked
>> about updating previously published data... If not, perhaps we do want a
>> timestamp convention...
>> 
>> => What about non-time-based versioning?
>> 
>> "While the sequence number value in these collections is syntactically
>> similar to sequence-based segmentation, the sequence number has a very
>> different meaning."
>> 
>> => What is that meaning?  (This is the one I'm least clear on.  There is
>> an implicit definition of sequence but it's probably best to make it
>> explicit... monotonically increasing non-negative integer?)
>> 
>> 
>> As I mentioned in a previous email, perhaps the specific role of
>> FinalBlockID in each case should be explained?
>> 
>> 
>> Jeff
>> 
>> On 7/20/14, 6:46 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:
>> 
>>> Please check the first draft for the naming conventions memo
>>> (http://redmine.named-data.net/attachments/download/100/convention.pdf
>>> or  git at git.irl.cs.ucla.edu:papers/ndn-memos-naming-conventions.git)
>>> 
>>> The primary intention for the document is to just define the encoding
>>> format and several (4 to be exact) markers.  In future we may include
>>> more discussions, motivations, and examples.
>>> 
>>> ---
>>> Alex
>>> 
>>> On Jul 20, 2014, at 8:01 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> As I mentioned before, I think this is a really useful conversation.
>>>> 
>>>> I'd suggest that conventions be captured and proposed in a spec document
>>>> rather than by email, so that there can be examples / motivations and a
>>>> little deeper discussion.  I think this is also a good way to share the
>>>> results of the dialogue.
>>>> 
>>>> For example, it may also be necessary (and interesting) to define a
>>>> convention for the FinalBlockId depending on whether something is a
>>>> sequence or a segment, if we indeed make that distinction. (As an
>>>> aside, I
>>>> notice that the tlv 0.2 spec still shows "NumberComponent" as a
>>>> potential
>>>> type for FinalBlockID.  From talking with Lixia, I thought that we have
>>>> decided that there will not be typed components in the architecture.  If
>>>> that is true, then all such references should be removed.  If not, this
>>>> should be discussed, too.)
>>>> 
>>>> Some thoughts below in addition to the ones sent earlier.
>>>> 
>>>> 
>>>>>> Hi Jeff and all,
>>>>>> 
>>>>>> We had a follow up discussion today about naming conventions and in
>>>>>> particular we got to one question about "sequence numbers".   The CCNx
>>>>>> naming convention that we going to revert for now defines markers for
>>>>>> segments (sequential and non-sequential) and marker for version.  What
>>>>>> this convention is missing is the marker for sequential sequence
>>>>>> numbers
>>>>>> for "infinite" collection.  Examples of this could be stream of
>>>>>> generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>>>>> (?).  In the past, we kind of used "segment" convention to represent
>>>>>> such numbers, but during our discussion we agreed that there is
>>>>>> different semantics for "segments" and "sequence numbers" and it is
>>>>>> useful to explicitly distinguish between them:
>>>>>> 
>>>>>> - "Segment" is a Data packet that is a part of a bigger data blob
>>>>>> (e.g., segments of one frame).  If third party (repo, cache, library?)
>>>>>> understands this semantics, than it can try request all the segments
>>>>>> and
>>>>>> stop when finished.
>>>> 
>>>> Yes, this makes sense to me.  And then FinalBlockID indicates the end
>>>> segment if known?
>>>> 
>>>>>> 
>>>>>> - "Sequence number" (for "infinite" collections) denotes that the
>>>>>> particular Data object is part of the collection, but is independent
>>>>>> piece of this collection (individual frame).   It is also possible
>>>>>> that
>>>>>> such a piece can be further segmented.   If third parties understand
>>>>>> this semantics, they can perform very different actions compared to
>>>>>> segments.  
>>>> 
>>>> So is the idea that individual segments are not useful, but sequence
>>>> elements are?  Or that segments *could* be useful on their own, but the
>>>> application does not declare them that way?
>>>> 
>>>> Another useful thing here would be whether ordering matters - sequence
>>>> implies ordering, perhaps we need a notion of an unordered collection?
>>>> Would be nice to perhaps sketch out a paper with these conventions and
>>>> elaborate on them and potential use cases.
>>>> 
>>>>>> 
>>>>>> 
>>>>>> The proposal at hand is that we not just define markers for "segment"
>>>>>> (%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>>>>> notion of sequence numbers (say, %FE for now).
>>>>>> 
>>>>>> This definition doesn't imply we need to do any immediate change in
>>>>>> any
>>>>>> of the application we have.  It is just for the future
>>>>>> applications/updates we use a more semantically correct ways to mark
>>>>>> out
>>>>>> sequence numbers.
>>>> 
>>>> 
>>>> How is "semantically correct" defined?  Maybe we need use cases to be
>>>> discussed? 
>>>> 
>>>> 
>>>> Thanks,
>>>> Jeff
>>>> 
>>>> 
>>>>>> This will also prepare libraries for any convention change later.  The
>>>>>> place where we plan to use it right away is in NFD notification stream
>>>>>> protocol 
>>>>>> (http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>>>>> 
>>>>>> Can you give opinions about this proposal?
>>>>>> 
>>>>>> ---
>>>>>> Alex
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Nfd-dev mailing list
>>>>>> Nfd-dev at lists.cs.ucla.edu
>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>> 
>>>> 
>>> 
>> 
> 




From shijunxiao at email.arizona.edu  Thu Jul 24 03:56:16 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 24 Jul 2014 03:56:16 -0700
Subject: [Nfd-dev] size_t vs std::size_t
In-Reply-To: <612E60E4-179E-47AE-AA71-3E6E127A622A@ucla.edu>
References: <CAOFH+OZ52K7A5z_1jdGyPvs4LyRCgNMFBG+yrQVUZtV=qiWm2w@mail.gmail.com>
	<CAOFH+Oap=P84qrJfKJ4nhpid40L8F8nn7uXCRGu_QNs1pskmnQ@mail.gmail.com>
	<CADfzvvZnOjQXW4EWmu2RZhw6Ybb6drvN5nBGhE85-o=+8OcEpA@mail.gmail.com>
	<612E60E4-179E-47AE-AA71-3E6E127A622A@ucla.edu>
Message-ID: <CAOFH+Ob4nCJ==4_e4YdrDSq4RYs9gfqZ4EbNYT6HE1mSL96Bvg@mail.gmail.com>

Dear folks

Since both are the same type, we should use a consistent name for it,
regardless of whether a function is a callback of Boost.Asio (which is not
obvious).

Therefore, the proposal is:

* in common.hpp, include cstddef
* in common.hpp, using std::size_t
* write size_t everywhere

Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140724/5bcba04e/attachment.html>

From davide.pesavento at lip6.fr  Thu Jul 24 10:06:40 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Thu, 24 Jul 2014 19:06:40 +0200
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <01E77C53-28AC-42F7-AA7B-DFCC2C713CC7@ucla.edu>
References: <CFF1F40D.1549E6%jburke@remap.ucla.edu>
	<8645B4F3-8D29-49D0-B0FD-657B9A9950AE@ucla.edu>
	<01E77C53-28AC-42F7-AA7B-DFCC2C713CC7@ucla.edu>
Message-ID: <CADfzvvZJde09ptRU6PSbz9rshRkAP0OPk4SsSe5QduDb0re1Vw@mail.gmail.com>

Hi Alex and all,

Some comments from me and Giulio.

Segmentation: looks good to us.

Versioning: must the version really correspond to the number of
millisecs since epoch? I can see a couple of problems with this:
    1/ millisecs granularity may not be enough for the application
    2/ if accurate clock synchronization is indeed a problem, using
timestamps is pointless, but on the other hand there's no defined
marker for non-time-based versioning, so what do we do?

Maybe the value for the version marker should be defined more broadly
as a monotonically increasing nonnegative integer (but not necessarily
sequential), leaving the door open to more use cases. On the other
hand, one could argue that this new definition isn't much different
from a sequence number (it only lacks the sequentiality property),
therefore maybe we could merge versioning into sequencing. If needed,
applications can still use timestamps in name components, but those
components simply won't be marked in any special way.

Conversely, if the majority prefers keeping the proposed timestamp
semantics, can we at least call it "timestamping" instead of
versioning?

Thanks,
Davide

On Thu, Jul 24, 2014 at 2:32 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
> Hi guys,
>
> We need to have an approval for the naming convention spec before we can proceed with changes to the libraries.  Given the testbed deployment is scheduled this Friday, the spec (at least on conceptual level, we can correct wordings later) needs to be approved before that
>
> Just in case, link to the latest version: http://redmine.named-data.net/attachments/download/102/convention.pdf
>
> ---
> Alex
>



From davide.pesavento at lip6.fr  Thu Jul 24 10:12:46 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Thu, 24 Jul 2014 19:12:46 +0200
Subject: [Nfd-dev] size_t vs std::size_t
In-Reply-To: <CAOFH+Ob4nCJ==4_e4YdrDSq4RYs9gfqZ4EbNYT6HE1mSL96Bvg@mail.gmail.com>
References: <CAOFH+OZ52K7A5z_1jdGyPvs4LyRCgNMFBG+yrQVUZtV=qiWm2w@mail.gmail.com>
	<CAOFH+Oap=P84qrJfKJ4nhpid40L8F8nn7uXCRGu_QNs1pskmnQ@mail.gmail.com>
	<CADfzvvZnOjQXW4EWmu2RZhw6Ybb6drvN5nBGhE85-o=+8OcEpA@mail.gmail.com>
	<612E60E4-179E-47AE-AA71-3E6E127A622A@ucla.edu>
	<CAOFH+Ob4nCJ==4_e4YdrDSq4RYs9gfqZ4EbNYT6HE1mSL96Bvg@mail.gmail.com>
Message-ID: <CADfzvvaPmnbsVpuiQLbiWGUPiXJPOzyQUKSfUp27R41PhpJjHQ@mail.gmail.com>

Hi Junxiao,

On Thu, Jul 24, 2014 at 12:56 PM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Dear folks
>
> Since both are the same type, we should use a consistent name for it,
> regardless of whether a function is a callback of Boost.Asio (which is not
> obvious).

I agree completely.

>
> Therefore, the proposal is:
>
> * in common.hpp, include cstddef
> * in common.hpp, using std::size_t
> * write size_t everywhere

+1

Thanks,
Davide


From alexander.afanasyev at ucla.edu  Thu Jul 24 15:26:52 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 24 Jul 2014 15:26:52 -0700
Subject: [Nfd-dev] size_t vs std::size_t
In-Reply-To: <CADfzvvaPmnbsVpuiQLbiWGUPiXJPOzyQUKSfUp27R41PhpJjHQ@mail.gmail.com>
References: <CAOFH+OZ52K7A5z_1jdGyPvs4LyRCgNMFBG+yrQVUZtV=qiWm2w@mail.gmail.com>
	<CAOFH+Oap=P84qrJfKJ4nhpid40L8F8nn7uXCRGu_QNs1pskmnQ@mail.gmail.com>
	<CADfzvvZnOjQXW4EWmu2RZhw6Ybb6drvN5nBGhE85-o=+8OcEpA@mail.gmail.com>
	<612E60E4-179E-47AE-AA71-3E6E127A622A@ucla.edu>
	<CAOFH+Ob4nCJ==4_e4YdrDSq4RYs9gfqZ4EbNYT6HE1mSL96Bvg@mail.gmail.com>
	<CADfzvvaPmnbsVpuiQLbiWGUPiXJPOzyQUKSfUp27R41PhpJjHQ@mail.gmail.com>
Message-ID: <4D1D27D9-6133-4874-BFCC-B22191EC7B78@ucla.edu>

If you insist on that, I would not object.  I just don't see much value of having such a "consistency" if it doesn't matter in the first place.

---
Alex

On Jul 24, 2014, at 10:12 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> Hi Junxiao,
> 
> On Thu, Jul 24, 2014 at 12:56 PM, Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>> Dear folks
>> 
>> Since both are the same type, we should use a consistent name for it,
>> regardless of whether a function is a callback of Boost.Asio (which is not
>> obvious).
> 
> I agree completely.
> 
>> 
>> Therefore, the proposal is:
>> 
>> * in common.hpp, include cstddef
>> * in common.hpp, using std::size_t
>> * write size_t everywhere
> 
> +1
> 
> Thanks,
> Davide




From alexander.afanasyev at ucla.edu  Thu Jul 24 15:38:25 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 24 Jul 2014 15:38:25 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <CADfzvvZJde09ptRU6PSbz9rshRkAP0OPk4SsSe5QduDb0re1Vw@mail.gmail.com>
References: <CFF1F40D.1549E6%jburke@remap.ucla.edu>
	<8645B4F3-8D29-49D0-B0FD-657B9A9950AE@ucla.edu>
	<01E77C53-28AC-42F7-AA7B-DFCC2C713CC7@ucla.edu>
	<CADfzvvZJde09ptRU6PSbz9rshRkAP0OPk4SsSe5QduDb0re1Vw@mail.gmail.com>
Message-ID: <24393D5B-8D52-4E33-965A-395811038AF1@ucla.edu>


On Jul 24, 2014, at 10:06 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> Hi Alex and all,
> 
> Some comments from me and Giulio.
> 
> Segmentation: looks good to us.
> 
> Versioning: must the version really correspond to the number of
> millisecs since epoch? I can see a couple of problems with this:
>    1/ millisecs granularity may not be enough for the application
>    2/ if accurate clock synchronization is indeed a problem, using
> timestamps is pointless, but on the other hand there's no defined
> marker for non-time-based versioning, so what do we do?
> 
> Maybe the value for the version marker should be defined more broadly
> as a monotonically increasing nonnegative integer (but not necessarily
> sequential), leaving the door open to more use cases. On the other
> hand, one could argue that this new definition isn't much different
> from a sequence number (it only lacks the sequentiality property),
> therefore maybe we could merge versioning into sequencing. If needed,
> applications can still use timestamps in name components, but those
> components simply won't be marked in any special way.

Hi Davide and Giulio. Thanks for the comments!

The reason I'm tempted to keep the current definition of versioning is a little bit to do with application inter-operability in mind.  If version is defined as increasing number, then there is no clear definition of how distributed production of data can be implemented.  If producers perform some way of version synchronization, then only these producers will be able to produce the "correct" version, while third-parties will be excluded and not able to produce never version of the data (this is kind of a vague argument, but I think there could be use cases for that).  Giving a flawed, but simple mechanism to generate "correct" time-based version is in this sense better.

As for dealing with applications that needs better granularity...  In some cases it is possible to cheat, ensuring that "version" is increased at least by one for the next generated data.  For other cases we definitely need to define some marker or some other way to give reasonable understanding for others about the component.

> Conversely, if the majority prefers keeping the proposed timestamp
> semantics, can we at least call it "timestamping" instead of
> versioning?

This what Lan was proposing before.  Completely replacing versioning with timestamping doesn't make sense for me.  Probably, we can have such a convention, though it should be used just for "timestamping" purposes, which not necessarily the same as versioning.  Also, if convention for timestamping is defined, we need to specify/exemplify how this could be used (e.g., by third-parties).

---
Alex


> Thanks,
> Davide
> 
> On Thu, Jul 24, 2014 at 2:32 AM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> Hi guys,
>> 
>> We need to have an approval for the naming convention spec before we can proceed with changes to the libraries.  Given the testbed deployment is scheduled this Friday, the spec (at least on conceptual level, we can correct wordings later) needs to be approved before that
>> 
>> Just in case, link to the latest version: http://redmine.named-data.net/attachments/download/102/convention.pdf
>> 
>> ---
>> Alex
>> 




From shijunxiao at email.arizona.edu  Thu Jul 24 16:08:42 2014
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 24 Jul 2014 16:08:42 -0700
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <24393D5B-8D52-4E33-965A-395811038AF1@ucla.edu>
References: <CFF1F40D.1549E6%jburke@remap.ucla.edu>
	<8645B4F3-8D29-49D0-B0FD-657B9A9950AE@ucla.edu>
	<01E77C53-28AC-42F7-AA7B-DFCC2C713CC7@ucla.edu>
	<CADfzvvZJde09ptRU6PSbz9rshRkAP0OPk4SsSe5QduDb0re1Vw@mail.gmail.com>
	<24393D5B-8D52-4E33-965A-395811038AF1@ucla.edu>
Message-ID: <CAOFH+OagcrKDp9fN3iv22dynBjX903KejF-9P6tj7TkiFm8Vqg@mail.gmail.com>

Dear folks

My opinion is:

The version number is a non-negative integer.
Applications SHOULD guarantee version numbers of the same collection is
monotonically increasing.
To satisfy this recommendation, applications MAY choose to generate version
numbers based on timestamps; when a version number is based on timestamp,
it SHOULD be the number of milliseconds since UNIX epoch.
Alternatively, applications MAY choose to generate version numbers from a
monotonically increasing sequence.
When multiple producers exist for the same collection, a producer SHOULD
NOT generate a version number that is less than or equal to the latest
version number to best of its knowledge.

Yours, Junxiao

On Thu, Jul 24, 2014 at 3:38 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

>
> On Jul 24, 2014, at 10:06 AM, Davide Pesavento <davide.pesavento at lip6.fr>
> wrote:
>
> > Hi Alex and all,
> >
> > Some comments from me and Giulio.
> >
> > Segmentation: looks good to us.
> >
> > Versioning: must the version really correspond to the number of
> > millisecs since epoch? I can see a couple of problems with this:
> >    1/ millisecs granularity may not be enough for the application
> >    2/ if accurate clock synchronization is indeed a problem, using
> > timestamps is pointless, but on the other hand there's no defined
> > marker for non-time-based versioning, so what do we do?
> >
> > Maybe the value for the version marker should be defined more broadly
> > as a monotonically increasing nonnegative integer (but not necessarily
> > sequential), leaving the door open to more use cases. On the other
> > hand, one could argue that this new definition isn't much different
> > from a sequence number (it only lacks the sequentiality property),
> > therefore maybe we could merge versioning into sequencing. If needed,
> > applications can still use timestamps in name components, but those
> > components simply won't be marked in any special way.
>
> Hi Davide and Giulio. Thanks for the comments!
>
> The reason I'm tempted to keep the current definition of versioning is a
> little bit to do with application inter-operability in mind.  If version is
> defined as increasing number, then there is no clear definition of how
> distributed production of data can be implemented.  If producers perform
> some way of version synchronization, then only these producers will be able
> to produce the "correct" version, while third-parties will be excluded and
> not able to produce never version of the data (this is kind of a vague
> argument, but I think there could be use cases for that).  Giving a flawed,
> but simple mechanism to generate "correct" time-based version is in this
> sense better.
>
> As for dealing with applications that needs better granularity...  In some
> cases it is possible to cheat, ensuring that "version" is increased at
> least by one for the next generated data.  For other cases we definitely
> need to define some marker or some other way to give reasonable
> understanding for others about the component.
>
> > Conversely, if the majority prefers keeping the proposed timestamp
> > semantics, can we at least call it "timestamping" instead of
> > versioning?
>
> This what Lan was proposing before.  Completely replacing versioning with
> timestamping doesn't make sense for me.  Probably, we can have such a
> convention, though it should be used just for "timestamping" purposes,
> which not necessarily the same as versioning.  Also, if convention for
> timestamping is defined, we need to specify/exemplify how this could be
> used (e.g., by third-parties).
>
> ---
> Alex
>
>
> > Thanks,
> > Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140724/9e1cf286/attachment.html>

From jburke at remap.ucla.edu  Fri Jul 25 11:24:08 2014
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Fri, 25 Jul 2014 18:24:08 +0000
Subject: [Nfd-dev] Naming conventions for "sequence number"
In-Reply-To: <24393D5B-8D52-4E33-965A-395811038AF1@ucla.edu>
Message-ID: <CFF7EE32.158777%jburke@remap.ucla.edu>



On 7/24/14, 3:38 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:

>
>On Jul 24, 2014, at 10:06 AM, Davide Pesavento <davide.pesavento at lip6.fr>
>wrote:
>
>> Hi Alex and all,
>> 
>> Some comments from me and Giulio.
>> 
>> Segmentation: looks good to us.
>> 
>> Versioning: must the version really correspond to the number of
>> millisecs since epoch? I can see a couple of problems with this:
>>    1/ millisecs granularity may not be enough for the application
>>    2/ if accurate clock synchronization is indeed a problem, using
>> timestamps is pointless, but on the other hand there's no defined
>> marker for non-time-based versioning, so what do we do?
>> 
>> Maybe the value for the version marker should be defined more broadly
>> as a monotonically increasing nonnegative integer (but not necessarily
>> sequential), leaving the door open to more use cases. On the other
>> hand, one could argue that this new definition isn't much different
>> from a sequence number (it only lacks the sequentiality property),
>> therefore maybe we could merge versioning into sequencing. If needed,
>> applications can still use timestamps in name components, but those
>> components simply won't be marked in any special way.
>
>Hi Davide and Giulio. Thanks for the comments!
>
>The reason I'm tempted to keep the current definition of versioning is a
>little bit to do with application inter-operability in mind.  If version
>is defined as increasing number, then there is no clear definition of how
>distributed production of data can be implemented.  If producers perform
>some way of version synchronization, then only these producers will be
>able to produce the "correct" version, while third-parties will be
>excluded and not able to produce never version of the data (this is kind
>of a vague argument, but I think there could be use cases for that).
>Giving a flawed, but simple mechanism to generate "correct" time-based
>version is in this sense better.

This argument makes sense to me but is there a way we can make this work
to some arbitrary level of precision, selected by the application, rather
than requiring milliseconds.

>
>As for dealing with applications that needs better granularity...  In
>some cases it is possible to cheat, ensuring that "version" is increased
>at least by one for the next generated data.

I think we want to avoid this cheat if possible.  Sometimes a millisecond
is relevant, depending on what's being versioned.

> For other cases we definitely need to define some marker or some other
>way to give reasonable understanding for others about the component.
>
>> Conversely, if the majority prefers keeping the proposed timestamp
>> semantics, can we at least call it "timestamping" instead of
>> versioning?
>
>This what Lan was proposing before.  Completely replacing versioning with
>timestamping doesn't make sense for me.  Probably, we can have such a
>convention, though it should be used just for "timestamping" purposes,
>which not necessarily the same as versioning.  Also, if convention for
>timestamping is defined, we need to specify/exemplify how this could be
>used (e.g., by third-parties).

I agree - maybe just a "if you're going to use timestamps for versions,
here's how..." sort of convention?

Jeff

>
>---
>Alex
>
>
>> Thanks,
>> Davide
>> 
>> On Thu, Jul 24, 2014 at 2:32 AM, Alex Afanasyev
>> <alexander.afanasyev at ucla.edu> wrote:
>>> Hi guys,
>>> 
>>> We need to have an approval for the naming convention spec before we
>>>can proceed with changes to the libraries.  Given the testbed
>>>deployment is scheduled this Friday, the spec (at least on conceptual
>>>level, we can correct wordings later) needs to be approved before that
>>> 
>>> Just in case, link to the latest version:
>>>http://redmine.named-data.net/attachments/download/102/convention.pdf
>>> 
>>> ---
>>> Alex
>>> 
>
>
>_______________________________________________
>Nfd-dev mailing list
>Nfd-dev at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From alexander.afanasyev at UCLA.EDU  Mon Jul 28 15:48:45 2014
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Mon, 28 Jul 2014 15:48:45 -0700
Subject: [Nfd-dev] Upcoming release candidate 2 for version 0.2.0
Message-ID: <45DDBFFA-FC8E-439A-B3F7-12AA423E67E4@ucla.edu>

Hi guys,

Just want to give you a heads up that we will make a release candidate 2 for the version 0.2.0.  

The original plan has changed a little bit and this release candidate (and the following release) will include features that have been already merged to master branch.

I'll send a quick announcement after merges and tagging is done.

---
Alex




From alexander.afanasyev at ucla.edu  Mon Jul 28 16:21:02 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 28 Jul 2014 16:21:02 -0700
Subject: [Nfd-dev] Naming conventions (draft 3)
Message-ID: <9809C679-E1BB-4A0A-9AF0-6D05C2A806FD@ucla.edu>

Hi guys,

I made an update of the naming convention spec based on the received feedback. The updated draft can be downloaded here: http://redmine.named-data.net/attachments/download/123/convention.pdf

- Version is redefined to be just a number (larger number represents later version and it is up to the app to define the specific use)
- New marker for Timestamp

Please comment as we need to have this document approved before we can finalize our release.

---
Alex


From davide.pesavento at lip6.fr  Mon Jul 28 17:13:47 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 29 Jul 2014 02:13:47 +0200
Subject: [Nfd-dev] Naming conventions (draft 3)
In-Reply-To: <9809C679-E1BB-4A0A-9AF0-6D05C2A806FD@ucla.edu>
References: <9809C679-E1BB-4A0A-9AF0-6D05C2A806FD@ucla.edu>
Message-ID: <CADfzvvau13LgcLcbUT=4E2oqNyoFvdU-SHvSUhpzSKqG9dCxBw@mail.gmail.com>

Hi Alex,

Thanks for the new draft.

*) 3.3 suggests using a timestamp as "a simple way to implement
versioning", which sounds odd to me, why not using the timestamp
marker 0xFC in such cases then?

*) In 3.4, the value for the timestamp is in milliseconds. Can we
change it to microseconds? Applications that don't need this
granularity can just append zeros as needed.

*) In 3.4, typo "cane" -> "can"

*) Why is sequencing a sub-section of timestamping?

Thanks,
Davide

On Tue, Jul 29, 2014 at 1:21 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
> Hi guys,
>
> I made an update of the naming convention spec based on the received feedback. The updated draft can be downloaded here: http://redmine.named-data.net/attachments/download/123/convention.pdf
>
> - Version is redefined to be just a number (larger number represents later version and it is up to the app to define the specific use)
> - New marker for Timestamp
>
> Please comment as we need to have this document approved before we can finalize our release.
>
> ---
> Alex
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


From alexander.afanasyev at ucla.edu  Mon Jul 28 17:24:52 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 28 Jul 2014 17:24:52 -0700
Subject: [Nfd-dev] Naming conventions (draft 4)
In-Reply-To: <CADfzvvau13LgcLcbUT=4E2oqNyoFvdU-SHvSUhpzSKqG9dCxBw@mail.gmail.com>
References: <9809C679-E1BB-4A0A-9AF0-6D05C2A806FD@ucla.edu>
	<CADfzvvau13LgcLcbUT=4E2oqNyoFvdU-SHvSUhpzSKqG9dCxBw@mail.gmail.com>
Message-ID: <988FC8AC-A7CD-4B99-8B2A-C4F4A31409C2@ucla.edu>


On Jul 28, 2014, at 5:13 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> Hi Alex,
> 
> Thanks for the new draft.
> 
> *) 3.3 suggests using a timestamp as "a simple way to implement
> versioning", which sounds odd to me, why not using the timestamp
> marker 0xFC in such cases then?

For me, version and timestamp has semantical difference.  Timestamp is not necessary a version.  Timestamp could be assigned for different data items in time sequenced collection.  Version is about the same data packet.  Using timestamp marker for version creates semantical ambiguity.

> *) In 3.4, the value for the timestamp is in milliseconds. Can we
> change it to microseconds? Applications that don't need this
> granularity can just append zeros as needed.

I have no objections to refine granularity to microseconds.

> *) In 3.4, typo "cane" -> "can"
> 
> *) Why is sequencing a sub-section of timestamping?

an accident.


I have applied the fixes in draft 4: http://redmine.named-data.net/attachments/download/124/convention.pdf

---
Alex

> Thanks,
> Davide
> 
> On Tue, Jul 29, 2014 at 1:21 AM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> Hi guys,
>> 
>> I made an update of the naming convention spec based on the received feedback. The updated draft can be downloaded here: http://redmine.named-data.net/attachments/download/123/convention.pdf
>> 
>> - Version is redefined to be just a number (larger number represents later version and it is up to the app to define the specific use)
>> - New marker for Timestamp
>> 
>> Please comment as we need to have this document approved before we can finalize our release.
>> 
>> ---
>> Alex
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From davide.pesavento at lip6.fr  Mon Jul 28 17:35:25 2014
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 29 Jul 2014 02:35:25 +0200
Subject: [Nfd-dev] Naming conventions (draft 4)
In-Reply-To: <988FC8AC-A7CD-4B99-8B2A-C4F4A31409C2@ucla.edu>
References: <9809C679-E1BB-4A0A-9AF0-6D05C2A806FD@ucla.edu>
	<CADfzvvau13LgcLcbUT=4E2oqNyoFvdU-SHvSUhpzSKqG9dCxBw@mail.gmail.com>
	<988FC8AC-A7CD-4B99-8B2A-C4F4A31409C2@ucla.edu>
Message-ID: <CADfzvvbyLDc8F-8HZ4y=r4j3KK0ePo7Mv9Advmf1+DTQPZiXmA@mail.gmail.com>

On Tue, Jul 29, 2014 at 2:24 AM, Alex Afanasyev
<alexander.afanasyev at ucla.edu> wrote:
>
> On Jul 28, 2014, at 5:13 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
>
>> Hi Alex,
>>
>> Thanks for the new draft.
>>
>> *) 3.3 suggests using a timestamp as "a simple way to implement
>> versioning", which sounds odd to me, why not using the timestamp
>> marker 0xFC in such cases then?
>
> For me, version and timestamp has semantical difference.  Timestamp is not necessary a version.  Timestamp could be assigned for different data items in time sequenced collection.  Version is about the same data packet.  Using timestamp marker for version creates semantical ambiguity.
>

Oh ok, I see the rationale now. And I agree. This difference could be
explained in more detail in the document, maybe with an example, but I
guess we can do it after the spec has been finalized.

>> *) In 3.4, the value for the timestamp is in milliseconds. Can we
>> change it to microseconds? Applications that don't need this
>> granularity can just append zeros as needed.
>
> I have no objections to refine granularity to microseconds.
>
>> *) In 3.4, typo "cane" -> "can"
>>
>> *) Why is sequencing a sub-section of timestamping?
>
> an accident.
>
>
> I have applied the fixes in draft 4: http://redmine.named-data.net/attachments/download/124/convention.pdf
>
> ---
> Alex
>
>> Thanks,
>> Davide
>>
>> On Tue, Jul 29, 2014 at 1:21 AM, Alex Afanasyev
>> <alexander.afanasyev at ucla.edu> wrote:
>>> Hi guys,
>>>
>>> I made an update of the naming convention spec based on the received feedback. The updated draft can be downloaded here: http://redmine.named-data.net/attachments/download/123/convention.pdf
>>>
>>> - Version is redefined to be just a number (larger number represents later version and it is up to the app to define the specific use)
>>> - New marker for Timestamp
>>>
>>> Please comment as we need to have this document approved before we can finalize our release.
>>>
>>> ---
>>> Alex
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



From lixia at CS.UCLA.EDU  Wed Jul 30 15:11:47 2014
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Wed, 30 Jul 2014 15:11:47 -0700
Subject: [Nfd-dev] How to handle unrecognized TLVs
Message-ID: <19371E4C-4E52-4844-A17F-96B4FABB7D0A@cs.ucla.edu>

We discussed this issue during today's NFD call but did not reach a concrete conclusion:

1/ TLV format allows new types to be easily introduced

2/ However when a new type is introduced, it is almost guaranteed that some node does not recognize it.  What should the node do in this case?

a) in the current implementation (as I heard form Alex), in certain cases we do drop, in other cases we forward -- decisions embedded in implementation.

b) IETF current practice is to reserve 2 bits in the type field to define the desired action when running into unrecognized types (commonly it is some combination of (a)forward vs drop, and (b)send an error msg or not)

Do we want to do the same (reserving 2 bits in the type field)?
If so,
- this reduces the number of types for 1-byte type to 32

- where to put these 2 bits?  since type field is variable length, 
  the best place would be the last 2 bits, but that means renumbering
  all the defined types :-(

- there is also a question of whether we need to reserve 2-bit, or one bit could do (just define forward/drop)

Please share your thought!

Lixia


From alexander.afanasyev at ucla.edu  Wed Jul 30 15:19:33 2014
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Wed, 30 Jul 2014 15:19:33 -0700
Subject: [Nfd-dev] How to handle unrecognized TLVs
In-Reply-To: <19371E4C-4E52-4844-A17F-96B4FABB7D0A@cs.ucla.edu>
References: <19371E4C-4E52-4844-A17F-96B4FABB7D0A@cs.ucla.edu>
Message-ID: <A8B7E035-C102-4D98-98C3-1DE8F5E81E4A@ucla.edu>


On Jul 30, 2014, at 3:11 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:

> We discussed this issue during today's NFD call but did not reach a concrete conclusion:
> 
> 1/ TLV format allows new types to be easily introduced
> 
> 2/ However when a new type is introduced, it is almost guaranteed that some node does not recognize it.  What should the node do in this case?
> 
> a) in the current implementation (as I heard form Alex), in certain cases we do drop, in other cases we forward -- decisions embedded in implementation.
> 
> b) IETF current practice is to reserve 2 bits in the type field to define the desired action when running into unrecognized types (commonly it is some combination of (a)forward vs drop, and (b)send an error msg or not)
> 
> Do we want to do the same (reserving 2 bits in the type field)?
> If so,
> - this reduces the number of types for 1-byte type to 32

Small correction: to 64 types of each "processing type".

> - where to put these 2 bits?  since type field is variable length, 
>  the best place would be the last 2 bits, but that means renumbering
>  all the defined types :-(
> 
> - there is also a question of whether we need to reserve 2-bit, or one bit could do (just define forward/drop)
> 
> Please share your thought!
> 
> Lixia



From yingdi at CS.UCLA.EDU  Thu Jul 31 12:30:50 2014
From: yingdi at CS.UCLA.EDU (Yingdi Yu)
Date: Thu, 31 Jul 2014 12:30:50 -0700
Subject: [Nfd-dev] How to handle unrecognized TLVs
In-Reply-To: <A8B7E035-C102-4D98-98C3-1DE8F5E81E4A@ucla.edu>
References: <19371E4C-4E52-4844-A17F-96B4FABB7D0A@cs.ucla.edu>
	<A8B7E035-C102-4D98-98C3-1DE8F5E81E4A@ucla.edu>
Message-ID: <3CACE8E0-4EBC-4BE8-9E6E-D151936F0DA1@cs.ucla.edu>

On Jul 30, 2014, at 3:19 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> On Jul 30, 2014, at 3:11 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
> 
>> We discussed this issue during today's NFD call but did not reach a concrete conclusion:
>> 
>> 1/ TLV format allows new types to be easily introduced
>> 
>> 2/ However when a new type is introduced, it is almost guaranteed that some node does not recognize it.  What should the node do in this case?
>> 
>> a) in the current implementation (as I heard form Alex), in certain cases we do drop, in other cases we forward -- decisions embedded in implementation.
>> 
>> b) IETF current practice is to reserve 2 bits in the type field to define the desired action when running into unrecognized types (commonly it is some combination of (a)forward vs drop, and (b)send an error msg or not)
>> 
>> Do we want to do the same (reserving 2 bits in the type field)?
>> If so,
>> - this reduces the number of types for 1-byte type to 32
> 
> Small correction: to 64 types of each "processing type".

I remember we have already used the leftmost bit to indicate whether the TLV is application-specific, so it actually reduces the number of types to 32 if two more bits are used.

>> - where to put these 2 bits?  since type field is variable length, 
>> the best place would be the last 2 bits, but that means renumbering
>> all the defined types :-(

I do not see the problem of using the 2nd and 3rd leftmost bits for this purpose. We have already used the leftmost bit to indicate app-specific tlv:
for 1byte type, 0-127 is NDN-specific, 128-252 is app-specific
for 3byte type, 253-32767 is NDN-specific, >32768 is app-speicific

>> - there is also a question of whether we need to reserve 2-bit, or one bit could do (just define forward/drop)
I wonder when and what kind of error msg will be sent and what the msg would look like. Should it be a data packet that shares the same name (prefix) as the interest? If so, does that mean applications needs to be able to handle error msg? Moreover, who should sign the error msg and how to verify the err msg?

I think the semantic could be much more simplified if we just define forward/drop.

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140731/440a1ccc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140731/440a1ccc/attachment.bin>