Subject: [icnrg] CCNx Drafts - next steps

From: <[email-masked]>
Date: Mon, 6 Apr 2015 16:49:20 +0000

For those that missed the ICNRG meeting in Dallas, we voted to adopt the CCNx protocol drafts as ICNRG drafts. 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)
+1 (650) 812-4493
[email-masked]<mailto:[email-masked]>

---

From: David IMAP Mailstore <[email-masked]>
Date: Mon, 6 Apr 2015 09:55:16 -0700

> On Apr 6, 2015, at 9:49 AM, <[email-masked]> <[email-masked]> 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 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
> 
> [email-masked]
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: <[email-masked]>
Date: Mon, 6 Apr 2015 17:02:50 +0000

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

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

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

Thanks (chair hat on)
DaveO

Many thanks!

Laura
----
Laura Hill

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg
_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg

---

From: Alex Afanasyev <[email-masked]>
Date: Mon, 6 Apr 2015 12:29:22 -0700

> On Apr 6, 2015, at 10:02 AM, [email-masked] wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Apr 6, 2015, at 9:49 AM, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> CCNx Semantics: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxsemantics-01 <http://tools.ietf.org/html/draft-mosko-icnrg-ccnxsemantics-01>
>>> CCNx Packet Format: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxmessages-01 <http://tools.ietf.org/html/draft-mosko-icnrg-ccnxmessages-01>
>>> CCNx Labeled Content: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxlabeledcontent-00 <http://tools.ietf.org/html/draft-mosko-icnrg-ccnxlabeledcontent-00>
>>> CCNx Content Object Chunking: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxchunking-00 <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 <http://tools.ietf.org/html/draft-mosko-icnrg-ccnxfragmentation-00>
>>> CCNx Serial Versioning: http://tools.ietf.org/html/draft-mosko-icnrg-ccnxserialversion-00 <http://tools.ietf.org/html/draft-mosko-icnrg-ccnxserialversion-00>
>>> 
>>> [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Mon, 6 Apr 2015 22:30:07 +0000

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
+1(650)812-4458
[email-masked]

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

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

Laura

—
Alex

Thanks (chair hat on)
DaveO

Many thanks!

Laura
----
Laura Hill

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 07 Apr 2015 12:40:49 +0100

Hi Dave,

On 06/04/15 17:55, David IMAP Mailstore 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.

Is this [1] the (only) relevant IPR disclosure?

If so, and speaking purely as an individual: from a research
point of view that's not a big deal. From the point of view
of work emerging from the IRTF and potentially coming to the
IETF, having work thusly encumbered would be a showstopper
as far as I'm concerned if it arrived at the IETF's door
with [1] attached. Of course, it's entirely possible that [1]
would have been updated by then, but I consider it as a
negative myself.

If the RG adopt these drafts and progress them as one amongst
many, then I would not object. (But I can see why that might
make the RG less productive too.) If the proposal were for the
RG to decide that future work will be based around e.g. the
packet format or one of the other drafts named by [1], then I
would also not object, but I would thereafter consider that
so long as [1] is the relevant IPR declaration, the output
of the ICNRG is not at all likely to ever be useful input to
the IETF.

And again, all of the above is my personal opinion only.

Thanks,
S.

[1] https://datatracker.ietf.org/ipr/2560/

> 
> 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) +1 (650) 812-4493 
>> [email-masked]
>> 
>> 
>> 
>> 
>> _______________________________________________ icnrg mailing list 
>> [email-masked] https://www.irtf.org/mailman/listinfo/icnrg
> 
> 
> 
> _______________________________________________ icnrg mailing list 
> [email-masked] https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: MUSCARIELLO Luca IMT/OLN <[email-masked]>
Date: Tue, 14 Apr 2015 21:04:45 +0200

Hi,

I fail to understand how these drafts could be considered as RG work as 
opposed to an individual contribution.
To me, this  set of drafts is an individual contribution.

Several drafts have been presented on the packet format, and no real 
agreement has been reached to continue
working together on a common draft. In this sense these drafts are not a 
RG contribution, de facto.

 From a research point of view, I think that the disagreement we have 
all expressed has the merit to push
everyone to do more research on the different design choices the packet 
formats would imply.
Which is a good think, IMO.

I also fail to understand the implications of adopting these documents 
as group drafts, as no one else would work on it
except one contributor. I might be missing something here though.

Luca

On 04/06/2015 07:02 PM, [email-masked] 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
>
>> On Apr 6, 2015, at 9:55 AM, David IMAP Mailstore 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>>
>>
>> On Apr 6, 2015, at 9:49 AM, <[email-masked] 
>> <mailto:[email-masked]>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> For those that missed the ICNRG meeting in Dallas, we voted to adopt 
>>> the CCNx protocol drafts as ICNRG drafts.
>> We took the sense of the room, which was to adopt the drafts as RG 
>> Drafts, as opposed to individual contributions.
>>
>> yet occurred. I hope to get a message on this out to the list this week.
>>
>>> 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
>>> 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.
>>>
>>>   * CCNx Labeled Content:
>>>   * CCNx Content Object Chunking:
>>>     http://tools.ietf.org/html/draft-mosko-icnrg-ccnxchunking-00
>>>   * CCNx End-to-End Fragmentation:
>>>   * CCNx Serial Versioning:
>>> 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

---

From: <[email-masked]>
Date: Tue, 14 Apr 2015 20:05:22 +0000

The drafts are currently not RG work, they are individual contributions.   Adopting them would make them RG work.  Many WG/RG drafts start as individual contributions and get adopted as WG/RG documents, hence the word “adopt”.

Once the document is adopted, it will be a RG document and the RG can guide the development.  We are a RG, we are not producing standards. This is very explicit by the charter of the IRTF [1][2] and ICNRG.  The document would at most be Experimental.   This does not preclude any other document from being adopted in any way.

If you feel that your protocol is not ready to be adopted, then continue working on it.  You are free to keep control (and maintain it as an individual contribution) or ask the group to adopt it (and take control).

These documents reflect the views of more than the authors.  They have received and adopted quite a bit of feedback.  We have merged (and removed) a number of items based on suggestions.   We are now looking for more active participation from the whole group.

When you talk about expressing disagreement it seems you imply a large part of the group has disagreed.  I’m not sure if you’re talking about disagreement from adoption or disagreement of the protocol.   In terms of disagreement of adoption, from the last meeting the sense of the room seemed to be overwhelmingly in favor of adoption.  On the list so far, from general replies to Laura’s email, it has been you and Alex.

In terms of disagreement of the protocol itself, it’s not an issue.  A- many people agree with the protocol as is (having worked with us for over a year in the spec),  B- people with other protocols don’t agree (but so far we have been getting closer), C- some people are not sure and need more time to read the drafts, D- most people don’t care.   I would say that just by the number of people we have that agree on the protocol as is, it would be a good enough reason to adopt.  But, to top it off, adoption would actually give everyone a voice, even the people that disagree.    Non-adoption is like saying you don’t want to have a voice.  Again, this is not a final call, it’s adoption to continue working together as a group.

Nacho

[1] https://tools.ietf.org/html/rfc2014
[2] https://tools.ietf.org/html/rfc5743

On 4/14/15, 12:04 PM, "MUSCARIELLO Luca IMT/OLN" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

I fail to understand how these drafts could be considered as RG work as opposed to an individual contribution.
To me, this  set of drafts is an individual contribution.

Several drafts have been presented on the packet format, and no real agreement has been reached to continue
working together on a common draft. In this sense these drafts are not a RG contribution, de facto.

>From a research point of view, I think that the disagreement we have all expressed has the merit to push
everyone to do more research on the different design choices the packet formats would imply.
Which is a good think, IMO.

I also fail to understand the implications of adopting these documents as group drafts, as no one else would work on it
except one contributor. I might be missing something here though.

Luca

On 04/06/2015 07:02 PM, [email-masked]<mailto:[email-masked]> 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):

Laura

Thanks (chair hat on)
DaveO

Many thanks!

Laura
----
Laura Hill

_______________________________________________
icnrg mailing list
[email-masked]<mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/icnrg

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Tue, 14 Apr 2015 20:18:47 +0000

I agree with Nacho. When a document stays as an individual contribution it is hard for the group to collectively contribute. WG acceptance does not mean putting it “in cement” it means that the group recognizes the contribution and will work on it. Many WG document at least in the IETF were greatly modified after going from individual to WG and further to RFC. I actually prefer to limit individual contributions as they less conducive to consensus and general approvals.

Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Apr 14, 2015, at 4:05 PM, [email-masked] wrote:
> 
> [1] https://tools.ietf.org/html/rfc2014 <https://tools.ietf.org/html/rfc2014>
> [2] https://tools.ietf.org/html/rfc5743 <https://tools.ietf.org/html/rfc5743>
> 
> 
> --
> Nacho (Ignacio) Solis
> Protocol Architect
> Principal Scientist
> On 4/14/15, 12:04 PM, "MUSCARIELLO Luca IMT/OLN" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi,
>> 
>> On 04/06/2015 07:02 PM, [email-masked] <mailto:[email-masked]> wrote:
>>> [email-masked] <mailto:[email-masked]>https://www.irtf.org/mailman/listinfo/icnrg <https://www.irtf.org/mailman/listinfo/icnrg>

---

From: MUSCARIELLO Luca IMT/OLN <[email-masked]>
Date: Tue, 14 Apr 2015 22:24:58 +0200

If many people have worked with you for over a year on the spec that 
would  be enough to consider the draft a RG
contribution as opposed to an individual contribution. I just missed to 
see the many people
you mention as contributors in the documents.  BTW,  I guess they'll 
show up and agree for a RG draft.

However this common work didn't take place on the list, AFAIK.

Luca

On 04/14/2015 10:05 PM, [email-masked] wrote:
> In terms of disagreement of the protocol itself, it’s not an issue. 
>  A- many people agree with the protocol as is (having worked with us 
> for over a year in the spec),  B- people with other protocols don’t 
> agree (but so far we have been getting closer), C- some people are not 
> sure and need more time to read the drafts, D- most people don’t care. 
>   I would say that just by the number of people we have that agree on 
> the protocol as is, it would be a good enough reason to adopt.  But, 
> to top it off, adoption would actually give everyone a voice, even the 
> people that disagree.    Non-adoption is like saying you don’t want to 
> have a voice.  Again, this is not a final call, it’s adoption to 
> continue working together as a group.

---

From: <[email-masked]>
Date: Tue, 14 Apr 2015 22:49:20 +0000

The draft will continue being an individual contribution until it is
adopted.

So far, what the document reflects is input from various people and
projects, including the work that you¹ve been involved in.
(https://datatracker.ietf.org/doc/draft-ccn-packet-header/).  For example
in the form of allowing for extension fields; the name index would be a
good example.  We even had a separate writeup devoted to this.

As an individual contribution up until now, some collaboration work did
happened outside the list. We¹ve tried to have the document up-to date
with all discussions and changes for every meeting. We¹ve presented all
changes whenever possible, requesting feedback at every turn.

As for the people supporting this, when you say they¹ll show up and agree
for the RG draft you mean other than the sense of the room from last
meeting?  (See video recording @ 2:08) [1]   Are you looking for
individuals to raise their hand on the mailing list and express their
desire to adopt the document?   The chairs haven¹t made a call for this
yet.

Given that you¹re obviously opposed to the document being adopted, let me
ask, what would it take to convince you to adopt the document?  Do you
think the format is incorrect? Do you think the protocol is broken? Do you
think more work needs to happen on the list before it must be adopted? Do
you think that there is no rough consensus to adopt it? Do you think ICN
protocols don¹t fit in ICNRG? Do you think CCN is not a ICN protocol? Do
you feel adopting this document will impede you from working on something
else?

Nacho

http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_ICNR
G&chapter=chapter_0

On 4/14/15, 1:24 PM, "MUSCARIELLO Luca IMT/OLN"
<[email-masked]> wrote:

>> In terms of disagreement of the protocol itself, it¹s not an issue.
>> for over a year in the spec),  B- people with other protocols don¹t
>> sure and need more time to read the drafts, D- most people don¹t care.
>> people that disagree.    Non-adoption is like saying you don¹t want to
>> have a voice.  Again, this is not a final call, it¹s adoption to

---

From: MUSCARIELLO Luca IMT/OLN <[email-masked]>
Date: Wed, 15 Apr 2015 14:34:54 +0200

Two options:

1) The owner of https://datatracker.ietf.org/ipr/2560/, i.e. PARC,  
produces a set of drafts
that are reviewed by the RG group which sends feedback to the owner who 
eventually integrates
modifications to the drafts.

2) The RG group calls for a common work of the RG to produce a new draft
including the contribution of each other.

Option 1) is of little interest, IMO, as I agree with Stephen's comment: 
that draft won't go that far in the IETF.
Option 2) requires much more collaboration among the people working in 
the RG but will have more chances to
go somewhere in the IETF.

Directly answering to your questions:

Do you think the format is incorrect? Yes
Do you think the protocol is broken? Yes I do, as it requires additional research.
Do you think more work needs to happen on the list before it must be adopted? Yes. More work is required in general.
Do you think that there is no rough consensus to adopt it?  Yes I do.
Do you think ICN protocols don¹t fit in ICNRG?
Do you think CCN is not a ICN protocol?
Do you feel adopting this document will impede you from working on something else? No I don't. I think it will impede the RG to focus on something that will have a future at the IETF.

Nacho, this is just my personal opinion and of course I might be wrong.
I am interested in the adoption of the technology and I feel that the 
adoption of the drafts goes in the opposite direction.

Luca

On 04/15/2015 12:49 AM, [email-masked] wrote:
> .

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 15 Apr 2015 13:20:49 +0000

Everyone, please remember that you are an IRTF research group and not an IETF working group. You are not setting standards, and you can produce experimental specifications that have limited consensus (which should then be described in the documents; see http://wiki.tools.ietf.org/html/rfc5743#section-2.1)

Lars

---

From: <[email-masked]>
Date: Wed, 15 Apr 2015 15:35:19 +0000

I believe you are mistaken on the options;  or at least, have a limited
view.  Documents do go from individual to group drafts (I’m assuming for
you that would be option 3). As a matter of fact, the RFC of Handling of
Internet Drafts (RFC 7221) has this in the first paragraph:
“...When a working group is ready to develop a particular document, the
most common mechanism is for it to "adopt" an existing document as a
starting point..” 

Granted, this is for working groups, but research groups are not that
different in this process. (As Lars pointed out, see the IRTF RFC, 5743).

From your answer:

Incorrect format (I should have specified clearly I meant formatting of
the document) -- We’ll double check with the current formatting.   I’m
sure at least the IANA and security considerations could use some work.

Broken protocol ― Adoption would be the perfect way for the protocol to be
improved.  You would have a say in how to fix it.  Again, the adoption
process is meant to work at various levels of maturity.

Work on the list ― Adoption would mean work happens on the list and on the
meetings, since it would be the research group working on it.

Rough consensus ― Good thing the IRTF has very clear well articulated
rules on rough consensus!  (yes, that was a joke), seriously though,
IETF/IRTF have guidelines on what rough consensus is.  In this case, it’s
rough consensus to adopt the document as a RG draft, nothing more.  It
does not create a standard. It does not force anybody to work on this or
not work on this.

ICN/ICNRG/RG - How will this impede us to focus?  You are free to focus
your time on anything you want.  We’re not going to run out of draft names
or RFC numbers.

Let me step back for a second.  I’m really perplexed at the resistance to
adopt the drafts. This gives the RG (and every person in it) more say over
what happens.  It makes the development process more open.

Nacho

https://tools.ietf.org/html/rfc7221

https://tools.ietf.org/html/rfc5743

On 4/15/15, 5:34 AM, "MUSCARIELLO Luca IMT/OLN"
<[email-masked]> wrote:

>Do you think more work needs to happen on the list before it must be
>adopted? Yes. More work is required in general.
>Do you feel adopting this document will impede you from working on
>something else? No I don't. I think it will impede the RG to focus on
>something that will have a future at the IETF.
>
>

---

From: Mark Stapp <[email-masked]>
Date: Wed, 15 Apr 2015 12:26:32 -0400

I'd like to reiterate what I said at the mic during the Dallas meeting 
where this topic was raised.

I think there's a lot of value in the ccnx group's having invested in 
producing clear, ietf-format documents. they've tried to express a range 
of ideas clearly, from high-level abstract concepts, to protocol 
messaging, to bytes-on-the-wire encoding. I wish that more of the 
discussion in the RG were as direct and ... fact-based.

I think that there's also a lot of merit in the actual contents of the 
documents. I'd like to see more implementation, whether in 'real' 
application experimentation or in simulation, and I'd like to see 
whether having some well-expressed mechanisms that have been documented 
in this way will enable different groups to produce results that can be 
compared meaningfully. in my opinion, there have been very many 
experiments described where an idiosyncratic protocol is used, or where 
the experimenter does not actually know whether, for example, a scheme 
only works if broadcasts are used, or if tcp is used. I think having 
more clear, complete protocol descriptions (and hopefully 
implementations) will help produce more rigorous experiments, with 
better ways to compare and evaluate results.

I hope that there will be more contributions from other groups who have 
different views of the ICN space. we'll have a more productive 
discussion if the details of the different approaches are presented 
clearly and we can talk about the technical merits and drawbacks of 
various alternatives.

And I want to second (third, etc.) the point that this RG's actions do 
not constitute standards of any kind. Adopting contributions as RG 
documents means that there's consensus that there's technical value in 
the proposals, and that it's worth working collectively to 
improve/edit/experiment on the basis of the RG documents.

Regards,
Mark

---

From: MUSCARIELLO Luca IMT/OLN <[email-masked]>
Date: Wed, 15 Apr 2015 20:04:30 +0200

> process is meant to work at various levels of maturity.

I do not mean bad protocol. I think there is a lot of great work in it.
I want to dissipate any doubt on this point. I do not think at all that
the protocol is bad.

> your time on anything you want.  We’re not going to run out of draft names

Thank you to reminding me that I can focus on anything I want.

Do you implicitly mean, by asking for the adoption, that you'll deliver
the code of CCNx1.0
so that people on the list can experiment with that? Or do I need to buy
a license of CCNx1.0 to do that kind of work?

Most of my doubts, not resistance, come from the fact that I cannot do
any of the research work
I think should be done to improve the drafts unless I pay a license to
PARC to get CCNx1.0 code,
or at least pay per view the code.

Maybe I am missing how, in practice, I can really collaborate in any
form in improving these drafts.
Or maybe some people on the list payed/will pay to do that.

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 15 Apr 2015 14:31:36 -0400

___________________________
iDevice - please excuse typos.

> On Apr 7, 2015, at 7:40 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hi Dave,
> 
It's the only one that's been filed.

---

From: <[email-masked]>
Date: Wed, 15 Apr 2015 18:51:18 +0000

>I want to dissipate any doubt on this point. I do not think at all that

I’m fine we cleared that up. :-)

>so that people on the list can experiment with that?

I do not implicitly mean anything.  What adoption means is that the
control of the document passes to IRTF and the group. I guess there might
be implicit rights on the document considering RFC 5378.

The document does not have any bearing on our code, other than our code
tries to implement the protocol described in the documents.

>Or do I need to buy a license of CCNx1.0 to do that kind of work?

I’m not sure if you’re asking about code, protocol, packet formats or
patents.  

Right now, this is an experimental protocol specification. I am not a
lawyer this is not a legal statement. PARC does own intellectual property
that may be reflected in the protocol specification.  This should not be a
problem at this stage (see discussion bellow).

>or at least pay per view the code.

Again, this is a specification. It does not relate to our code.  In fact,
this is better. It means that there would be a generally agreed to
protocol that does not depend on our code and receives input from others.

The spec is currently implemented in CCNx Lite, and it’s probably very
close in the spec Cisco used for some of their experiments.

Yes, our code is currently closed.  This does not affect the spec. If
you’re interested in using our code commercially to develop a product,
yes, you’ll currently have to pay us.  We do routinely consider our
options in this area since the value of a protocol is many times driven by
adoption.

Our IP position has obviously not affected you doing work since you have
worked on protocols that are close enough to our protocols (see your draft
on the CCN packet header).  Same applies to many of the other work being
done in this area.

>Maybe I am missing how, in practice, I can really collaborate in any form
>in improving these drafts.

Strangely enough, I feel that you have this backwards. It would be
advantageous to you to collaborate if you want to change things.

First, IPR is present in practically everything the IETF/IRTF does. This
is why there is a process for this.  For example, does IPR prevent people
collaborating with Orange because of the patents they hold on certain
protocols? (See IPR disclosure list if you want a refresher on the latest
Orange IPR filings).  A lot of those filings are for actual standards, not
for a research experimental protocol that has yet to see the light of day
through deployment anywhere real.

Second, if you dislike our IP position, whether it is the current position
or the position you think we may take up in the future, you should submit
an alternate protocol that does not have IPR behind it. IETF/IRTF will
weigh that in.

We have been very forthcoming about our IPR. If anything, I’m surprised
that no other IPR statements have come forth in any of the other work done
by this group. Do the other contributors to the mailing list, drafts and
presentations have no relevant IP to disclose?

Finally, just to make sure it’s clear, from the IRTF RFC 5743:

“However, although disclosure is required, there are no specific
requirements on the licensing terms for intellectual property related to
IRTF Stream publication."

Nacho

https://tools.ietf.org/html/rfc5378

http://www.ietf.org/mail-archive/web/ipr-announce/current/maillist.html

>>> Do you think the protocol is broken? Yes I do, as it requires
>>>additional
>>> research.
>>>>http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_
>>>>IC
>>>> NR
>>>> G&chapter=chapter_0
>>>>
>>>>
>>>> --
>>>> Nacho (Ignacio) Solis
>>>> Protocol Architect
>>>> Principal Scientist

---

From: [email-masked]
Date: Wed, 15 Apr 2015 20:55:42 +0200 (CEST)

It would be a pitty if we as a RG went down the MANET path, fighting a 
document war since 20 years it seems ... At the same time it shows the 
boom bust cycle where only a few of the contenders made it to RFC level. 
So it starts with expansion - the world is large enough for multiple 
forwarding styles.

But beyond that inevitable expansion, I welcome especially the stability 
created by a RG document. CCNx1.0 (sic) has been in quite some flux 
these months, while NDN was rather stable, so this is a big win.

My main question is PARC's committment when such a RG document evolves - 
will PARC track this in its code base, or fork the documents? We will 
see ...

Regarding code: ccn-lite already speaks NDN, at least partly - I'm 
confident that we can soon show interoperability with CCNx1.0.

best, christian

On Wed, 15 Apr 2015, Mark Stapp wrote:

> I'd like to reiterate what I said at the mic during the Dallas meeting where 
> this topic was raised.
>
> producing clear, ietf-format documents. they've tried to express a range of 
> ideas clearly, from high-level abstract concepts, to protocol messaging, to 
> bytes-on-the-wire encoding. I wish that more of the discussion in the RG were 
> as direct and ... fact-based.
>
> documents. I'd like to see more implementation, whether in 'real' application 
> experimentation or in simulation, and I'd like to see whether having some 
> well-expressed mechanisms that have been documented in this way will enable 
> different groups to produce results that can be compared meaningfully. in my 
> opinion, there have been very many experiments described where an 
> idiosyncratic protocol is used, or where the experimenter does not actually 
> know whether, for example, a scheme only works if broadcasts are used, or if 
> tcp is used. I think having more clear, complete protocol descriptions (and 
> hopefully implementations) will help produce more rigorous experiments, with 
> different views of the ICN space. we'll have a more productive discussion if 
> the details of the different approaches are presented clearly and we can talk 
> about the technical merits and drawbacks of various alternatives.
>
> And I want to second (third, etc.) the point that this RG's actions do not 
> constitute standards of any kind. Adopting contributions as RG documents 
> means that there's consensus that there's technical value in the proposals, 
> and that it's worth working collectively to improve/edit/experiment on the 
> basis of the RG documents.
>
> Regards,
> Mark
>

---

From: <[email-masked]>
Date: Wed, 15 Apr 2015 19:39:27 +0000

Personally, I would like to get the document adopted so we can move forward with this as a group and achieve at least a little consensus as a RG.  Having to work it out in a smoke filled back room makes my eyes water :)  Christian, I hope I’m not up in front of a WG still debating TLV types in 2030.

Compared to where we were in CCNx 0.8, there as has been tremendous changes in the CCNx 1.0 spec.  Even from where we began with the 1.0 spec, we have evolved it quite a bit over the last year based on conversations with others and our own internal evaluations.  I believe the deltas between drafts have been getting smaller and smaller, so hopefully we could work out any remaining issues.

I would welcome additional authors on the drafts, especially as RG documents.  We can also re-format, re-arrange, and re-write the drafts based on community feedback.  We took the approach of having one document on semantics and one document on mechanics (encoding), then additional documents on features built on top of the core protocol.  This can all be updated.

There are some fundamental differences in encoding with NDN.  We can discuss those differences more, but my opinion is that if the community wants a different encoding, we’ll move, and I really doubt we’d fork a different spec based on encoding differences.  

The protocol that runs over an encoding is, of course, different.  Again, we have some fundamental differences with NDN and other ICN proposals.  However, having several different approaches should not preclude adopting one or more of those as RG documents.  Again, we can debate the merits of one approach versus another, and if we are working with RG documents we can update them based on group guidance.

I expect the PARC codebase will track the drafts, whether they are individual contributions or RG documents.  I don’t see value at this point in going off to play in a sandbox alone.  Of course, we’re not standing still or necessarily moving at RG pace, but I expect we’d be implementing research topics over the draft protocols not some custom thing.

Marc

On Apr 15, 2015, at 11:55 AM, [email-masked] wrote:

> It would be a pitty if we as a RG went down the MANET path, fighting a document war since 20 years it seems ... At the same time it shows the boom bust cycle where only a few of the contenders made it to RFC level. So it starts with expansion - the world is large enough for multiple forwarding styles.
> 
> But beyond that inevitable expansion, I welcome especially the stability created by a RG document. CCNx1.0 (sic) has been in quite some flux these months, while NDN was rather stable, so this is a big win.
> 
> My main question is PARC's committment when such a RG document evolves - will PARC track this in its code base, or fork the documents? We will see ...
> 
> Regarding code: ccn-lite already speaks NDN, at least partly - I'm confident that we can soon show interoperability with CCNx1.0.
> 
> best, christian
> 
> 
>> I'd like to reiterate what I said at the mic during the Dallas meeting where this topic was raised.
>> 
>> I think there's a lot of value in the ccnx group's having invested in producing clear, ietf-format documents. they've tried to express a range of ideas clearly, from high-level abstract concepts, to protocol messaging, to bytes-on-the-wire encoding. I wish that more of the discussion in the RG were as direct and ... fact-based.
>> 
>> I think that there's also a lot of merit in the actual contents of the documents. I'd like to see more implementation, whether in 'real' application experimentation or in simulation, and I'd like to see whether having some well-expressed mechanisms that have been documented in this way will enable different groups to produce results that can be compared meaningfully. in my opinion, there have been very many experiments described where an idiosyncratic protocol is used, or where the experimenter does not actually know whether, for example, a scheme only works if broadcasts are used, or if tcp is used. I think having more clear, complete protocol descriptions (and hopefully implementations) will help produce more rigorous experiments, with better ways to compare and evaluate results.
>> 
>> I hope that there will be more contributions from other groups who have different views of the ICN space. we'll have a more productive discussion if the details of the different approaches are presented clearly and we can talk about the technical merits and drawbacks of various alternatives.
>> 
>> And I want to second (third, etc.) the point that this RG's actions do not constitute standards of any kind. Adopting contributions as RG documents means that there's consensus that there's technical value in the proposals, and that it's worth working collectively to improve/edit/experiment on the basis of the RG documents.
>> 
>> Regards,
>> Mark
>>

---

From: MUSCARIELLO Luca IMT/OLN <[email-masked]>
Date: Wed, 15 Apr 2015 21:52:02 +0200

> close in the spec Cisco used for some of their experiments.

Cisco is not asking to adopt their draft and if PARC relies on ccn_lite to
allow experimentation on PARC's draft I see problems coming.

> options in this area since the value of a protocol is many times driven by

An ISP does not build routers, it buys them.
Currently there is nothing to buy so we do not risk much.

Here we are talking about research and I feel like I won't be able to
confront/compare/modify/propose anything on these draft unless
I build the entire thing myself just to be able to talk with you.

Sorry, I won't go through the discussion on IPR. I am not a legal and
you neither.

---

From: <[email-masked]>
Date: Wed, 15 Apr 2015 20:29:36 +0000

>allow experimentation on PARC's draft I see problems coming.

I’m really confused about what you’re talking about.

Having a well specified protocol adopted will _allow_ for experimentation.
This way we can have interoperation between CCN Lite, Cisco, Huawei, PARC
or whoever else wants to implement the spec.  Having a spec allows us to
compare different approaches.

Also, the drafts that we are talking about are only a minute fraction of
what you would need for experimentation, at least at any reasonable scale.
 Right now with the drafts in question we can test forwarding and that’s
about it.  There is no spec for when to cache and what to cache, or what
routing protocol to use, or what policies must be followed in named
advertisements. 

Those types of experiments are enabled by agreeing on a lower format. This
is one such format.

It seems to me that you feel that adoption will set some protocol in stone
and make it somehow mandatory, this is not the case.

>I build the entire thing myself just to be able to talk with you.

So, let me see if I can summarize the argument you are making for not
adopting the document:

Since you don’t currently have access to our source of the implementation
of the spec, 
	you won’t be able to compare and propose anything,
	so you think the group shouldn’t adopt the draft.

Is that correct?

Nacho

>>>>>> in the form of allowing for extension fields; the name index would
>>>>>>be
>>>>>> a
>>>>>> Given that you¹re obviously opposed to the document being adopted,
>>>>>>let
>>>>>> me
>>>>>> think the format is incorrect? Do you think the protocol is broken?
>>>>>>Do
>>>>>> you
>>>>>> think more work needs to happen on the list before it must be
>>>>>>adopted?
>>>>>> Do
>>>>>> protocols don¹t fit in ICNRG? Do you think CCN is not a ICN
>>>>>>protocol?
>>>>>> Do
>>>>>>> contribution as opposed to an individual contribution. I just
>>>>>>>missed
>>>>>>> to
>>>>>>> see the many people

---

From: [email-masked]
Date: Thu, 16 Apr 2015 11:01:18 +0200 (CEST)

you wrote:

"I expect the PARC codebase will track the drafts, whether they 
are individual contributions or RG documents."

This is indeed a strong statement and I'm still amazed how prompt it 
came. I think this is significant.

I wonder who in the ICNRG will follow with similar statements, regarding 
any RG document.

thanks, christian