Skip to main content

Common Ancestor Objective Function and Parent Set DAG Metric Container Extension
draft-ietf-roll-nsa-extension-12

Revision differences

Document history

Date Rev. By Action
2024-02-26
12 Ines Robles Added to session: interim-2024-roll-02
2024-01-22
12 Dominique Barthel Added to session: interim-2024-roll-01
2023-11-08
12 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-12.txt
2023-11-08
12 Remous-Aris Koutsiamanis New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2023-11-08
12 Remous-Aris Koutsiamanis Uploaded new revision
2023-11-06
11 Ines Robles Added to session: IETF-118: roll  Wed-1200
2023-11-01
11 Daniam Henriques
Closed request for Last Call review by RTGDIR with state 'Team Will not Review Version': A new version of the document will be released soon …
Closed request for Last Call review by RTGDIR with state 'Team Will not Review Version': A new version of the document will be released soon and then a new review request will be raised and processed.
2023-11-01
11 Daniam Henriques Assignment of request for Last Call review by RTGDIR to Tony Przygienda was withdrawn
2023-10-25
11 Carl Wallace Request for Last Call review by SECDIR Completed: Ready. Reviewer: Carl Wallace. Sent review to list.
2023-10-19
11 (System) Document has expired
2023-10-19
11 (System) Removed all action holders (IESG state changed)
2023-10-19
11 (System) IESG state changed to Dead from AD is watching
2023-10-09
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Carl Wallace
2023-10-09
11 Tero Kivinen Assignment of request for Last Call review by SECDIR to Steve Hanna was rejected
2023-10-04
11 Alvaro Retana Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Alvaro Retana. Sent review to list.
2023-09-24
11 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Alvaro Retana
2023-07-13
11 Tero Kivinen Request for Last Call review by SECDIR is assigned to Steve Hanna
2023-07-13
11 Tero Kivinen Closed request for Early review by SECDIR with state 'Withdrawn'
2023-07-11
11 Roman Danyliw Requested Early review by SECDIR
2023-07-10
11 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Tony Przygienda
2023-07-10
11 Ines Robles Requested Last Call review by RTGDIR
2023-07-10
11 Ines Robles Requested Last Call review by SECDIR
2023-04-26
11 (System) Changed action holders to John Scudder (IESG state changed)
2023-04-26
11 Cindy Morgan IESG state changed to AD is watching from Dead
2023-04-26
11 Cindy Morgan Shepherding AD changed to John Scudder
2023-04-18
11 Michael Richardson Changed document external resources from: None to:

github_repo https://github.com/roll-wg/draft-ietf-roll-nsa-extension
2023-04-17
11 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-11.txt
2023-04-17
11 Remous-Aris Koutsiamanis New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2023-04-17
11 Remous-Aris Koutsiamanis Uploaded new revision
2023-03-27
10 (System) Document has expired
2023-03-27
10 (System) IESG state changed to Dead from AD is watching
2023-03-26
10 Alvaro Retana Removed all action holders
2023-03-16
10 Alvaro Retana Tag Revised I-D Needed - Issue raised by AD set.
2023-03-16
10 Alvaro Retana IETF WG state changed to WG Document from Submitted to IESG for Publication
2023-03-16
10 Alvaro Retana
My AD term is coming to an end, and this document hasn't been revised based on the review I provided almost a year ago.  After …
My AD term is coming to an end, and this document hasn't been revised based on the review I provided almost a year ago.  After consulting with the new responsible AD, we've decided to return this draft to the WG.
2023-03-16
10 (System) Changed action holders to Alvaro Retana (IESG state changed)
2023-03-16
10 Alvaro Retana IESG state changed to AD is watching from AD Evaluation::Revised I-D Needed
2023-02-23
10 Alvaro Retana Changed action holders to Nicolas Montavont, Pascal Thubert, Georgios Papadopoulos, Remous-Aris Koutsiamanis
2022-03-17
10 Alvaro Retana === AD Review of draft-ietf-roll-nsa-extension-10 ===
https://mailarchive.ietf.org/arch/msg/roll/QTnFl5T7KlbiST8xSC2zrfJLDKA/
2022-03-17
10 (System) Changed action holders to Nicolas Montavont, Alvaro Retana, Pascal Thubert, Georgios Papadopoulos, Remous-Aris Koutsiamanis (IESG state changed)
2022-03-17
10 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-10-12
10 (System) Changed action holders to Alvaro Retana (IESG state changed)
2021-10-12
10 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2021-09-09
10 Alvaro Retana Notification list changed to Dominique Barthel <dominique.barthel@orange.com>, aretana.ietf@gmail.com from Dominique Barthel <dominique.barthel@orange.com>
2021-03-10
10 Ines Robles
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard. This is the type indicated in the title page header.
This draft defines a new Objective Function for the RPL (RFC6550) routing protocol, as well as a new extension for the Node State and Attibute (NSA) object for the RPL routing metric (RFC6551).

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

[Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.]

Packet Replication and Elimination (PRE) is a general method for maximizing packet delivery rate and potentially minimizing latency and jitter.
PRE achieves controlled redundancy by laying multiple forwarding paths through a network and forwarding copies of a same packet in parallel over these paths.
PRE can follow the Destination-Oriented Directed Acyclic Graph (DODAG) formed, in a distributed fashion, by RPL.
RPL allows selecting multiple parents for each node in a network, a subset of these parents being used to forward packets.
What was missing so far to achieve PRE with RPL was
- an Objective Function (OF) that drives a node to locally select its parents based on their contributions to controlled redundant paths
- a metric that allows parent candidates to advertise their own parent set, allowing the Objective Function to achieve the aforementioned goal
This document specifies such metric and OF (actually even 3 different flavors of the OF).

Working Group Summary:

[Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?]
There was no controversy, but a few reviews and discussions on a few technical aspects.
One topic carried over is about compressing the list of IPv6 addresses that are included in the Parent Set TLV of the metric.
The WG decided that this compression should be out of the scope of this draft, since a general compression technique for all RPL control messages (and in particular, those that carry IPv6 addresses) is needed anyway.
Until such compression is standardised, the applicability of this draft is likely to be limited to not-so-constrained networks.

Document Quality:

[Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?]
There is one academic implementation known so far (by Tomas Lagos Jenscke, who is specifically recognized in the Acknowledgements section).
This work is awaited by the 6TiSCH and DetNet groups as the way to achieve Packet Replication and Elimination with RPL.
Therefore, other implementations are expected to emerge as part of the various 6TiSCH implementations.

Personnel:

[Who is the Document Shepherd? Who is the Responsible Area Director?]
The shepherd is Dominique Barthel.
The responsible AD is Alvaro Retana.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The Shepherd, who happens to be a co-author of RFC6551, had a special interest in this draft and performed several thorough reviews over the two years it was matured.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No particular concern, for the reason mentionned in (3). The draft was reviewed by several competent contributors of the ROLL WG. However, more reviews from people with different backgrounds are always good.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
I don't believe any such particular perspective is needed, although Security Considerations reviews often bring back their load of surprises.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

As mentionned in (2), a compression technique (beyond that of 6LoWPAN) is needed for this document to be applicable to constrained network. The WG intends to work on this, going forward.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes, the 4 authors have confirmed that they are not aware of any IPR related to this draft, beyond disclosures # 3286 and 3269.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Two IPR disclosures have been filed, which reference an earlier version of this document: # 3286 and 3269, Aug 2018.
This has been announced on the mailing list and displayed at several ROLL meetings. This has not prompted any discussion on the ML or at the WG meetings.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Packet Replication and Elimination is of interest for only a few people in the Working Group, who are mostly 6TiSCH and DetNet contributors.
They turn out to be among the most active and influencial contributors to the ROLL WG at the moment.
Other individuals in the WG seem to understand what is being done and have not expressed disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No significant discontent was expressed about this draft.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Idnit reports no issue on version -10 of the draft, except for one warning: one informative reference (draft-ietf-6tisch-architecture-29) has advanced to -30 since publication of -10 of this draft.
This will be corrected as part of the changes following IESG review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no such content requiring formal review.

(13) Have all references within this document been identified as either normative or informative?

Yes indeed.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are to published RFC's.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document adds a new Objective Function (new code point) to RPL. RPL (RFC 6550) anticipated that objective functions would be added later as separate documents, so the status of RFC 6550 is not changed by this document.
This documents adds a TLV option (new code point) in the RPL Routing Metric/Constraint of RFC 6551. RFC 6551 anticipated that new options would be added later, so the status of RFC 6551 is not changed by this document.
In any case, RFC 6550 and 6551 are appropriately described and referenced in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This draft does not define any newly created IANA registries.
I have verified that the new requested codepoints (one for the Objective Function, one for the Parent Set option of the RPL Routing Metric/Constraint) accurately reference the appropriate IANA registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This draft does not define any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

There is no such section in this draft.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not Applicable.
2021-03-10
10 Ines Robles Responsible AD changed to Alvaro Retana
2021-03-10
10 Ines Robles IETF WG state changed to Submitted to IESG for Publication from WG Document
2021-03-10
10 Ines Robles IESG state changed to Publication Requested from I-D Exists
2021-03-10
10 Ines Robles IESG process started in state Publication Requested
2021-03-10
10 Dominique Barthel
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?
Proposed Standard. This is the type indicated in the title page header.
This draft defines a new Objective Function for the RPL (RFC6550) routing protocol, as well as a new extension for the Node State and Attibute (NSA) object for the RPL routing metric (RFC6551).

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

[Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.]

Packet Replication and Elimination (PRE) is a general method for maximizing packet delivery rate and potentially minimizing latency and jitter.
PRE achieves controlled redundancy by laying multiple forwarding paths through a network and forwarding copies of a same packet in parallel over these paths.
PRE can follow the Destination-Oriented Directed Acyclic Graph (DODAG) formed, in a distributed fashion, by RPL.
RPL allows selecting multiple parents for each node in a network, a subset of these parents being used to forward packets.
What was missing so far to achieve PRE with RPL was
- an Objective Function (OF) that drives a node to locally select its parents based on their contributions to controlled redundant paths
- a metric that allows parent candidates to advertise their own parent set, allowing the Objective Function to achieve the aforementioned goal
This document specifies such metric and OF (actually even 3 different flavors of the OF).

Working Group Summary:

[Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?]
There was no controversy, but a few reviews and discussions on a few technical aspects.
One topic carried over is about compressing the list of IPv6 addresses that are included in the Parent Set TLV of the metric.
The WG decided that this compression should be out of the scope of this draft, since a general compression technique for all RPL control messages (and in particular, those that carry IPv6 addresses) is needed anyway.
Until such compression is standardised, the applicability of this draft is likely to be limited to not-so-constrained networks.

Document Quality:

[Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?]
There is one academic implementation known so far (by Tomas Lagos Jenscke, who is specifically recognized in the Acknowledgements section).
This work is awaited by the 6TiSCH and DetNet groups as the way to achieve Packet Replication and Elimination with RPL.
Therefore, other implementations are expected to emerge as part of the various 6TiSCH implementations.

Personnel:

[Who is the Document Shepherd? Who is the Responsible Area Director?]
The shepherd is Dominique Barthel.
The responsible AD is Alvaro Retana.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The Shepherd, who happens to be a co-author of RFC6551, had a special interest in this draft and performed several thorough reviews over the two years it was matured.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No particular concern, for the reason mentionned in (3). The draft was reviewed by several competent contributors of the ROLL WG. However, more reviews from people with different backgrounds are always good.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.
I don't believe any such particular perspective is needed, although Security Considerations reviews often bring back their load of surprises.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

As mentionned in (2), a compression technique (beyond that of 6LoWPAN) is needed for this document to be applicable to constrained network. The WG intends to work on this, going forward.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
Yes, the 4 authors have confirmed that they are not aware of any IPR related to this draft, beyond disclosures # 3286 and 3269.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
Two IPR disclosures have been filed, which reference an earlier version of this document: # 3286 and 3269, Aug 2018.
This has been announced on the mailing list and displayed at several ROLL meetings. This has not prompted any discussion on the ML or at the WG meetings.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Packet Replication and Elimination is of interest for only a few people in the Working Group, who are mostly 6TiSCH and DetNet contributors.
They turn out to be among the most active and influencial contributors to the ROLL WG at the moment.
Other individuals in the WG seem to understand what is being done and have not expressed disagreement.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)
No significant discontent was expressed about this draft.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Idnit reports no issue on version -10 of the draft, except for one warning: one informative reference (draft-ietf-6tisch-architecture-29) has advanced to -30 since publication of -10 of this draft.
This will be corrected as part of the changes following IESG review.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no such content requiring formal review.

(13) Have all references within this document been identified as either normative or informative?

Yes indeed.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are to published RFC's.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document adds a new Objective Function (new code point) to RPL. RPL (RFC 6550) anticipated that objective functions would be added later as separate documents, so the status of RFC 6550 is not changed by this document.
This documents adds a TLV option (new code point) in the RPL Routing Metric/Constraint of RFC 6551. RFC 6551 anticipated that new options would be added later, so the status of RFC 6551 is not changed by this document.
In any case, RFC 6550 and 6551 are appropriately described and referenced in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

This draft does not define any newly created IANA registries.
I have verified that the new requested codepoints (one for the Objective Function, one for the Parent Set option of the RPL Routing Metric/Constraint) accurately reference the appropriate IANA registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This draft does not define any new IANA registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

There is no such section in this draft.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not Applicable.
2020-10-29
10 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-10.txt
2020-10-29
10 (System) New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2020-10-29
10 Remous-Aris Koutsiamanis Uploaded new revision
2020-09-26
09 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-09.txt
2020-09-26
09 (System) New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2020-09-26
09 Remous-Aris Koutsiamanis Uploaded new revision
2020-07-02
08 Dominique Barthel Changed consensus to Yes from Unknown
2020-07-02
08 Dominique Barthel Intended Status changed to Proposed Standard from None
2020-06-08
08 Ines Robles Notification list changed to Dominique Barthel <dominique.barthel@orange.com>
2020-06-08
08 Ines Robles Document shepherd changed to Dominique Barthel
2020-04-28
08 Ines Robles Added to session: interim-2020-roll-01
2020-03-27
08 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-08.txt
2020-03-27
08 (System) New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2020-03-27
08 Remous-Aris Koutsiamanis Uploaded new revision
2020-03-09
07 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-07.txt
2020-03-09
07 (System) New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2020-03-09
07 Remous-Aris Koutsiamanis Uploaded new revision
2020-02-10
06 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-06.txt
2020-02-10
06 (System) New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2020-02-10
06 Remous-Aris Koutsiamanis Uploaded new revision
2019-11-04
05 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-05.txt
2019-11-04
05 (System) New version accepted (logged-in submitter: Remous-Aris Koutsiamanis)
2019-11-04
05 Remous-Aris Koutsiamanis Uploaded new revision
2019-07-17
04 Peter Van der Stok Added to session: IETF-105: roll  Wed-1000
2019-07-08
04 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-04.txt
2019-07-08
04 (System) New version approved
2019-07-08
04 (System) Request for posting confirmation emailed to previous authors: Nicolas Montavont , Pascal Thubert , Georgios Papadopoulos , Remous-Aris Koutsiamanis
2019-07-08
04 Remous-Aris Koutsiamanis Uploaded new revision
2019-06-28
03 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-03.txt
2019-06-28
03 (System) New version approved
2019-06-28
03 (System) Request for posting confirmation emailed to previous authors: Nicolas Montavont , Pascal Thubert , Georgios Papadopoulos , Remous-Aris Koutsiamanis
2019-06-28
03 Remous-Aris Koutsiamanis Uploaded new revision
2019-06-24
02 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-02.txt
2019-06-24
02 (System) New version approved
2019-06-24
02 (System) Request for posting confirmation emailed to previous authors: Nicolas Montavont , Pascal Thubert , Georgios Papadopoulos , Remous-Aris Koutsiamanis
2019-06-24
02 Remous-Aris Koutsiamanis Uploaded new revision
2019-03-12
01 Ines Robles Added to session: IETF-104: roll  Mon-1610
2019-03-11
01 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-01.txt
2019-03-11
01 (System) New version approved
2019-03-11
01 (System) Request for posting confirmation emailed to previous authors: Nicolas Montavont , Pascal Thubert , Georgios Papadopoulos , Remous-Aris Koutsiamanis
2019-03-11
01 Remous-Aris Koutsiamanis Uploaded new revision
2018-12-18
00 Peter Van der Stok This document now replaces draft-koutsiamanis-roll-nsa-extension instead of None
2018-12-18
00 Remous-Aris Koutsiamanis New version available: draft-ietf-roll-nsa-extension-00.txt
2018-12-18
00 (System) WG -00 approved
2018-12-18
00 Remous-Aris Koutsiamanis Set submitter to "Remous-Aris Koutsiamanis ", replaces to draft-koutsiamanis-roll-nsa-extension and sent approval email to group chairs: roll-chairs@ietf.org
2018-12-18
00 Remous-Aris Koutsiamanis Uploaded new revision