Re: [yang-doctors] YANG FAQ page and Developing of the Answers

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Mon, 06 June 2016 11:00 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DEB12D0A9 for <yang-doctors@ietfa.amsl.com>; Mon, 6 Jun 2016 04:00:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.315
X-Spam-Level:
X-Spam-Status: No, score=-8.315 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqHnZvHJSQ_2 for <yang-doctors@ietfa.amsl.com>; Mon, 6 Jun 2016 04:00:26 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9014212D0E9 for <yang-doctors@ietf.org>; Mon, 6 Jun 2016 04:00:25 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AZAQAJV1VX/xUHmMZbGQEBAQEBgk8hLFZ9BoVEh1ytM4F2BBcBCYVxAoEyOBQBAQEBAQEBZSeERQEBAQEDAQEBDwgBDAY+AwsQAgEIDQECAQMBAQEBChYBBgcnCxQJCAEBBAENBQgBGYgNAQ2eZZtEAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYog0mBA4JZgUoBAQUYDhAMCgiCboISHAWIBQyFVYVShRABhgKKDE6EAoMghUWGO4kfHjaBTDscgUtuAQEBiFQNFwcYAX4BAQE
X-IPAS-Result: A2AZAQAJV1VX/xUHmMZbGQEBAQEBgk8hLFZ9BoVEh1ytM4F2BBcBCYVxAoEyOBQBAQEBAQEBZSeERQEBAQEDAQEBDwgBDAY+AwsQAgEIDQECAQMBAQEBChYBBgcnCxQJCAEBBAENBQgBGYgNAQ2eZZtEAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYog0mBA4JZgUoBAQUYDhAMCgiCboISHAWIBQyFVYVShRABhgKKDE6EAoMghUWGO4kfHjaBTDscgUtuAQEBiFQNFwcYAX4BAQE
X-IronPort-AV: E=Sophos;i="5.26,426,1459828800"; d="scan'208,217";a="190354641"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Jun 2016 07:00:20 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 06 Jun 2016 07:00:19 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Mon, 6 Jun 2016 07:00:18 -0400
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Benoit Claise <bclaise@cisco.com>, Andy Bierman <andy@yumaworks.com>, "Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com>
Thread-Topic: [yang-doctors] YANG FAQ page and Developing of the Answers
Thread-Index: AdG/VH5NQpNvhc6dQGuzF57fUdLtVQAC32gAABUQIgAAC1yPoA==
Date: Mon, 06 Jun 2016 11:00:17 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA752032E2@AZ-FFEXMB04.global.avaya.com>
References: <AMXPR07MB215DECE780A217751171795915B0@AMXPR07MB215.eurprd07.prod.outlook.com> <CABCOCHRXgxsMXNDr7Z+5YJ1nU2dFi6p1dZ1pf3Y_Q5e+wDmUDg@mail.gmail.com> <bd9b267e-e9f1-d24b-6cbb-c8e9b49032a3@cisco.com>
In-Reply-To: <bd9b267e-e9f1-d24b-6cbb-c8e9b49032a3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.48]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA752032E2AZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/tB8P-CycAb3QoHBjgiVMHrbKN8Y>
Cc: "yang-doctors@ietf.org" <yang-doctors@ietf.org>
Subject: Re: [yang-doctors] YANG FAQ page and Developing of the Answers
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jun 2016 11:00:33 -0000

My two agorot: if the answer is in one of the RFCs the answer can be quite short. One or two sentences clarifying the issue, and then 'see RFC ..., Section ...'. However, not only 'See RFC ... Section ...'.

I would take exception of the Sunday trainings, even if we may have pointers to presentations or recordings. The reason is that they are non-normative in language and style, and more difficult to search in.

I am less sure that we should include references to work-in-progress and non-settled issues like opstate. The line of avoiding to issue guidelines until these are settled seems right to me.

Regards,

Dan




From: yang-doctors [mailto:yang-doctors-bounces@ietf.org] On Behalf Of Benoit Claise
Sent: Monday, June 06, 2016 10:28 AM
To: Andy Bierman; Ersue, Mehmet (Nokia - DE/Munich)
Cc: yang-doctors@ietf.org
Subject: Re: [yang-doctors] YANG FAQ page and Developing of the Answers

Hi Andy,

It's wishful thinking to hope that people who wants to know about YANG/NETCONF will review...
    - RFC6244
    - IETF Sunday trainings
    - RFC6020/RFC6020bis
    - RFC6087/RFC6087bis
... before asking their first questions.
Note that I can see the addition of some extra questions "What I should review to know YANG/NETCONF/RESTCONF?".

The FAQs are questions received by the YANG doctors. Some level of overlap is fine. Not necessary with text duplication: a  pointer to RFC6020bis or RFC6087bis or ... is sometimes sufficient. And if the information is not in RFC6087bis, then we have to ask ourselves: why? should it be?

For the opstate status, I agree with you.

Regards, Benoit
Hi,

One concern raised at the last IETF was too much overlap between
the FAQ and the rfc6087bis draft.  Most of the issues so far are in the
draft already, and the other ones just say "there should be a guideline...".

The opstate and module organization are a fairly radioactive topics,
so rfc6087bis has avoided any guidelines until the issues are settled.
I don't want overlap so the guidelines will just point to RFC that defines
all the opstate details (I hope).



Andy




On Sun, Jun 5, 2016 at 11:05 AM, Ersue, Mehmet (Nokia - DE/Munich) <mehmet.ersue@nokia.com<mailto:mehmet.ersue@nokia.com>> wrote:
Hi All,

Benoit proposed to update/maintain the YANG Wiki FAQ page. This is basically to do by
assigning questions to people and validating the drafted answer text on YANG doctor's list
(see attached mail).

As a result the Q/A page at https://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=-QopTTDk4NEzjKNoAllxV6GdtJ_p6fk31N0HDWMKw1U&e=>
will be updated with the validated answers.
As a starter I will assign the 6 questions currently on the FAQ page to people I assume can answer it appropriately.
We need to check whether the current answer on this page is sufficient and improve as necessary.
If you don't like the question formulation you can provide a better one in your draft.

Please send your proposed draft answer to yang-doctors@ietf.org<mailto:yang-doctors@ietf.org> for validation and use the answered question in the subject (at least partly if it is long).
PLMK with a short note if you feel uncomfortable with the assigned question.

I propose to note the assignments on the page below as a new category: YANG Questions and Answers
https://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors-review-history<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Ddoctors-2Dreview-2Dhistory&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=qw9Y0w_AavNiIRVVnwC8sUrPF8K3gy2_fDkslkLYDzw&e=>

Please let us know the questions you think should be addressed on the FAQ page.
As a reminder the minutes of YANG editing and advice sessions are attached.

Any other suggestions are welcome.

Many Thanks.

Cheers,
Mehmet




---------- Forwarded message ----------
From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>>
To: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>, Martin Bjorklund <mbj@tail-f.com<mailto:mbj@tail-f.com>>
Cc: YANG Doctors <yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>>
Date: Wed, 18 May 2016 10:22:46 +0000
Subject: Re: [yang-doctors] YANG FAQ
Dear all,

Second topic now: The FAQ.

In my email below, I mentioned this point:
4. YANG FAQ.
At this point in time, I believe that the WIKI is the right way to go. We can see later how the content evolves. The first step is to update https://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=-QopTTDk4NEzjKNoAllxV6GdtJ_p6fk31N0HDWMKw1U&e=> with the typical questions received by YANG doctors, and maybe with content from Juergen's draft.
We have a couple of questions already at https://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=-QopTTDk4NEzjKNoAllxV6GdtJ_p6fk31N0HDWMKw1U&e=>
Btw, not too sure who answered the first two. This might be worth tracking.

The types of questions we want to answer on that WIKI are:
    - stemming from previous YANG editing sessions, document reviews, or direct feedback from YANG modelers
      For example, Rajiv Asati added questions 3, 4, and 5
    - not addressed by RFC 6087bis (but which could belong there, to be decided)

We might consider adding the content from https://tools.ietf.org/html/draft-schoenw-netmod-yang-pattern-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dschoenw-2Dnetmod-2Dyang-2Dpattern-2D00&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=uwteyPSmX75Khs9fDRjE8a8IVs3cLZ7F300WFCCc5rA&e=>

Exactly like for the document reviews, Dan will be assigning those questions to YANG doctors, who would be in charge of drafting an answer (before or after discussion on this list).

The end goal is to provider YANG modelers/reviewers with two pointers
    RFC6087bis
    These FAQs
If the answer is not in here (or RFC6020bis or RFC6244 or another RFC or ...), then we know we're missing something.

I hope it makes sense. Let me know.

Regards, Benoit

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


Primary YANG doctor page to bookmark: http://www.ietf.org/iesg/directorate/yang-doctors.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_iesg_directorate_yang-2Ddoctors.html&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=M3efNKJjoKB2vGgj4V8-H_Tzfar51zjhYmEFU8obyjM&e=>
>From there, you can find the important links, including the review assignments:

  *   YANG module security guidelines<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Dsecurity-2Dguidelines&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=GNy2EKgMABpedOBtWPwKbffRCE_JoD_FYw_sMuceL68&e=>
  *   NETMOD WIKI<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_wg_netmod_trac_wiki&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=5k6c5uArEkrdQuAEYZnjCaxSG5RYvZHYdgCiwfJNwVg&e=>
  *   NETCONF WIKI (tools, paper, presentations, tutorial)<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_wg_netconf_trac_wiki&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=T_UOTuscHleTk51AZAFJ5GQ5ICTZwPS64-iIrUskWjg&e=>
  *   YANG review assignments<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Ddoctors-2Dreview-2Dhistory&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=h1yk5N9Wq-b2VvKcrUhhmVPZ24CkhN_RfX6-DCyIw_g&e=>
  *   YANG review tools<https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Dreview-2Dtools&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=OKjYs5SZ5lgT2eB14t0_wSlkUHQ01o6fecjvhf5eOf4&e=>
  *   Historical page <https://urldefense.proofpoint.com/v2/url?u=http-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Dhistorical-2Ddata&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=YVM54zPt5gXI1K9GCiFmYE7ReEZljqGUirg480pnLhI&e=>
  *   YANG Questions/Answers<https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=-QopTTDk4NEzjKNoAllxV6GdtJ_p6fk31N0HDWMKw1U&e=>

Dear all,

I've been waiting for a couple of days before answering, to allow for more YANG doctors feedback.

First of, I believe that this priority list is right:
The YANG doctors are all volunteers. Below are guidelines for response time
1) WG document in WGLC: 2 - 4 weeks
2) WG document under development: 2 - 8 weeks
3) non-WG document: best effort (really)
It's correct that we mainly/only receive requests from category 3 at this point, and I will be pushing back on those.

2. Let's look at the stats for category 2 (no category 1 for now)
One third of drafts containing YANG data models (only the ones that extract without problems) are WG documents.
bclaise@bclaise-VirtualBox:~/ietf/draft-with-YANG-strict$ ls -l | wc -l
119
bclaise@bclaise-VirtualBox:~/ietf/draft-with-YANG-strict$ ls -l draft-ietf-* | wc -l
39
bclaise@bclaise-VirtualBox:~/ietf/draft-with-YANG-strict$

bclaise@bclaise-VirtualBox:~/ietf/draft-with-YANG-strict$ ls  draft-ietf-*
draft-ietf-bfd-yang-01.txt
draft-ietf-ccamp-wson-yang-01.txt
draft-ietf-dhc-dhcpv6-yang-01.txt
draft-ietf-i2rs-rib-data-model-05.txt
draft-ietf-i2rs-yang-l2-network-topology-02.txt
draft-ietf-i2rs-yang-l3-topology-01.txt
draft-ietf-i2rs-yang-network-topo-02.txt
draft-ietf-idr-bgp-model-01.txt
draft-ietf-ippm-twamp-yang-00.txt
draft-ietf-isis-yang-isis-cfg-08.txt
draft-ietf-l2tpext-keyed-v6-tunnel-yang-01.txt
draft-ietf-l3sm-l3vpn-service-model-05.txt
draft-ietf-lime-yang-oam-model-03.txt
draft-ietf-lisp-yang-01.txt
draft-ietf-lmap-yang-04.txt
draft-ietf-netconf-restconf-12.txt
draft-ietf-netconf-server-model-09.txt
draft-ietf-netconf-yang-library-05.txt
draft-ietf-netconf-yang-patch-08.txt
draft-ietf-netconf-yang-push-02.txt
draft-ietf-netconf-zerotouch-08.txt
draft-ietf-netmod-acl-model-07.txt
draft-ietf-netmod-rfc6087bis-06.txt
draft-ietf-netmod-routing-cfg-21.txt
draft-ietf-netmod-schema-mount-01.txt
draft-ietf-netmod-syslog-model-07.txt
draft-ietf-netmod-yang-metadata-07.txt
draft-ietf-ospf-yang-04.txt
draft-ietf-pim-yang-00.txt
draft-ietf-rtgwg-policy-model-01.txt
draft-ietf-rtgwg-yang-key-chain-02.txt
draft-ietf-rtgwg-yang-rip-01.txt
draft-ietf-spring-sr-yang-02.txt
draft-ietf-teas-yang-rsvp-03.txt
draft-ietf-teas-yang-te-03.txt
draft-ietf-teas-yang-te-topo-04.txt
draft-ietf-trill-yang-04.txt
draft-ietf-trill-yang-oam-03.txt
draft-ietf-trill-yang-pm-02.txt

I expect that most NETCONF and NETMOD documents are fine from a YANG point of view.
I also believe that some routing ones are lead by YANG experts, so we should be good.
This still leaves us with some proactive work to do.

3.
As spotted by Dan, http://www.ietf.org/iesg/directorate/yang-doctors.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_iesg_directorate_yang-2Ddoctors.html&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=M3efNKJjoKB2vGgj4V8-H_Tzfar51zjhYmEFU8obyjM&e=> calls for reviews at WGLC, which is different from MIB documents reviews.

I asked the Secretariat to include this update.
OLD:
All YANG documents will be passed by a YANG doctor reviewer before they will be approved by the IESG. The YANG doctor review must be done after the Working Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on I-Ds that include YANG documents should ask the OPS ADs for a review as soon as the document completed WGLC.

NEW:
All YANG documents will be passed by a YANG doctor reviewer before they will be approved by the IESG. The YANG doctor review must be done after the Working Group Last Call and before the IETF Last Call. ADs and WG chairs responsible on I-Ds that include YANG documents should ask the OPS ADs for a review as soon as the document completed WGLC. Failing that request, the review will be conducted during the IETF Last Call.

4. YANG FAQ.
At this point in time, I believe that the WIKI is the right way to go. We can see later how the content evolves. The first step is to update https://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors <https://urldefense.proofpoint.com/v2/url?u=https-3A__trac.tools.ietf.org_area_ops_trac_wiki_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=-QopTTDk4NEzjKNoAllxV6GdtJ_p6fk31N0HDWMKw1U&e=> with the typical questions received by YANG doctors, and maybe with content from Juergen's draft.

5. Dan Romascanu proposes himself as YANG doctors secretary. Thanks for volunteering Dan.
I have some visibility on the maturity of the YANG data models, so Dan and I could help with the early assignments. Note: Dan is on vacation till May 1st. If some YANG doctors don't want to be assigned YANG models for review, it's about time to tell us.

Regards, Benoit


On Fri, Apr 15, 2016 at 12:34 AM, Martin Bjorklund <mbj@tail-f.com<mailto:mbj@tail-f.com>> wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> wrote:
> The question is whether we want some sort of change control. For the
> pattern, I tend to think having change control is a good thing since
> the pattern should ideally after some discussion be stable and longer
> time valid.
>
> If you have pattern, then write them down and send them here or to
> NETMOD. Yeah, I know, this is old style...

But we also would like to collect the patterns.


Let's list some options:

1) collect everything in one I-D, keep updating it, never publish as
   RFC.


How would we tell the difference from a real I-D   ;-)



2) collect everything in one I-D, keep updating it, publish "often" as
   an Informationl RFC

3) gitbook (https://github.com/GitbookIO/gitbook<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_GitbookIO_gitbook&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=73IW0Fbp8M1y8YmJTZ2cHND8XqU0mFXoY1hNpd5QjBs&e=>)
   create a yang-doctors repo at github, publish often/automatically,
   either through gitbook.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__gitbook.com&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=dEd5bQ__2r2uCOEgrNsAWyA6wkswt_S13GrGQLOdD_Q&e=> or yang-central.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__yang-2Dcentral.org&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=Roht6ZXSQsxDHjwC6vNF8ARXcSmDKueo_82NNRFHry8&e=> or something else

   write in markdown/asciidoc + graphics, check in to github

4) wiki
   ietf or github wiki



I think an IETF maintained WEB page is best

Let's use the wiki page Benoit mentioned.



1) is current state of affair, except it isn't really updated (it is
updated locally, but the draft is still -00)

2) gives us strict "change control", everything is properly reviewed,
and adding new patterns will be slow

3) doesn't give us normal ietf review process, but we can define our
own review process.  easy for others to collaborate.  nice result;
online, pdf, epub...

4) doesn't give us normal ietf review process.  not as easy for others
to collaborate.


The YANG Patterns draft did not really get any interest, even though
it was good work.  Not the first time that has happened.
Maybe re-marketed as the YANG FAQ it will do better.

Each entry should be "How do I do this? , w/answer"


How do I link my list to the interfaces list?
   - interface-ref typedef
   - direct leafref
   - match key-stmt
   - augment
   - augment-when

Where should I put must-stmts?

How do I know if I need a must-stmt or not?
What are easier ways to accomplish the same constraint?

When should I define a grouping instead of inline definitions?
(We do not agree on this in YD)

When should I use a YANG feature?

When should I defined a new module instead of adding
a YANG feature + objects to an existing module?

We could probably come up with 100 Q&A if we tried.


Andy




I would like to try option 3.  I think options 1 and 2 are the wrong
tool for the problem.  Wikis rarely work well over time.  I don't know
if option 3 works better over time, but I think it would be
interesting to try it out.



/martin

_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>
https://www.ietf.org/mailman/listinfo/yang-doctors<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=cgShsKHcMyDIU1PJsR-kHGnPVIreOenBGsQUE9VaLwM&e=>




_______________________________________________

yang-doctors mailing list

yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>

https://www.ietf.org/mailman/listinfo/yang-doctors<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=cgShsKHcMyDIU1PJsR-kHGnPVIreOenBGsQUE9VaLwM&e=>




_______________________________________________

yang-doctors mailing list

yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>

https://www.ietf.org/mailman/listinfo/yang-doctors<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=cgShsKHcMyDIU1PJsR-kHGnPVIreOenBGsQUE9VaLwM&e=>



---------- Forwarded message ----------
From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>>
To: "Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com<mailto:mehmet.ersue@nokia.com>>
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com<mailto:dromasca@avaya.com>>
Date: Wed, 1 Jun 2016 13:59:11 +0000
Subject: Sent to NSN.COM<https://urldefense.proofpoint.com/v2/url?u=http-3A__NSN.COM&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=nZl6UsDWBRsv-3Y68DPDD5ImGuJo0W1QONV5gFmDBXU&e=> - Fwd: Meeting minutes: IETF 93: YANG editing and advice session, July 19th 2015



-------- Forwarded Message --------
Subject:

IETF 93: YANG editing and advice session

Date:

Sun, 19 Jul 2015 17:26:24 +0200

From:

Benoit Claise <bclaise@cisco.com><mailto:bclaise@cisco.com>

To:

Benoit Claise <bclaise@cisco.com><mailto:bclaise@cisco.com>



1. prefix name advice

2. tunnel:

    no unified idea of the tunnel

    typdef for end points, for encaps

    where do we put the encap?

    ZITAO WANG: Huawei (for China Telecom)

    Andy: one place for common typedefs

    L3VPN, GRE, VLAN: different tunnel types

    Benoit: 5 or 6 tunnel

3. typedef for end points

    generic: could be done, but discussed happened and conclusion ->

not worth it

    Andy: like interface identityref

4. Andy: Grouping versus augment



5. maintainable over time

    like openconfig

6 augmentation and uses











.






---------- Forwarded message ----------
From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>>
To: "Ersue, Mehmet (Nokia - DE/Munich)" <mehmet.ersue@nokia.com<mailto:mehmet.ersue@nokia.com>>
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com<mailto:dromasca@avaya.com>>
Date: Wed, 1 Jun 2016 13:58:39 +0000
Subject: Sent to NSN.COM<https://urldefense.proofpoint.com/v2/url?u=http-3A__NSN.COM&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=nZl6UsDWBRsv-3Y68DPDD5ImGuJo0W1QONV5gFmDBXU&e=> - Fwd: Meeting minutes: IEFF 92 YANG editing and advice session, RFC 6087bis



-------- Forwarded Message --------
Subject:

Meeting minutes: IEFF 92 YANG editing and advice session, RFC 6087bis

Date:

Sun, 22 Mar 2015 20:07:23 -0500

From:

Benoit Claise <bclaise@cisco.com><mailto:bclaise@cisco.com>

To:

me <bclaise@cisco.com><mailto:bclaise@cisco.com>



Lada:
- lead address should be extending
- container that can be enabled/disabled
    canonical approach: with present, with leaf with default = true
    individual draft by Juergen (expire) or WIKI
- how to delete stuff from a grouping
    no possible
    advice: plan in advance, so that we have the common part in the grouping, then use extend the grouping
- granularity of module:
    small or big set of functions: it depends
- naming convention
    globalIpPool: ugly
    convention: global-ip-local

Martin:
- diffserv:
    different vendors have different structure?
    common model or multiple model?
- grouping and granularity

Andy:
- reusing data types:
    grouping/typdef
    RFC 6991

AI: single place with all YANG models,
        published ones
        WG ones
- attributes
    don't want to have them change on the fly
    current YANG: any single leaf can change 10000/s
    "only set when created"
    Dean: should it be in the description?

Tom:
- creating new type that can reused
- the tree ouput inb





_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>
https://www.ietf.org/mailman/listinfo/yang-doctors<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=cgShsKHcMyDIU1PJsR-kHGnPVIreOenBGsQUE9VaLwM&e=>





_______________________________________________

yang-doctors mailing list

yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>

https://www.ietf.org/mailman/listinfo/yang-doctors<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=CwMD-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=Lc3YFWLlrL64R1JWzm0m4zIvMprKdcCon1FhyzDi3uE&s=cgShsKHcMyDIU1PJsR-kHGnPVIreOenBGsQUE9VaLwM&e=>