Skip to main content

A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
draft-ietf-lime-yang-connectionless-oam-methods-13

Revision differences

Document history

Date Rev. By Action
2019-04-16
13 Alissa Cooper Shepherding AD changed to Ignas Bagdonas
2019-03-11
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-02-11
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-02-04
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-11-07
13 (System) RFC Editor state changed to EDIT from MISSREF
2017-11-27
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-11-22
13 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-11-22
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-11-14
13 (System) IANA Action state changed to In Progress from On Hold
2017-11-14
13 (System) IANA Action state changed to On Hold from In Progress
2017-11-13
13 (System) RFC Editor state changed to MISSREF
2017-11-13
13 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-11-13
13 (System) Announcement was received by RFC Editor
2017-11-12
13 (System) IANA Action state changed to In Progress
2017-11-12
13 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-11-12
13 Amy Vezza IESG has approved the document
2017-11-12
13 Amy Vezza Closed "Approve" ballot
2017-11-12
13 Amy Vezza Ballot approval text was generated
2017-11-12
13 Amy Vezza Ballot writeup was changed
2017-11-12
13 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-11-12
13 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-13.txt
2017-11-12
13 (System) New version approved
2017-11-12
13 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar
2017-11-12
13 Qin Wu Uploaded new revision
2017-11-12
13 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar
2017-11-12
13 Qin Wu Uploaded new revision
2017-10-28
12 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-10-28
12 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-12.txt
2017-10-28
12 (System) New version approved
2017-10-28
12 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar
2017-10-28
12 Qin Wu Uploaded new revision
2017-10-26
11 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead
2017-10-26
11 Alia Atlas
[Ballot comment]
After a useful conversation with Benoit, I better understand how the status-code and sub-status-code
are intended to be used.  While I do still …
[Ballot comment]
After a useful conversation with Benoit, I better understand how the status-code and sub-status-code
are intended to be used.  While I do still have some concerns about the clarity and ease of using this,
I do not think it is Discuss-worthy, so I have moved these to be Comments.

a)  It would be helpful to clarify that and how additional OAM YANG modules
are expected to use the status-code identityref and sub-status-code identityref
so that there is a clear indication of how OAM modules are expected to interact
and be build to interact.

b) To handle the cases where OAM mechanisms might be triggered by the RPCs but that
OAM mechanism may not have an associated YANG module, it would be useful to be able
to send back the numeric codes (whether status-code or sub-status-code).  Maybe that's a
generic module of status codes - but this could help with dependencies.

These two points get to what I was concerned/confused by in (1) below.

1) on p. 19: "        leaf status-code {
          type identityref{
            base status-code;
          }
          mandatory true;
          description
          "Error code for continuity-check message, that is
            relevant to the protocol under use for CC.
            For example if ICMP is the protocol under use, the
            error codes are as defined in [RFC4443].";
        }"
I am quite unclear on how this could technically be used??  RFC4443 defines integer error codes or types and
sub-codes that are also integers.
Is the expectation that an ICMPv6-specific YANG module will define those codes as identityrefs???
Clarification in at least the description is needed, since I don't see how it could be used as currently defined.

=======================================

1) On p.6 : "leaf protocol-id-meta-data {
            type uint64;
            description
              "An optional meta-data related to the protocol ID.
                For e.g., this could be the Internet Protocol number
                for standard Internet Protocols for help in protocol
                processing.";
          }"
Seems very useful - but how and where would a tool be able to learn the expected contents and parsing of the
protocol-id-meta-data?  I do not see any indication in the module on p.16 where the protocol-ids are defined -
not even in the descriptions much less programmatically.

2) The complete data hierarchy in Sec 3.2 is confusing in a couple ways.  First, it isn't clear what is going to be
defined in this document and what is from draft-ietf-lime-yang-connectionless-oam-14.  Second, the groupings
are all expanded - which makes it very hard to see the logical structure & requires sanity-checking that the same
information appears.
2017-10-26
11 Alia Atlas [Ballot Position Update] Position for Alia Atlas has been changed to No Objection from Discuss
2017-10-26
11 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2017-10-26
11 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2017-10-25
11 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2017-10-25
11 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2017-10-25
11 Alia Atlas
[Ballot discuss]
1) on p. 19: "        leaf status-code {
          type identityref{
          …
[Ballot discuss]
1) on p. 19: "        leaf status-code {
          type identityref{
            base status-code;
          }
          mandatory true;
          description
          "Error code for continuity-check message, that is
            relevant to the protocol under use for CC.
            For example if ICMP is the protocol under use, the
            error codes are as defined in [RFC4443].";
        }"
I am quite unclear on how this could technically be used??  RFC4443 defines integer error codes or types and
sub-codes that are also integers.
Is the expectation that an ICMPv6-specific YANG module will define those codes as identityrefs???
Clarification in at least the description is needed, since I don't see how it could be used as currently defined.
2017-10-25
11 Alia Atlas
[Ballot comment]
1) On p.6 : "leaf protocol-id-meta-data {
            type uint64;
            description
  …
[Ballot comment]
1) On p.6 : "leaf protocol-id-meta-data {
            type uint64;
            description
              "An optional meta-data related to the protocol ID.
                For e.g., this could be the Internet Protocol number
                for standard Internet Protocols for help in protocol
                processing.";
          }"
Seems very useful - but how and where would a tool be able to learn the expected contents and parsing of the
protocol-id-meta-data?  I do not see any indication in the module on p.16 where the protocol-ids are defined -
not even in the descriptions much less programmatically.

2) The complete data hierarchy in Sec 3.2 is confusing in a couple ways.  First, it isn't clear what is going to be
defined in this document and what is from draft-ietf-lime-yang-connectionless-oam-14.  Second, the groupings
are all expanded - which makes it very hard to see the logical structure & requires sanity-checking that the same
information appears.
2017-10-25
11 Alia Atlas [Ballot Position Update] New position, Discuss, has been recorded for Alia Atlas
2017-10-25
11 Benjamin Kaduk Request for Telechat review by SECDIR Completed: Ready. Reviewer: Benjamin Kaduk. Sent review to list.
2017-10-25
11 Alissa Cooper
[Ballot comment]
There is an outstanding issue stemming from the Gen-ART review concerning whether two-way delay is supported and whether it would be signaled by …
[Ballot comment]
There is an outstanding issue stemming from the Gen-ART review concerning whether two-way delay is supported and whether it would be signaled by specifying TWAMP as the protocol-id. This should be resolved before the document gets published.
2017-10-25
11 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2017-10-25
11 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2017-10-24
11 Adam Roach
[Ballot comment]
id-nits reports:

  ** There are 5 instances of too long lines in the document, the longest one
    being 3 characters …
[Ballot comment]
id-nits reports:

  ** There are 5 instances of too long lines in the document, the longest one
    being 3 characters in excess of 72.

The document uses "id", "Id", and "ID" interchangeably for "identifier." I suggest changing these to "ID" everywhere.

The indenting and spacing in the YANG module appears to be inconsistent. You may want to consider a formatting pass to make it easier to read.
2017-10-24
11 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2017-10-24
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2017-10-24
11 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-11.txt
2017-10-24
11 (System) New version approved
2017-10-24
11 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar
2017-10-24
11 Qin Wu Uploaded new revision
2017-10-24
10 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2017-10-24
10 Eric Rescorla
[Ballot comment]
I noted a few nits:

Line 729
    description
      "Propreitary protocol (eg.,IP SLA).";
  }
Typo: proprietary


Line 766 …
[Ballot comment]
I noted a few nits:

Line 729
    description
      "Propreitary protocol (eg.,IP SLA).";
  }
Typo: proprietary


Line 766
  identity invalid-cc{
  base status-code;
Nit: " {"
2017-10-24
10 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2017-10-24
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2017-10-23
10 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2017-10-23
10 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-lime-yang-connectionless-oam-methods-10, and we have a question for Benoit.

QUESTION: should …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-lime-yang-connectionless-oam-methods-10, and we have a question for Benoit.

QUESTION: should the new YANG module be posted in the registry? If so, instructions should be added to the IANA Considerations section.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single new registration is to be made as follows:

ID: yang:ietf-connectionless-oam
URI: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods
Filename: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

The IESG-designated expert has reviewed and approved this request.

Second, in the YANG Module Names registry on the YANG Parameters page located at:

https://www.iana.org/assignments/yang-parameters/

a single new module name is to be registered as follows:

Name: ietf-connectionless-oam-methods
Namespace: urn:ietf:params:xml:ns:yang:ietf-connectionless-oam-methods
Prefix: cloam-methods
Module:
Reference: [ RFC-to-be ]

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist
2017-10-23
10 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2017-10-23
10 Jouni Korhonen Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Jouni Korhonen. Sent review to list.
2017-10-23
10 Kathleen Moriarty
[Ballot comment]
Thanks for your work on this draft.  In the security considerations, could you please add a clause on network reconnaissance into the text …
[Ballot comment]
Thanks for your work on this draft.  In the security considerations, could you please add a clause on network reconnaissance into the text since that could lead to other attack types (compromise, etc.).

OLD:

These are the
  operations and their sensitivity/vulnerability:

  o  continuity-check: Generates continuity check.

  o  path-discovery: Generates path discovery.

  which may lead to Denial-of-Service attack on both the local device
  and the network or unauthorized source access to some sensitive
  information.

NEW:
These are the
  operations and their sensitivity/vulnerability:

  o  continuity-check: Generates continuity check.

  o  path-discovery: Generates path discovery.

  which may be used for network reconnaissance or lead to Denial-of-Service attack on both the local device
  and the network or unauthorized source access to some sensitive
  information.
2017-10-23
10 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2017-10-23
10 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-10.txt
2017-10-23
10 (System) New version approved
2017-10-23
10 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar
2017-10-23
10 Qin Wu Uploaded new revision
2017-10-21
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2017-10-19
09 Benoît Claise Ballot has been issued
2017-10-19
09 Benoît Claise [Ballot Position Update] New position, Yes, has been recorded for Benoit Claise
2017-10-19
09 Benoît Claise Created "Approve" ballot
2017-10-19
09 Benoît Claise Ballot writeup was changed
2017-10-13
09 Brian Carpenter Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. Sent review to list.
2017-10-12
09 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2017-10-12
09 Jean Mahoney Request for Telechat review by GENART is assigned to Brian Carpenter
2017-10-12
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Benjamin Kaduk
2017-10-12
09 Tero Kivinen Request for Telechat review by SECDIR is assigned to Benjamin Kaduk
2017-10-11
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jouni Korhonen
2017-10-11
09 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Jouni Korhonen
2017-10-11
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2017-10-11
09 Amy Vezza
The following Last Call announcement was sent out (ends 2017-10-25):

From: The IESG
To: IETF-Announce
CC: Ron Bonica , cpignata@cisco.com, lime-chairs@ietf.org, Carlos Pignataro …
The following Last Call announcement was sent out (ends 2017-10-25):

From: The IESG
To: IETF-Announce
CC: Ron Bonica , cpignata@cisco.com, lime-chairs@ietf.org, Carlos Pignataro , draft-ietf-lime-yang-connectionless-oam-methods@ietf.org, bclaise@cisco.com, lime@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols) to Proposed Standard


The IESG has received a request from the Layer Independent OAM Management in
the Multi-Layer Environment WG (lime) to consider the following document: -
'Retrieval Methods YANG Data Model for Connectionless Operations,
  Administration, and Maintenance(OAM) protocols'
  as Proposed
  Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides technology-independent RPC
  operations for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details.  This is leading to uniformity between OAM protocols and
  support both nested OAM workflows (i.e., performing OAM functions at
  different levels through a unified interface) and interacting OAM
  workflows ( i.e., performing OAM functions at same levels through a
  unified interface).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lime-yang-connectionless-oam-methods/ballot/


No IPR declarations have been submitted directly on this I-D.




2017-10-11
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2017-10-11
09 Benoît Claise Placed on agenda for telechat - 2017-10-26
2017-10-11
09 Benoît Claise Last call was requested
2017-10-11
09 Benoît Claise Last call announcement was generated
2017-10-11
09 Benoît Claise Ballot approval text was generated
2017-10-11
09 Benoît Claise Ballot writeup was generated
2017-10-11
09 Benoît Claise IESG state changed to Last Call Requested from AD Evaluation
2017-10-11
09 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-09.txt
2017-10-11
09 (System) New version approved
2017-10-11
09 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar
2017-10-11
09 Qin Wu Uploaded new revision
2017-10-04
08 Carlos Pignataro
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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

(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

  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides a technology-independent
  RPC commands for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (adjunct document)
  and the retrieval methods (this document).

Document Quality

  There are plans of and implementations of this protocol.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.
  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro is the Document Shepherd
  Benoit Claise is the Responsible Area  Director

(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.

  This version of the document is ready to be sent to the responsible AD.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns regarding both breath and depth of reviews.

(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.

  YANG, with review taken place by YANG Doctors (Carl Moberg)

(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.

  None.

(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, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(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? 

  WG Agreement.

(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 threat of appeal.

  One working group participant has expressed discontent several
  times. In particular, this participant has expressed concern that
  his comments have not been addressed and also that he has
  not been given enough time to review. Part of that discussion can
  be seen at:
  https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4
  -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk
    -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI
      -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c
      -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I
  -> https://mailarchive.ietf.org/arch/msg/lime/l9Ym6lj7twTqqB0wz_EyHam_9P8

  The WG held 4 "Editathon" interims in which we went comment-by-comment
  hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime

  Further, both LIME WG Chairs believe there's been ample opportunity
  to share review and comments in multiple occasions, and that
  the document editors have responded timely and incorporated
  comments. In fact, multiple deadlines were given to this participant.
  Many of these deadlines were not respected, yet the WG and document
  editors waited and incorporated late comments just to get another
  deadline. This caused delay and broke the WG flow.

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

  None.

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

  YANG Doctor

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

  Yes.

(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?

  Yes, to active I-Ds.

(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.

(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.

  No.

(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 5226).

  All looks good.

(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.

  None.

(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, etc.

  YANG Doctors Review.
  YANG Validator.
2017-10-03
08 Carlos Pignataro
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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

(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

  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides a technology-independent
  RPC commands for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (adjunct document)
  and the retrieval methods (this document).

Document Quality

  There are plans of and implementations of this protocol.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.
  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro is the Document Shepherd
  Benoit Claise is the Responsible Area  Director

(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.

  This version of the document is ready to be sent to the responsible AD.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns regarding both breath and depth of reviews.

(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.

  YANG, with review taken place by YANG Doctors (Carl Moberg)

(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.

  None.

(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, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(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? 

  WG Agreement.

(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 threat of appeal.

  One working group participant has expressed discontent several
  times. In particular, this participant has expressed concern that
  his comments have not been addressed and also that he has
  not been given enough time to review. Part of that discussion can
  be seen at:
  https://mailarchive.ietf.org/arch/msg/lime/mxhWWvOUh3t_RGV-y4jx9SYBWQ4
  -> https://mailarchive.ietf.org/arch/msg/lime/C0jK4TZl1O7QM9mSF08CpNe0lSk
    -> https://mailarchive.ietf.org/arch/msg/lime/8NekB0HmACry-vjYM1h_S75WhAI
      -> https://mailarchive.ietf.org/arch/msg/lime/Y7W6EB9QUCvWZSdhUP4EhoTJ07c
      -> https://mailarchive.ietf.org/arch/msg/lime/kCCHIgU0Yj8A87Z6foE5koTa_5I
  -> https://mailarchive.ietf.org/arch/msg/lime/l9Ym6lj7twTqqB0wz_EyHam_9P8

  The WG held 4 "Editathon" interims in which we went comment-by-comment
  hosting a discussion and providing a disposition: https://datatracker.ietf.org/meeting/past#lime

  Further, both LIME WG Chairs believe there's been ample opportunity
  to share review and comments in multiple occasions, and that
  the document editors have responded timely and incorporated
  comments.

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

  None.

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

  YANG Doctor

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

  Yes.

(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?

  Yes, to active I-Ds.

(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.

(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.

  No.

(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 5226).

  All looks good.

(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.

  None.

(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, etc.

  YANG Doctors Review.
  YANG Validator.
2017-09-20
08 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-08.txt
2017-09-20
08 (System) New version approved
2017-09-20
08 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Srihari Raghavan , Qin Wu , Zitao Wang , Deepak Kumar
2017-09-20
08 Qin Wu Uploaded new revision
2017-09-15
07 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-07.txt
2017-09-15
07 (System) New version approved
2017-09-15
07 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang
2017-09-15
07 Qin Wu Uploaded new revision
2017-08-31
06 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-06.txt
2017-08-31
06 (System) New version approved
2017-08-31
06 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang
2017-08-31
06 Qin Wu Uploaded new revision
2017-07-04
05 Benoît Claise IESG state changed to AD Evaluation from Publication Requested
2017-06-28
05 Carlos Pignataro
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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

(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

  This document presents a retrieval method YANG Data model for
  connectionless OAM protocols.  It provides a technology-independent
  RPC commands for connectionless OAM protocols.  The retrieval methods
  model presented here can be extended to include technology specific
  details. 

Working Group Summary

  This document is the product of an early split of LIME YANG
  Models into Connection-Oriented (C-O) OAM Models and
  Connectionless (CL, i.e., this) OAM Models. Further, the
  CL Model is further split into the Model (adjunct document)
  and the retrieval methods (this document).

Document Quality

  There are plans of and implementations of this protocol.
  This includes at least two different implementations of
  the model, as well as product and demos at Bits-n-Bytes.
  Further, there are plans to finalize the implementation of
  this specification.

  The WG was very active in reviewing these documents.
  Notably, participants of the BFD and MPLS WGs were
  special reviewers.
  Additionally, worth mentioning Carl Moberg's YANG
  Doctor review which resulted in many fixes and
  improvements.

Personnel

  Carlos Pignataro is the Document Shepherd
  Benoit Claise is the Responsible Area  Director

(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.

  This version of the document is ready to be sent to the responsible AD.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns regarding both breath and depth of reviews.

(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.

  YANG, with review taken place by YANG Doctors (Carl Moberg)

(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.

  None.

(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, during WG adoption.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(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? 

  WG Agreement.

(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 threat of appeal.

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

  None.

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

  YANG Doctpr

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

  Yes.

(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?

  Yes, to active I-Ds.

(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.

(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.

  No.

(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 5226).

  All looks good.

(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.

  None.

(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, etc.

  YANG Doctors Review.
  YANG Validator.
2017-06-28
05 Carlos Pignataro Responsible AD changed to Benoit Claise
2017-06-28
05 Carlos Pignataro IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-06-28
05 Carlos Pignataro IESG state changed to Publication Requested
2017-06-28
05 Carlos Pignataro IESG process started in state Publication Requested
2017-06-28
05 Carlos Pignataro Tag Other - see Comment Log cleared.
2017-06-28
05 Carlos Pignataro Notification list changed to Carlos Pignataro <cpignata@cisco.com>, Ron Bonica <rbonica@juniper.net> from Carlos Pignataro <cpignata@cisco.com>
2017-06-28
05 Carlos Pignataro Changed document writeup
2017-06-19
05 Zitao Wang New version available: draft-ietf-lime-yang-connectionless-oam-methods-05.txt
2017-06-19
05 (System) New version approved
2017-06-19
05 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang
2017-06-19
05 Zitao Wang Uploaded new revision
2017-06-09
04 Carlos Pignataro Changed document writeup
2017-06-08
04 Qin Wu New version available: draft-ietf-lime-yang-connectionless-oam-methods-04.txt
2017-06-08
04 (System) New version approved
2017-06-08
04 (System) Request for posting confirmation emailed to previous authors: Reshad Rahman , Deepak Kumar , Srihari Raghavan , Qin Wu , Zitao Wang
2017-06-08
04 Qin Wu Uploaded new revision
2017-06-02
03 Carl Moberg Request for Early review by YANGDOCTORS Completed: On the Right Track. Reviewer: Carl Moberg. Sent review to list.
2017-06-01
03 Carlos Pignataro Expecting revised ID addressing Nits.
2017-06-01
03 Carlos Pignataro Tag Other - see Comment Log set.
2017-06-01
03 Carlos Pignataro Notification list changed to Carlos Pignataro <cpignata@cisco.com>
2017-06-01
03 Carlos Pignataro Document shepherd changed to Carlos Pignataro
2017-06-01
03 Carlos Pignataro Tag Revised I-D Needed - Issue raised by WG cleared.
2017-06-01
03 Carlos Pignataro IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2017-06-01
03 Carlos Pignataro Tag Revised I-D Needed - Issue raised by WG set.
2017-06-01
03 Carlos Pignataro IETF WG state changed to In WG Last Call from WG Document
2017-06-01
03 Carlos Pignataro Changed consensus to Yes from Unknown
2017-06-01
03 Carlos Pignataro Intended Status changed to Proposed Standard from None
2017-05-30
03 Zitao Wang New version available: draft-ietf-lime-yang-connectionless-oam-methods-03.txt
2017-05-30
03 (System) New version approved
2017-05-30
03 (System) Request for posting confirmation emailed to previous authors: Zitao Wang , Reshad Rahman , Deepak Kumar , lime-chairs@ietf.org, Srihari Raghavan , Qin Wu
2017-05-30
03 Zitao Wang Uploaded new revision
2017-05-15
02 Zitao Wang New version available: draft-ietf-lime-yang-connectionless-oam-methods-02.txt
2017-05-15
02 (System) New version approved
2017-05-15
02 (System) Request for posting confirmation emailed to previous authors: Zitao Wang , Reshad Rahman , Deepak Kumar , lime-chairs@ietf.org, Srihari Raghavan , Qin Wu
2017-05-15
02 Zitao Wang Uploaded new revision
2017-03-30
01 Carlos Pignataro Added to session: IETF-98: lime  Thu-1740
2017-02-23
01 Zitao Wang New version available: draft-ietf-lime-yang-connectionless-oam-methods-01.txt
2017-02-23
01 (System) New version approved
2017-02-23
01 (System) Request for posting confirmation emailed to previous authors: Zitao Wang , Reshad Rahman , Deepak Kumar , lime-chairs@ietf.org, Srihari Raghavan , Qin Wu
2017-02-23
01 Zitao Wang Uploaded new revision
2017-02-07
00 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Carl Moberg
2017-02-07
00 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Carl Moberg
2017-02-07
00 Mehmet Ersue Requested Early review by YANGDOCTORS
2016-10-31
00 Zitao Wang New version available: draft-ietf-lime-yang-connectionless-oam-methods-00.txt
2016-10-31
00 (System) WG -00 approved
2016-10-31
00 Zitao Wang Set submitter to "Michael Wang ", replaces to (none) and sent approval email to group chairs: lime-chairs@ietf.org
2016-10-31
00 Zitao Wang Uploaded new revision