Content-Centric Networking (CCNx) Messages in TLV Format
draft-irtf-icnrg-ccnxmessages-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-07-08
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-06-20
|
09 | David Oran | The CCNx specs have been under development since the inception of the ICNRG. They are highly mature and ready for publication as Experimental RFCs. They … The CCNx specs have been under development since the inception of the ICNRG. They are highly mature and ready for publication as Experimental RFCs. They have strong RG consensus, and have undergone careful editing by the authors, review by the IRSG, and furhter refinement by the RFC Editor. The final text is under review by the shepherd. |
2019-06-20
|
09 | David Oran | Notification list changed to David Oran <daveoran@orandom.net> |
2019-06-20
|
09 | David Oran | Document shepherd changed to David R. Oran |
2019-05-13
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-04-22
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2019-04-01
|
09 | (System) | RFC Editor state changed to AUTH from EDIT |
2019-02-21
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-02-21
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-02-21
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-02-12
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-01-31
|
09 | (System) | RFC Editor state changed to EDIT |
2019-01-31
|
09 | (System) | IANA Action state changed to In Progress |
2019-01-31
|
09 | Allison Mankin | IRTF state changed to Sent to the RFC Editor from In IESG Review |
2019-01-31
|
09 | Allison Mankin | Sent request for publication to the RFC Editor |
2019-01-31
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-01-24
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-01-24
|
09 | Marc Mosko | New version available: draft-irtf-icnrg-ccnxmessages-09.txt |
2019-01-24
|
09 | (System) | New version approved |
2019-01-24
|
09 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Marc Mosko , Ignacio Solis |
2019-01-24
|
09 | Marc Mosko | Uploaded new revision |
2019-01-09
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2019-01-08
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed |
2019-01-03
|
08 | (System) | IANA Review state changed to IANA - Not OK |
2019-01-03
|
08 | Amanda Baber | (Via drafts-eval@iana.org): IESG/Authors/WG Chairs: We have reviewed draft-irtf-icnrg-ccnxmessages-08 and understand that it requires 10 registry actions. However, we have several questions. IANA QUESTION --> … (Via drafts-eval@iana.org): IESG/Authors/WG Chairs: We have reviewed draft-irtf-icnrg-ccnxmessages-08 and understand that it requires 10 registry actions. However, we have several questions. IANA QUESTION --> will the IESG be the organization that designates an expert for the Expert Review/Specification Required registries? IANA NOTE --> RFC 8126 uses the term "Specification Required" to describe the registration procedure that requires both expert review and the provision of a public, readily accessible specification. IANA QUESTION --> The first paragraph of the IANA Considerations section states, "Each type registry can be updated by incrementally expanding the type space, i.e., by allocating and reserving new types." Does this refer to allocating and reserving new registries or new registrations? It isn't clear what the term "reserve" would mean in the former context. We understand that when this document is sent to us for processing, it will require the following actions: ACTION 1: The following registry will be created under the heading "CCNx": Registry Name: CCNx Packet Types Reference: [This document] Registration Procedure: RFC Required Type Name Reference 0 PT_INTEREST [This document, Section 3.2] 1 PT_CONTENT [This document, Section 3.2] 2 PT_RETURN [This document, Section 3.2] 3-255 Unassigned ACTION 2: The following registry will be created under the heading "CCNx": Registry Name: CCNx Interest Return Codes Reference: [This document] Registration Procedure: Expert Review Note: Registration request should include public standard leading to RFC. Type Name Reference 0 ? 1 T_RETURN_NO_ROUTE [This document, Section 3.2.3.3] 2 T_RETURN_LIMIT_EXCEEDED [This document, Section 3.2.3.3] 3 T_RETURN_NO_RESOURCES [This document, Section 3.2.3.3] 4 T_RETURN_PATH_ERROR [This document, Section 3.2.3.3] 5 T_RETURN_PROHIBITED [This document, Section 3.2.3.3] 6 T_RETURN_CONGESTED [This document, Section 3.2.3.3] 7 T_RETURN_MTU_TOO_LARGE [This document, Section 3.2.3.3] 8 T_RETURN_UNSUPPORTED_HASH_RESTRICTION [This document, Section 3.2.3.3] 9 T_RETURN_MALFORMED_INTEREST [This document, Section 3.2.3.3] 10-255 Unassigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? ACTION 3: The following registry will be created under the heading "CCNx": Registry Name: CCNx Hop-by-Hop Types Reference: [This document] Registration Procedure: RFC Required Type Name Reference 0 ? 1 T_INTLIFE [This document, Section 3.4] 2 T_CACHETIME [This document, Section 3.4] 3 T_MSGHASH [This document, Section 3.4] 4-7 Reserved [This document] 8-4093 Unassigned 4094 T_PAD [This document, Section 3.3.1] 4095 T_ORG [This document, Section 3.3.2] 4096-8191 Reserved for Experimental Use [This document, Section 3] 8192-65535 Unasssigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? IANA QUESTION --> The document uses both hex and decimal numbering in this registry. In the future, it may be possible to display more than one method in an IANA registry, but we need to use a consistent method when creating the registry. Should we use hex instead of decimal here? ACTION 4: The following registry will be created under the heading "CCNx": Registry Name: CCNx Top-Level Types Reference: [This document] Registration Procedure: RFC Required Type Name Reference 0 ? 1 T_INTEREST [This document, Section 3.5] 2 T_OBJECT [This document, Section 3.5] 3 T_VALIDATION_ALG [This document, Section 3.5] 4 T_VALIDATION_PAYLOAD [This document, Section 3.5] 5-65535 Unasssigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? ACTION 5: The following registry will be created under the heading "CCNx": Registry Name: CCNx Name Segment Types Reference: [This document] Registration Procedure: Specification Required Type Name Reference 0 ? 1 T_NAMESEGMENT [This document, Section 3.6.1] 2 T_IPID [This document, Section 3.6.1] 3-15 Unassigned 16-19 Reserved [This document] 20-4094 Unassigned 4095 T_ORG [This document, Section 3.3.2] 4096-8191 T_APP:00 - T_APP:4096 [This document, Section 3.6.1] 8192-65535 Unasssigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal? IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document. ACTION 6: The following registry will be created under the heading "CCNx": Registry Name: CCNx Message Types Reference: [This document] Registration Procedure: RFC Required Type Name Reference 0 T_NAME [This document, Section 3.6] 1 T_PAYLOAD [This document, Section 3.6] 2 T_KEYIDRESTR [This document, Section 3.6] 3 T_OBJHASHRESTR [This document, Section 3.6] 4 Unassigned 5 T_PAYLDTYPE [This document, Section 3.6.2.2] 6 T_EXPIRY [This document, Section 3.6.2.2] 7-12 Reserved [This document] 8-4093 Unassigned 4094 T_PAD [This document, Section 3.3.1] 4095 T_ORG [This document, Section 3.3.2] 4096-8191 Reserved for Experimental Use [This document, Section 3] 8192-65535 Unasssigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal? ACTION 7: The following registry will be created under the heading "CCNx": Registry Name: CCNx PayloadType Reference: [This document] Registration Procedure: Specification Required Type Name Reference 0 T_PAYLOADTYPE_DATA [This document, Section 3.6.2.2.1] 1 T_PAYLOADTYPE_KEY [This document, Section 3.6.2.2.1] 2 T_PAYLOADTYPE_LINK [This document, Section 3.6.2.2.1] IANA QUESTION --> Does this registry have a maximum available value (e.g. 255, 65535, etc.)? IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document. ACTION 8: The following registry will be created under the heading "CCNx": Registry Name: CCNx Validation Algorithm Types Reference: [This document] Registration Procedure: Specification Required Type Name Reference 0 ? 1 Unassigned 2 T_CRC32C [This document, Section 3.6.4.1] 3 Unassigned 4 T_HMAC-SHA256 [This document, Section 3.6.4.1] 5 T_RSA-SHA256 [This document, Section 3.6.4.1] 6 EC-SECP-256K1 [This document, Section 3.6.4.1] 7 EC-SECP-384R1 [This document, Section 3.6.4.1] 8-4093 Unassigned 4094 T_PAD [This document, Section 3.3.1] 4095 T_ORG [This document, Section 3.3.2] 4096-8191 Reserved for Experimental Use [This document, Section 3] 8192-65535 Unasssigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal? IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document. IANA QUESTION --> If the registration procedure is listed as "Specification Required," should there also be a note at the top of the registry that reads "Note: registration requires public specification of the algorithm"? ACTION 9: The following registry will be created under the heading "CCNx": Registry Name: CCNx Validation Dependent Data Types Reference: [This document] Registration Procedure: RFC Required Type Name Reference 0 ? 1-8 Unassigned 9 T_KEYID [This document, Section 3.6.4.1.4] 10 T_PUBLICKEYLOC [This document, Section 3.6.4.1.4] 11 T_PUBLICKEY [This document, Section 3.6.4.1.4] 12 T_CERT [This document, Section 3.6.4.1.4] 13 T_LINK [This document, Section 3.6.4.1.4] 14 T_KEYLINK [This document, Section 3.6.4.1.4] 15 T_SIGTIME [This document, Section 3.6.4.1.4] 16-4094 Unassigned 4095 T_ORG [This document, Section 3.3.2] 4096-8191 Reserved for Experimental Use [This document, Section 3] 8192-65535 Unasssigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal? ACTION 10: The following registry will be created under the heading "CCNx": Registry Name: CCNx Hash Function Types Reference: [This document] Registration Procedure: Specification Required Type Name Reference 0 ? 1 T_SHA-256 [This document, Section 3.3.3] 2 T_SHA-512 [This document, Section 3.3.3] 3-4094 Unassigned 4095 T_ORG [This document, Section 3.3.2] 4096-8191 Reserved for Experimental Use [This document, Section 3] 8192-65535 Unasssigned IANA QUESTION --> Should value 0 be listed as "Reserved" (i.e. unavailable for assignment, per RFC 8126), listed as "Unassigned" (i.e. available for assignment), or left out of the registry? IANA QUESTION --> In the document, this registry uses both hex and decimal numbering. Should the IANA registry use hex or decimal? IANA QUESTION --> The registration procedure listed in the IANA Considerations section, "Expert Review with public specification," appears to match the RFC 8126 term "Specification Required," which requires expert review. Is this correct? If so, this should be changed in the document. IANA QUESTION --> If the registration procedure is listed as "Specification Required," should there also be a note at the top of the registry that reads "Note: registration requires public specification of the hash function"? Thank you, Amanda Baber Lead IANA Services Specialist |
2019-01-03
|
08 | (System) | Document has expired |
2018-12-06
|
08 | Allison Mankin | IETF conflict review initiated - see conflict-review-irtf-icnrg-ccnxmessages |
2018-12-06
|
08 | Allison Mankin | Changed consensus to Yes from Unknown |
2018-12-06
|
08 | Allison Mankin | IRTF state changed to In IESG Review from Waiting for IRTF Chair |
2018-07-02
|
08 | Marc Mosko | New version available: draft-irtf-icnrg-ccnxmessages-08.txt |
2018-07-02
|
08 | (System) | New version approved |
2018-07-02
|
08 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Marc Mosko , Ignacio Solis |
2018-07-02
|
08 | Marc Mosko | Uploaded new revision |
2018-04-10
|
07 | Allison Mankin | Look at the revisions and then pass to IESG |
2018-04-10
|
07 | Allison Mankin | Tag AD Followup cleared. |
2018-04-10
|
07 | Allison Mankin | IRTF state changed to Waiting for IRTF Chair from In IRSG Poll |
2018-03-19
|
07 | David Oran | Added to session: IETF-101: icnrg Tue-1550 |
2018-03-19
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-03-19
|
07 | Marc Mosko | New version available: draft-irtf-icnrg-ccnxmessages-07.txt |
2018-03-19
|
07 | (System) | New version approved |
2018-03-19
|
07 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Marc Mosko , Ignacio Solis |
2018-03-19
|
07 | Marc Mosko | Uploaded new revision |
2018-03-05
|
06 | Allison Mankin | Revision expected during or soon after IETF 101 |
2018-02-10
|
06 | Allison Mankin | Upon revision, we will get secdir review. |
2018-02-10
|
06 | Allison Mankin | Tag Revised I-D Needed set. |
2017-11-16
|
06 | Allison Mankin | Combine with reviews |
2017-11-16
|
06 | Allison Mankin | IRTF state changed to In IRSG Poll from Awaiting IRSG Reviews |
2017-10-29
|
06 | Christopher Wood | New version available: draft-irtf-icnrg-ccnxmessages-06.txt |
2017-10-29
|
06 | (System) | New version approved |
2017-10-29
|
06 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Marc Mosko , Ignacio Solis |
2017-10-29
|
06 | Christopher Wood | Uploaded new revision |
2017-09-12
|
05 | Christopher Wood | New version available: draft-irtf-icnrg-ccnxmessages-05.txt |
2017-09-12
|
05 | (System) | New version approved |
2017-09-11
|
05 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Marc Mosko , Ignacio Solis |
2017-09-11
|
05 | Christopher Wood | Uploaded new revision |
2017-07-20
|
04 | David Oran | IRTF state changed to Awaiting IRSG Reviews from In RG Last Call |
2017-06-27
|
04 | David Oran | Added to session: interim-2017-icnrg-02 |
2017-06-27
|
04 | David Oran | IRTF state changed to In RG Last Call |
2017-06-27
|
04 | David Oran | Intended Status changed to Experimental from None |
2017-03-17
|
Jasmine Magallanes | Posted related IPR disclosure: Cisco's Statement about IPR related to draft-irtf-icnrg-ccnxmessages and draft-irtf-icnrg-ccnxsemantics | |
2017-03-13
|
04 | Christopher Wood | New version available: draft-irtf-icnrg-ccnxmessages-04.txt |
2017-03-13
|
04 | (System) | New version approved |
2017-03-13
|
04 | (System) | Request for posting confirmation emailed to previous authors: Christopher Wood , Ignacio Solis , irtf-chair@irtf.org, " marc.mosko@parc.com" , icnrg-chairs@ietf.org |
2017-03-13
|
04 | Christopher Wood | Uploaded new revision |
2016-12-30
|
03 | (System) | Document has expired |
2016-06-28
|
03 | Marc Mosko | New version available: draft-irtf-icnrg-ccnxmessages-03.txt |
2016-04-04
|
02 | Marc Mosko | New version available: draft-irtf-icnrg-ccnxmessages-02.txt |
2016-01-11
|
01 | Marc Mosko | New version available: draft-irtf-icnrg-ccnxmessages-01.txt |
2015-08-26
|
Naveen Khan | Posted related IPR disclosure: Palo Alto Research Center's Statement about IPR related to draft-irtf-icnrg-ccnxsemantics, draft-irtf-icnrg-ccnxmessages, and Presentations by PARC @ IETF 93, 94, … Posted related IPR disclosure: Palo Alto Research Center's Statement about IPR related to draft-irtf-icnrg-ccnxsemantics, draft-irtf-icnrg-ccnxmessages, and Presentations by PARC @ IETF 93, 94, and interim meetings |
|
2015-07-14
|
Naveen Khan | Posted related IPR disclosure: Palo Alto Research Center's Statement about IPR related to draft-irtf-icnrg-ccnxmessages, draft-irtf-icnrg-ccnxsemantics, and Presentations by PARC @ IETF 93 | |
2015-06-29
|
00 | laura.hill@parc.com | New version available: draft-irtf-icnrg-ccnxmessages-00.txt |