Subject: [babel] Babel YANG deliverable

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 12 Jun 2018 07:39:46 +0000

I think we need to have a list discussion about this Babel YANG deliverable.
It is clear that none of the people directly engaged in this WG have the expertise or competency to create a Babel YANG model. We also have no desire or intent to acquire this expertise. The learning curve is steep and time-consuming. 
The requirement to create a Babel YANG model is purely about creating the model for the sake of having the model. There exists no user community demand for this model, at this time.
There exists a user community who does want Babel. There is a homenet (unmanaged network) use case which has rfc6126bis as a dependency. There is interest from other users with networks that do not require management through a management protocol, or who are using other non-IETF solutions. There is some interest from at least one employee of an ISP (me) who has committed to creating the information model and a BBF TR-181 data model (for use with BBF TR-069 and TR-369). Lack of publication of rfc6126bis is standing in the way of these use cases being fully realized. [Side note: Because of these use cases, netconf and YANG MUST NOT be mandatory to implement, even if the YANG model is created.]

However, the lack of a YANG model is being used as an excuse to prevent publication of rfc6126bis -- even though none of the user communities actively interested in Babel care anything about YANG or netconf. The Babel user community is being held hostage by YANG advocates.
So we're at an impasse.

I see the following as possible ways forward, and provide an assessment of their feasibility and outcomes.
1. Kill the rfc6126bis effort now. Very feasible. Outcome: All work on Babel leaves IETF and either dies or goes elsewhere.
2. Put rfc6126bis on hold until a YANG model happens. This is the default "do nothing" choice. Obviously, very feasible. Outcome: Since the YANG model shows no sign of happening, it is highly likely we would lose the interest of the draft authors, and it would be effectively the same as killing the draft. If we're going to kill the draft, then I prefer the decision be a conscious one (see option 1). 
3. One of the people currently engaged in Babel puts in the time and effort to learn YANG and create a model. Highly unlikely. Outcome: Extensive delay (due to learning curve and bad attitude), which is likely to devolve into option 2.
4. Someone who is competent in YANG volunteers to quickly create the YANG model. Feasibility is unknown, but no-one has stepped forward, yet. Outcome: If done quickly, it might be successful; otherwise, it will devolve into option 2.
5. The draft is sent on for IESG review without there being a YANG model. This can be with** or without a management section that explains the current lack of a YANG model. Feasible (depends on chair willingness). Outcome: Success is uncertain since we've been told there is a policy that says routing protocols must have a YANG model just for the sake of having a YANG model? Not sure what the policy really is, since I can't find where it's stated.

Option 2 is default (do nothing, and kill the draft by lack of action). Option 3 should be tossed -- it's not going to happen. Options 1, 4, or 5 are up to the chairs. [The WG participants know of no-one for option 4.]
Donald, Russ, -- it's in your hands. Do we consciously kill it, do you find someone ASAP to do the YANG model, do you move it forward and fight the fight, or do we do nothing and allow it to die? 

My preference would be to fight the fight -- send the draft up for review. This "there shall be a YANG model" policy (it would be great to get a pointer to this policy so we can read it and determine who approved this policy and any other details of this policy) is inappropriate and untenable for Babel. 

Barbara

** Possible Management section text:
Babel may be used in a variety of scenarios. As one of these scenarios is the unmanaged home network case, no management capability will be required in order to be compliant with this specification. A Babel implementation profile for the home network use case is defined in [homenet-babel-profile].

Where there is interest in defining other Babel usages, specifying an implementation profile for those usages is recommended. Such a profile would need to identify any needed management capabilities and protocols, and would need to ensure that data models necessary for interoperability exist. The information model [babel-information-model] has been defined as a basis for creating interoperable data models for various management interfaces and protocols (e.g., YANG, a graphical user interface, Broadband Forum TR-069 or TR-369).

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 12 Jun 2018 12:55:01 +0200

> My preference would be to fight the fight -- send the draft up for review. This "there shall be a YANG model" policy (it would be great to get a pointer to this policy so we can read it and determi…

I agree with your assessment, and would prefer option 4 (if feasible) or
5. I think it would be a shame if the IETF bureaucracy ends up choking
Babel :/

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 12 Jun 2018 14:42:33 +0200

> My preference would be to fight the fight -- send the draft up for
> review. This "there shall be a YANG model" policy (it would be great to
> get a pointer to this policy so we can read it and determine who approved
> this policy and any other details of this policy) is inappropriate and
> untenable for Babel.

I fully agree.

-- Juliusz

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 12 Jun 2018 15:01:39 +0200

Hello WG,

there is no "policy". There is a WG charter which says:

To be consistent with the ongoing effort to use YANG data modules in the
Routing Area, a Babel YANG data model to support management of home
gateway routers is required as part of moving Babel to Proposed
Standard.

regards,
martin

Le 2018-06-12 à 14:42, Juliusz Chroboczek a écrit :
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 12 Jun 2018 09:11:42 -0400

Hi Barbara and Toke,

>> The requirement to create a Babel YANG model is purely about creating the model for the sake of having the model. There exists no user community demand for this model, at this time.

I do not view the requirement in the Babel Charter for a YANG model
the same way you do.
     Although no analogy is exact, let me give a quick analogy to
security. Time and again, protocols have come to the IETF with
advocates who insist the security isn't needed, that the protocol will
only be used in limited environments, that the protocol will never be
used across the general Internet, that there is no community demand
for the protocol to be securable, etc. And those advocate have almost
always been proven wrong -- in many cases resulting in painful and
sometimes not entirely successful attempts to retrofit security. So,
there is an actual general IETF process requirement for Security
Considerations sections in standards track documents.
     An analogy to management is not exact, management is easier to
retrofit, Operational Considerations is not a general IETF process
required section in standard track documents, etc. Nevertheless, I
think that management oriented people would view with suspicion the
claim that Babel will never need to be manageable, that there will
never be a case where a management station that is, say, monitoring
information inside a variety of protocols on a network would also like
to monitor Babel. So, there is a requirement for a YANG model in the
Babel Charter but, as long as there is clear progress towards that, it
is not clear that its completion needs to be a blocking consideration
for rfc6126bis.

>> 4. Someone who is competent in YANG volunteers to quickly create the YANG model. Feasibility is unknown, but no-one has stepped forward, yet. Outcome: If done quickly, it might be successful; othe…

I will send a message to the Operations Area Directors and Directorate
seeking a volunteer to work on a YANG model. I probably should have
done this earlier.

>> 5. The draft is sent on for IESG review without there being a YANG model. This can be with** or without a management section that explains the current lack of a YANG model. Feasible (depends on ch…

The Chairs can request publication based on WG consensus but it is
then up to our Area Director to review the document and, if he so
chooses, initiate the IETF Last Call and put it on the IESG agenda.

>> My preference would be to fight the fight -- send the draft up for review. This "there shall be a YANG model" policy (it would be great to get a pointer to this policy so we can read it and determ…

I did ask our AD and he indicated that he would be extremely reluctant
to forward the draft to the IESG, due to the requirement in the Babel
Charter for a YANG model, unless such a model had been at least
started.

> 5. I think it would be a shame if the IETF bureaucracy ends up choking

Thanks,
Donald

PS: The Babel Charter is here https://datatracker.ietf.org/wg/babel/about/
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 12 Jun 2018 14:20:13 +0000

Hi Martin,

> On Jun 12, 2018, at 10:02 PM, Martin Vigoureux <[email-masked]> wrote:
> 
> Hello WG,
> 

There appears to be considerable variation across IETF as to what is done about charter items where no-one steps up to do do them. Other cases I’ve seen, the AD has simply acknowledged drafts do not write themselves. A charter item that no-one volunteers to write is one that will not be written. This is the only case I’ve seen where a standalone draft is held hostage unless other chartered items are done. 

Are you volunteering to create the Babel yang model? That would be great, if you are. Hopefully you’re not demanding that others do work you find so unimportant that you aren’t willing to spend your own time on it. 
Barbara 

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_babel&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=KUl39WBERUssMBc4NgENSyN8yJFmYTlXPKHyiR76N8E&s=4kbvBR_jYRCAjBMnjFcr8fZD0RMBfKNmvx0CM9Dcvq8&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_babel&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=KUl39WBERUssMBc4NgENSyN8yJFmYTlXPKHyiR76N8E&s=4kbvBR_jYRCAjBMnjFcr8fZD0RMBfKNmvx0CM9Dcvq8&e=

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 13 Jun 2018 09:03:09 +0000

Hi Donald,
Response inline.
Barbara
-------------------
> >> It is clear that none of the people directly engaged in this WG have the
> expertise or competency to create a Babel YANG model. We also have no
> desire or intent to acquire this expertise. The learning curve is steep and
> time-consuming.
> >> The requirement to create a Babel YANG model is purely about creating
> the model for the sake of having the model. There exists no user community
> demand for this model, at this time.
> 
> I do not view the requirement in the Babel Charter for a YANG model the
> same way you do.
>      Although no analogy is exact, let me give a quick analogy to security. Time
> and again, protocols have come to the IETF with advocates who insist the
> security isn't needed, that the protocol will only be used in limited
> environments, that the protocol will never be used across the general
> Internet, that there is no community demand for the protocol to be
> securable, etc. And those advocate have almost always been proven wrong -
> - in many cases resulting in painful and sometimes not entirely successful
> attempts to retrofit security. So, there is an actual general IETF process
> requirement for Security Considerations sections in standards track
> documents.
>      An analogy to management is not exact, management is easier to retrofit,
> Operational Considerations is not a general IETF process required section in
> standard track documents, etc. Nevertheless, I think that management
> oriented people would view with suspicion the claim that Babel will never
> need to be manageable, that there will never be a case where a
> management station that is, say, monitoring information inside a variety of
> protocols on a network would also like to monitor Babel. 

Just to be clear, I never suggested that Babel will never need to be manageable. I'm putting real effort into babel-information-model because I do see the need for manageability in some usages. The points I've made are:
 - there must be no mandatory-to-implement management protocol so lightweight implementations can exist for unmanaged environments (and, also, management interfaces are a major source of security vulnerabilities; management interfaces that aren't present have no vulnerabilities and can't be used to compromise a device)
 - babel-information-model is progressing
 - I'll be creating a TR-181 data model, so Babel can be managed through TR-069/TR-369; this is the management protocol I'm interested in using because my employer currently uses it to managed millions of Wi-Fi CE routers and has no plans of moving to netconf or restconf for CE router management
 - I have no intention of learning YANG, and no other regular WG participant appears interested in learning YANG either; YANG isn't easy -- it takes time to learn and more time to learn well; so the authors of all the babel WG drafts are not in a position to promise a YANG model
 - as an additional note (responding to your sentence about monitoring), I think NetJSON (netjson.org) would be a much better approach for the type of monitoring you describe; it would be pretty easy to create a NetJSON extension for Babel (given the information model)

The language requiring a YANG model was placed in the charter because Benoit insisted on it and said Babel will not be made into an IETF Proposed Standard without a YANG model**. It was not something the WG wanted, but is something that was forced on us. Apparently this requirement will render meaningless all the work done on Babel unless someone can be found to do a YANG model. Years of work and effort is depending on the kindness of strangers to produce something that is being required for no other reason than some people not involved with Babel had a desire (and the power) to require it. 
**https://www.ietf.org/mail-archive/web/babel/current/msg00378.html

> So, there is a
> requirement for a YANG model in the Babel Charter but, as long as there is
> clear progress towards that, it is not clear that its completion needs to be a
> blocking consideration for rfc6126bis.

That's somewhat good news. But the WG participants are powerless to make this happen -- short of expending massive effort to learn YANG and produce the DM ourselves -- which is an unrealistic expectation in order to create something that is just a check-the-box requirement with no user community expressing interest or demand.

> >> There exists a user community who does want Babel. There is a homenet
> >> (unmanaged network) use case which has rfc6126bis as a dependency.
> >> There is interest from other users with networks that do not require
> >> management through a management protocol, or who are using other
> >> non-IETF solutions. There is some interest from at least one employee
> >> of an ISP (me) who has committed to creating the information model
> >> and a BBF TR-181 data model (for use with BBF TR-069 and TR-369).
> >> Lack of publication of rfc6126bis is standing in the way of these use
> >> cases being fully realized. [Side note: Because of these use cases,
> >> netconf and YANG MUST NOT be mandatory to implement, even if the
> YANG
> >> model is created.]
> >>
> >> However, the lack of a YANG model is being used as an excuse to prevent
> publication of rfc6126bis -- even though none of the user communities
> actively interested in Babel care anything about YANG or netconf. The Babel
> user community is being held hostage by YANG advocates.
> >> So we're at an impasse.
> >>
> >> 1. Kill the rfc6126bis effort now. Very feasible. Outcome: All work on Babel
> leaves IETF and either dies or goes elsewhere.
> >> 2. Put rfc6126bis on hold until a YANG model happens. This is the default
> "do nothing" choice. Obviously, very feasible. Outcome: Since the YANG
> model shows no sign of happening, it is highly likely we would lose the
> interest of the draft authors, and it would be effectively the same as killing
> the draft. If we're going to kill the draft, then I prefer the decision be a
> conscious one (see option 1).
> >> 3. One of the people currently engaged in Babel puts in the time and
> effort to learn YANG and create a model. Highly unlikely. Outcome: Extensive
> delay (due to learning curve and bad attitude), which is likely to devolve into
> option 2.
> >> 4. Someone who is competent in YANG volunteers to quickly create the
> YANG model. Feasibility is unknown, but no-one has stepped forward, yet.
> Outcome: If done quickly, it might be successful; otherwise, it will devolve
> into option 2.
> 
> seeking a volunteer to work on a YANG model. I probably should have done
> this earlier.

Thank you. I sincerely hope you find someone. Please let them know we've already identified the data elements and really just need someone who knows YANG modeling. Identifying data elements can be difficult for someone who knows nothing of the thing being modeled -- just like creating a YANG model is difficult for those not versed in YANG. These are distinct competencies.
 
> >> 5. The draft is sent on for IESG review without there being a YANG model.
> This can be with** or without a management section that explains the
> current lack of a YANG model. Feasible (depends on chair willingness).
> Outcome: Success is uncertain since we've been told there is a policy that
> says routing protocols must have a YANG model just for the sake of having a
> YANG model? Not sure what the policy really is, since I can't find where it's
> stated.
> 
> The Chairs can request publication based on WG consensus but it is then up
> to our Area Director to review the document and, if he so chooses, initiate
> the IETF Last Call and put it on the IESG agenda.
> 
> >> Option 2 is default (do nothing, and kill the draft by lack of
> >> action). Option 3 should be tossed -- it's not going to happen. Options 1, 4,
> or 5 are up to the chairs. [The WG participants know of no-one for option 4.]
> Donald, Russ, -- it's in your hands. Do we consciously kill it, do you find
> someone ASAP to do the YANG model, do you move it forward and fight the
> fight, or do we do nothing and allow it to die?
> >>
> >> My preference would be to fight the fight -- send the draft up for review.
> This "there shall be a YANG model" policy (it would be great to get a pointer
> to this policy so we can read it and determine who approved this policy and
> any other details of this policy) is inappropriate and untenable for Babel.
> 
> I did ask our AD and he indicated that he would be extremely reluctant to
> forward the draft to the IESG, due to the requirement in the Babel Charter
> for a YANG model, unless such a model had been at least started.
> 
> > I agree with your assessment, and would prefer option 4 (if feasible)
> > or 5. I think it would be a shame if the IETF bureaucracy ends up
> > choking Babel :/

Thanks Donald. I hope so, too.
 
> Thanks,
> Donald
> 
> PS: The Babel Charter is here
> https://datatracker.ietf.org/wg/babel/about
>  155 Beaver Street, Milford, MA 01757 USA  [email-masked]

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 13 Jun 2018 12:15:34 +0300

On 13 Jun 2018, at 12.03, STARK, BARBARA H <[email-masked]> wrote:
> That's somewhat good news. But the WG participants are powerless to make this happen — short of expending massive effort to learn YANG and produce the DM ourselves -- which is an unrealistic expectation in order to create something that is just a check-the-box requirement with no user community expressing interest or demand.

I would like to get rid of the charter item.

That said, if we cannot get rid of it it, I can write (lousy first draft) YANG model if it really helps once the management model doc is considered ready. I have done some MIBs and PIBs in the past so writing YANG model sounds like novel challenge, although not super interesting one (nor relevant in the Babel context) so I would prefer not to.

Cheers,

-Markus

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 14 Jun 2018 17:25:15 -0400

Hi Markus,

> I would like to get rid of the charter item.

Charters can certainly be changed but it requires approval of the IESG.

> That said, if we cannot get rid of it it, I can write (lousy first draft) YANG model if it really helps once the management model doc is considered ready. I have done some MIBs and PIBs in the past…

Thanks for the offer. That may turn out to be very useful.

Donald

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 15 Jun 2018 17:15:21 -0400

Hi Barbara,

> Barbara

My apologies if, in attempting to simplify my argument, I implies you
were saying the Babel will never need management.

>  - I'll be creating a TR-181 data model, so Babel can be managed through TR-069/TR-369; this is the management protocol I'm interested in using because my employer currently uses it to managed mill…

That is all good.

> **https://www.ietf.org/mail-archive/web/babel/current/msg00378.html

Well, we will see what happen on the Charter requirements front.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Denis Ovsienko <[email-masked]>
Date: Sat, 16 Jun 2018 19:51:22 +0100

Thank you for raising this point Barbara. This matter is very important for this working group, I have been thinking along those lines for a while and would like to add something in addition to what has already been discussed on this thread so far. It seems to me, it concerns all other WG members too.

 ---- On Tue, 12 Jun 2018 08:39:46 +0100 STARK, BARBARA H <[email-masked]> wrote ---- 
 > However, the lack of a YANG model is being used as an excuse to prevent publication of rfc6126bis -- even though none of the user communities actively interested in Babel care anything about YANG…

I agree there is a problem, but to make my point clear let me state it in a different way. Today is June 2018 and the milestones for the WG are the same as at the WG formation in June 2016:

Aug 2017 	IESG Submission of Babel Applicability draft (Informational)
Jul 2017 	IESG Submission of Babel Management draft (Proposed Standard)
Jul 2017 	IESG Submission of RFC6126bis and potentially companion security mechanisms draft (Proposed Standard)
Oct 2016 	WG adoption of Babel Management (Info Model & YANG Model) draft
Jul 2016 	WG adoption of RFC6126bis
Jul 2016 	WG adoption of Babel Applicability draft
draft-chroboczek-babel-applicability

YANG has been both in the charter (no YANG == no Proposed Standard) and in the milestones from the very beginning. Same as security. Same as Standards Track quality level 6126bis. All of which are at various stages of incompleteness (to be clear, 6126bis still has some of the issues I had raised in December 2016).

To make it here we (the working group) had accepted the charter and the milestones, then spent the whole time initially allocated for the work, missed all of the 2017 milestones and took one more year of overtime to prove we are not delivering anytime soon.

Hence the current situation is not an accident, we have thoroughly painted ourselves into a corner and it would be wrong to put the blame elsewhere (YANG costs and demand for it, bureaucracy, evil managers etc). This is how I see the real problem, YANG is just its proper detail.

 > My preference would be to fight the fight -- send the draft up for review. This "there shall be a YANG model" policy (it would be great to get a pointer to this policy so we can read it and determ…

Spelling those options is a good step towards a resolution -- among other things it reminds people the project default is a failure, not a success. Let's try to look one more step ahead. Even if we make it around the YANG requirement for now, how are we going to make it around the security requirement? Just rush the documents no matter what? It would smell and shooting it down would be right.

We need to clarify the details of where we are, and then we need to make the right decision (to avoid riding a dead horse or discarding good work). Let me build on top of your plan and propose the following, which also covers the YANG aspect:

Step 1. Study the charter and write down all meaningful work items.
Step 2. Place a call in the working group asking people to confirm their presence, availability and which work items they are willing to work on and how exactly (discuss, write, proof-read, find issues, fix issues, implement) and how many working hours per week they can contribute.
Step 3. If the working group fails to confirm its existence, conclude it without deliverables.
Step 4. If the working group exists but does not have the resource to implement the charter in the first place, conclude it without deliverables.
Step 5. Confirm new realistic dates for the milestones with the people that are willing to work on respective items.
Step 6. Admit the current default to IESG and ask to extend the credit line by adjusting the milestones. If declined, conclude w/o deliverables.
Step 7. (if all good so far) Resume the work as planned and demand status updates every week.

Does it look any better?

-- 
    Denis Ovsienko