[Nfd-dev] comments for the nfd doc

Syed Obaid Amin obaidasyed at gmail.com
Thu Jun 19 20:03:24 PDT 2014


On Thu, Jun 19, 2014 at 8:50 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

>
> On Jun 19, 2014, at 11:55 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
> >
> > On Jun 19, 2014, at 12:40 AM, Beichuan Zhang <bzhang at cs.ARIZONA.EDU>
> > wrote:
> >
> >> Hi,
> >>
> >> We’ve been integrating the text of the NFD Developer’s Guide, and now
> it is in the final stage. Can everyone read the document or part of it, and
> email in comments? Any comment would be appreciated. We plan to finish it
> by the end of Sunday.
> >>
> >> The current PDF is attached. If you want the latest version, the
> repository is git at git.irl.cs.ucla.edu:papers/nfd-docs.git.
> >>
> >
> > Some comments for Section 7 (Obaid please check):
> >
> > - "The RIB Manager that runs as a separate process, NRD (NFD RIB
> Daemon)" should be "NRD (NFD RIB Daemon), the RIB Manager that runs as a
> separate process, …"
>
> No. I think the description is correct. The correct name is NFD RIB
> Manager and NRD is just an abbreviation of this, not the other way around.
>
>
> > - 19 diagram should be Figure 19.
> >
> > - Figure 19 can be bigger and Figure 20 should be much smaller.
> >
> > - Figure 19 shows only NLSR.  What about other apps?  I suggest adding
> an app's typical interactions with NRD at the end of the time line.
>
> Including more stuff may clutter the picture. I'm ok with including more,
> but just want to make sure we don't include too much.
>

Showing NLSR allowed me to show both self-registration (which should be
same for other apps too) and prefix registration. I also think that  adding
more would clutter the figure. I can add a note at "Register NLSR" step
that further interactions are only valid for NLSR or other routing
protocols?



>
> > - It's not clear what this part means: "7.7 Extending RIB Manager
> > The RIB Manager currently supports only two commands { register and
> unregister. However, functionality of the RIB
> > Manager can be extended by introducing more commands. For example, if a
> node needs to announce a pre x currently, it
> > has to con gure the routing protocol. A set of commands for advertising
> and withdrawing pre xes, with the help of any
> > application, could provide a more uni ed way for the operators to
> publish name pre xes."
> >
> > Isn't advertising and withdrawing prefixes supported through register
> and unregister already?
>
> As I remember, withdraw and advertise were separate commands.  At least in
> the original protocol spec, though I already forgot what was the difference.
>

Yes, these two commands came from the old protocol specs. We added these
commands so that NRD can talk to the routing protocols and can advertise or
withdraw name prefixes through them. If I remember correctly, the
motivation was to allow a unified way of publishing prefixes, instead of
configuring separate routing protocols.

Regards,
Obaid

---
> Alex
>
> > or are you saying any application should be able to advertise and
> withdraw prefixes.  If this is what you mean, first it's not introducing
> more commands.  It's just allowing regular application to issue the
> existing commands, right?  Also I'm not sure if it's a good to let any
> application do these things.
> >
> > Lan
> >> Thanks,
> >>
> >> Beichuan
> >>
> >>
> >>
> >> [The attachment nfd-docs.pdf has been manually removed]
> >>
> >> _______________________________________________
> >> 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/20140619/b06e4232/attachment.html>


More information about the Nfd-dev mailing list