Re: [icnrg] CCNx Drafts - next steps

[<[e-mail]>]

The group should adopt the documents.


I’m not sure I understand your reason for not wanting to adopt the document.

You are correct that non-adoption doesn’t prevent further development. If the document doesn’t get adopted by the group, the work will continue as an individual contribution. One of the main differences this has is that as a working group document the draft must reflect “rough consensus”, whereas as an individual contribution, feedback from the group doesn’t have to be taken into account.  So, in a way, you’re basically objecting to the group having input in the development and documentation of the packet format.

Non-adoption would allow us to do whatever we wanted with the protocol.  However, because it is a protocol, and we want to interoperate, we want it to be discussed and criticized publicly. We want changes to go through the thorough review of ICNRG rough consensus.   We think that the current version of CCNx passes this rough consensus.  After all, multiple individuals have had input on the protocols and documents.  We believe that the protocol will be stronger by working together.

Having documents adopted by the group also forces some architectural discussions. What things must go together, what things must be combined? What things require which other things? What things must be split apart so they can be considered separately?   This is reflected in the document organization and separation (Semantics, packet format, fragmentation, etc).  It might be the case that there is agreement on somethings but not on others. Adoption allows the documents to reflect the view of the group in these “architectural” issues.

One of the main goals of RGs is to foster cross-organizational collaboration in important research areas. Adopting the documents would basically achieve this.


I would like to actually flip the question around and ask why wouldn’t you want your protocol to be adopted by ICNRG?  Wouldn’t NDN be stronger as well from ICNRG group feedback?  Isn’t collaboration one of the main goals of NDN/FIA?  As an individual I would gladly support adoption of NDN by the group.


As a side note, applications are very important, but they are not the primary focus of the RG.  This umbrella RG has to deal with all aspects of ICN.  You could look at some of the group drafts (like the challenges doc) and see if some of your concerns are reflected by the documents. Maybe you can contribute stuff there.

I, for one, would like to focus on an interoperable network so we can at least evaluate applications in real world scenarios.

If you have application requirements that would inform the design of the protocol or packet format please bring it forward so we can be informed as we make updates to the drafts; adopted or not.



Again, in terms of your objection to adopt, can you clarify,  from your email the only things I could conclude were:
- Not everybody is working on the same research effort.
- You don’t see adopting multiple documents leading to easier comparisons.
- We shouldn’t adopt formats until we are sure no changes will be required in the future.

I would think these are reasons  _for_ adoption
- Since we have multiple research efforts, we should document them in a similar fashion…
- … so we can compare them better
- We won’t know how to change formats until we have used those formats between multiple people in the real world.


Nacho



--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
[phone]
[e-mail]

On 4/6/15, 12:29 PM, "Alex Afanasyev" <[e-mail]<mailto:[e-mail]>> wrote:


On Apr 6, 2015, at 10:02 AM, [e-mail]<mailto:[e-mail]> wrote:

Thank you - sorry for the mis-statement - I am new to IETF.  We took a sense of the room and people “hummed” that they were in favor of adopting the docs as an experimental platform (not exclusive):


  *   Hums overwhelmingly agreed we should go forward with the adoption of the documents as an experimental option.

Laura

I want to make a few statements.

- People who attended IETF meeting in Dallas represent a small portion of those who are involved with ICN research research group.  Therefore, hums, as Dave pointed, represent only a sense of the room (which in my opinion was skewed), not the opinion of the research group.

- The conversation and humming was about packet format, not the platform.

- I disagree with adopting at this time (even non-exclusively) a packet format that represents an architecture that represents a subset of research efforts of the ICN research group.  I'm also against adopting multiple formats that are currently proposed, as I don't see the benefits for the ICNRG research efforts (e.g., to allow faithfully compare the results), as architectures behind the proposed formats have several major differences that directly impact applications.

Non-adoption does not prevent any experimentation with the technology and platform(s), rather it allows a more flexible way to evolve protocols, architectures, applications.  In my opinion, the latter (the applications) should be the primary focus of the research group.  Before adopting a format, there are so many question yet to be answered that no doubt would require certain features/changes from the packet:  how ICN and individual proposed architectures allow applications to be implemented in better ways?  What are new application patterns become available in ICN?  How ICN improves security aspect of applications (+not reduces security of the existing apps)?  How to enable seamingless infrastructure-full and infrastructure-less communication in ICN; etc.

—
Alex

On Apr 6, 2015, at 9:55 AM, David IMAP Mailstore <[e-mail]<mailto:[e-mail]>> wrote:

On Apr 6, 2015, at 9:49 AM, <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>> wrote:

For those that missed the ICNRG meeting in Dallas, we voted to adopt the CCNx protocol drafts as ICNRG drafts.
No, we did not. We don't vote.
We took the sense of the room, which was to adopt the drafts as RG Drafts, as opposed to individual contributions.

Also, per IRTF procedures, no decisions are made definitively in meetings. They are taken by a poll on the mailing list, which has not yet occurred. I hope to get a message on this out to the list this week.

Also, I any of these messages, please be sure people are pointed to the IPR disclosure associated with them so peoe can assess what if any problems that poses.

Thanks (chair hat on)
DaveO

Please make sure that you take the time and read through the current set of drafts so you can provide feedback.

CCNx Semantics: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxsemantics-01
This draft describes the semantics of the CCNx protocol independently of encoding.

CCNx Packet Format: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxmessages-01
This draft  specifies a Type-Length-Value (TLV) packet format and the TLV type and value encodings for the CCNx network protocol as specified in th CCNx Semantics document.

For your reference, additional specifications have also been submitted:

  *   CCNx Labeled Content: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxlabeledcontent-00
  *   CCNx Content Object Chunking: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxchunking-00
  *   CCNx End-to-End Fragmentation: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxfragmentation-00
  *   CCNx Serial Versioning: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxserialversion-00

We would like to get a new set of drafts out for the next ICNRG meeting, so keep this in mind if you want to send feedback or contribute. The cut-off date for drafts is 2015-07-06. We would like to have the updates ready at least a week before to schedule meeting time as needed.

Many thanks!

Laura
----
Laura Hill
Manager, Documentation and Information Architecture
Palo Alto Research Center (PARC)
[phone]
[e-mail]<mailto:[e-mail]>