Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

[Juergen Schoenwaelder]

On Tue, Dec 15, 2015 at 04:48:21PM +, Kent Watsen wrote:
> 
> The minutes for IETF 95 show that there was in-room support for adopting 
> draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that 
> this decision would be confirmed on the mailing list, which I am doing now.
> 
> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and 
> correspondingly add this to the WG charter as a milestone?  Please comment by 
> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge 
> whether or not there is consensus to move forward with the document.
> 

This I-D contains some Ethernet specific definitions. Are we going to
define Ethernet specific things in the IETF or is IEEE ready to take
over data models for 'their' interfaces? In other words, what exactly
is the scope of this work?

And (likely depending on the answer to the first question), is it
meaningful to produce an interface extension module or is it better to
simply carefully revise the model we already have?

If we add something to the work of this WG, what will be realistic
milestones and how do we make sure we stay focused? Is there a need
for some prioritization?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

[Gert Grammel]

+1

From: netmod > on 
behalf of Kent Watsen >
Date: Tuesday 15 December 2015 17:48
To: "netmod@ietf.org" 
>
Subject: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang 
as NETMOD WG draft


The minutes for IETF 95 show that there was in-room support for adopting 
draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that 
this decision would be confirmed on the mailing list, which I am doing now.

Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and 
correspondingly add this to the WG charter as a milestone?  Please comment by 
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge 
whether or not there is consensus to move forward with the document.

Thanks,
Kent


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

[Robert Wilton]

Hi Juergen,

Hopefully I can answer your questions inline ...

On 15/12/2015 17:08, Juergen Schoenwaelder wrote:

On Tue, Dec 15, 2015 at 04:48:21PM +, Kent Watsen wrote:

The minutes for IETF 95 show that there was in-room support for adopting 
draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that 
this decision would be confirmed on the mailing list, which I am doing now.

Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and 
correspondingly add this to the WG charter as a milestone?  Please comment by 
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge 
whether or not there is consensus to move forward with the document.


This I-D contains some Ethernet specific definitions. Are we going to
define Ethernet specific things in the IETF or is IEEE ready to take
over data models for 'their' interfaces? In other words, what exactly
is the scope of this work?
There is an informal IEEE 802.3 Ethernet design team (that has the 
backing of the 802.3 WG chair, and that I'm part of) that is working on 
YANG models for Ethernet interfaces.  The intention is that this 
informal design team will become a formal IEEE 802.3 WG design team once 
it traverses the necessary IEEE 802.3 WG processes (i.e. likely to be 
sometime later on next year).  The exact scope of this project hasn't 
been defined yet, and can't formally be defined until the IEEE 802.3 WG 
agrees that we can do it, but my expectation is that the long term goal 
will surely be to define YANG models to cover all of the 802.3 work, 
although there may be various interim goals along the way.


In the interim, whilst we wait for the formal WG to be started, the 
Ethernet design team are working on Ethernet models in Github 
(https://github.com/8023YangDesignTeam/EthernetYang).


How does that overlap with draft-wilton-netmod-intf-ext-yang?  The basic 
answer is that it shouldn't and arguably doesn't.  The only thing that 
it defines related to Ethernet is three leaves related to MAC address 
(configured value, operational value, and burnt-in value) that are 
applicable to all interfaces that use Ethernet framing.  There are 
various types of interface that use Ethernet framing but are not 
Ethernet interfaces, nor necessarily defined in IEEE.  I.e. I'm thinking 
of interfaces where a VPLS instances terminates to a layer 3 forwarding 
instances, or where a pseudo-wire is terminated directly to a layer 3 
forwarding instance.  But at the end of the day, if this part of the 
draft needs to be defined as part of the IEEE 802.3 space then I think 
that would be fine too - I don't think that it should really be an 
issue, and I think that we can involve the necessary folks to ensure 
that this bit gets to the right home.




And (likely depending on the answer to the first question), is it
meaningful to produce an interface extension module or is it better to
simply carefully revise the model we already have?

I'm not sure that I know the answer to this one.

Some of the extra configuration that is being defined by this module is 
more router specific, whereas I see the base interfaces model as 
potentially having a wider applicability across devices.




If we add something to the work of this WG, what will be realistic
milestones and how do we make sure we stay focused? Is there a need
for some prioritization?
I believe that at least some of this configuration is required to 
configure networks in a reliable way, so I would have thought that we 
need to progress these models at the same time as the routing protocol 
models.


On a related note, any VPLS or Pseudowire models defined by IETF are 
basically going to be undeployable without 
draft-wilton-netmod-intf-vlan-yang-01 (or an equivalent) being defined 
because there will be no configuration mechanism to bind the 
classification of traffic from a particular VLAN to a VPLS instance.  
Note that I don't see that any models coming out of IEEE 802.1Q are 
likely to help here.  This point was also raised in PALS at IETF 94 by 
some of the folks working on, or reviewing, those models.


Thanks,
Rob




/js



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft

[Robert Wilton]

Hi Tom,

On 15/12/2015 17:10, Nadeau Thomas wrote:

On Dec 15, 2015:12:08 PM, at 12:08 PM, Juergen Schoenwaelder 
 wrote:

On Tue, Dec 15, 2015 at 04:48:21PM +, Kent Watsen wrote:

The minutes for IETF 95 show that there was in-room support for adopting 
draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that 
this decision would be confirmed on the mailing list, which I am doing now.

Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and 
correspondingly add this to the WG charter as a milestone?  Please comment by 
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge 
whether or not there is consensus to move forward with the document.


This I-D contains some Ethernet specific definitions. Are we going to
define Ethernet specific things in the IETF or is IEEE ready to take
over data models for 'their' interfaces? In other words, what exactly
is the scope of this work?

The IEEE has officially started working on Ethernet models on
the public github repo here, so I suggest taking a look at that for any
overlaps.

https://github.com/YangModels/yang/tree/master/experimental/ieee

The latest (work in progress) models are actually at:
https://github.com/8023YangDesignTeam/EthernetYang/tree/master/experimental/ieee/802.3

This repo is a direct fork of YangModels so that we can iterate the IEEE 
802.3 models at a faster pace, with an intention that we periodically 
fold the IEEE model updates back into YangModels when they have been 
reviewed and reached some level of stability and consensus in the design 
team.


Thanks,
Rob




—Tom


And (likely depending on the answer to the first question), is it
meaningful to produce an interface extension module or is it better to
simply carefully revise the model we already have?

If we add something to the work of this WG, what will be realistic
milestones and how do we make sure we stay focused? Is there a need
for some prioritization?

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Milestones changed for netmod WG

[IETF Secretariat]

Changed milestone "Submit YANG 1.1 to the IESG", set due date to
January 2016 from October 2015.

URL: https://datatracker.ietf.org/wg/netmod/charter/

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Broadband Forum intention of using ietf-entity YANG module

[Romascanu, Dan (Dan)]

So, let's do it. Tom, or one of the other chairs - you need to run this. 

Regards,

Dan


> -Original Message-
> From: Benoit Claise [mailto:bcla...@cisco.com]
> Sent: Monday, December 14, 2015 9:18 PM
> To: Nadeau Thomas; Romascanu, Dan (Dan)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG
> module
> 
> 
> > I personally don’t see anything that prevents this.
> Same opinion here.
> 
> Regards, Benoit
> >
> > —Tom
> >
> >> On Dec 13, 2015:6:56 AM, at 6:56 AM, Romascanu, Dan (Dan)
>  wrote:
> >>
> >> Concerning the 'draft status' - anything prevents the wg from running a
> short consensus call and adding this item to the netmod milestones?
> >>
> >> Regards,
> >>
> >> Dan
> >>
> >>
> >>> -Original Message-
> >>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Nadeau
> >>> Thomas
> >>> Sent: Friday, December 11, 2015 4:27 PM
> >>> To: William Lupton
> >>> Cc: netmod@ietf.org
> >>> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity
> >>> YANG module
> >>>
> >>>
> >>>   Dependance on 1.1 should not be an issue as that is almost ready to
> >>> be approved. You should be building your model to comply with the 1.1
> rules.
> >>>
> >>>   —Tom
> >>>
> >>>
>  On Dec 11, 2015:8:00 AM, at 8:00 AM, William Lupton
> >>>  wrote:
>  All,
> 
>  The Broadband Forum would like to use the ietf-entity YANG module
> >>> (currently draft-entitydt-netmod-entity) for equipment management
> >>> but we are a bit concerned about its draft status and its dependence on
> YANG 1.1.
> >>> Any advice or reassurance?
>  Thanks,
>  William
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> >
> man_listinfo_netmod=BQIDaQ=BFpWQw8bsuKpl1SgiZH64Q=I4dzGx
> R31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA=9jKcR2EbKD3lb73tciJMJAk0J6
> 2dQAbsU_4R85zluXs=eBlkOZe4c5IXMoz_2YJnIKglubNBDQmS0Ej03Al8meI
> =

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Guidance on list vs. container of list

[Ladislav Lhotka]

Andy Bierman  writes:

> Hi,
>
> Use of NP-containers are subjective, based on how you
> want to organize your data.  The extra layer of containment
> may be a waste, but it sometimes has a purpose
>
>   - 2 or more sibling lists with lots of entries can be mixed in JSON,
> so putting each list in its container prevents that.

No, in JSON all list entries are always nicely packed in an array. It is
the XML encoding where entries of two lists can be interleaved.

For example, if we have

list foo { ... }
list bar { ... }

then JSON encoding is always

"foo": [...foo entries...]
"bar": [...bar entries...]

whereas in XML we can have, e.g.

...
...
...
...
...

Lada

>  - There is no standard way to 'delete-all' in NETCONF or RESTCONF
> but a 'replace' on the parent container can be used for this purpose.
> (container of list or leaf-list)
>  - container servers as a conceptual 'root' for external augments
>
> Andy
>
>
> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps  wrote:
>
>>
>> Some models seem to place a single list of things inside a container also
>> named after the items in the list, e.g.,
>>
>> +--ro modulename
>>   +--rw ribs
>>  +--rw rib* [name] +--rw name
>> I don't see the purpose of these containers. It seems to me that one can
>> model and query the exact same data without the outer container. That is,
>>
>> +--ro modulename
>>   +--rw rib* [name]  +--rw name
>> Is there something useful about these containers that I've missed, as it's
>> a fairly common pattern in the models I've been looking at.   Example
>> comparisons below..
>> Thanks,
>> Chris.
>>
>>
>> w/ container:
>>foo
>>bar ...  
>> 
>> w/o container:
>>
>>  foo   
>> bar   ...
>> Likewise if you want to fetch all ribs you can either way:
>>
>>
>>  
>>
>>  
>>
>> or
>>
>>
>>  
>>
>>  
>>
>> Or a particular rib
>>
>>
>>  
>>  foo
>>  
>>  
>>
>> or
>>
>>
>>foo
>>
>>  
>>
>> Using xpath:
>>
>>/modulename/ribs/rib[name='foo']
>> or
>>
>>/modulename/rib[name='foo']
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-01.txt

[Kent Watsen]

[As a contributor]


This update reflects the four on-list email threads since -00 was published as 
follows:


1. Regarding Balazs, Gert, and Robert’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14243.html

The term “non-derived” state in Req #4 has been removed and new term 
“Operational State” has been added.  The new requirement #3 is a little 
different than what’s in draft-openconfig-netmod-opstate, but I believe that it 
is what’s intended (no pun intended, doh!).  No change made clarifying long 
running operations like backup, as this requirements draft, when referring to 
“asynchronous", regards configuration operations.   Also no change made to add 
a new requirement for a YANG annotation for config nodes that are known to have 
potentially different intented-config value.

Git diffs: 
https://github.com/netmod-wg/opstate-reqs/commit/6bc82d24e35337cb2229fb6338f21af2bf106647
https://github.com/netmod-wg/opstate-reqs/commit/3dabc4fa905c4d3037f808dbc8f18584d3e613d5



2. Regarding Jason and Gert’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14342.html

I have not done anything about this yet, but it seems that something might need 
to be done.  Personally, I don’t see how Rollback on Error could be allowed to 
rollback the intended config set via an asynchronous commit (e.g., after  
has been sent).  My thinking is that the server should send  if the 
client requests that combination.  FWIW, I’m not troubled by 'hybrid' or 
cheating-synchronous implementations, as in my view, they don’t advertise 
support for applied configurations or for synchronous commits.



3. Regarding Jason and Randy’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14344.html

The old 2-A was removed since it’s a duplicate to 4-C, and then the old 2 was 
removed since it’s covered in the new Operational State term.  The old #5 was 
also removed to eliminate cruft from the draft.  Then I fixed Appendix B to 
point to new section numbers.

Git diffs: 
https://github.com/netmod-wg/opstate-reqs/commit/02ef5fedd4293024dab70514884e9661b9c86285
https://github.com/netmod-wg/opstate-reqs/commit/4a06744157dada4707a457ec06a17b048719ae0b
  



4. Regarding Jason and Gert’s thread here: 
https://www.ietf.org/mail-archive/web/netmod/current/msg14343.html

No changes made here because I don’t think this hybrid case needs to be 
defined.   In my view, a device either advertises support for synch or asynch 
or both or none (default).  For the first three cases, the behavior is 
explicitly defined.  For the last case, the behavior remains same as today 
(undefined), which is needed for backwards compatibility.



Thanks,
Kent








On 12/15/15, 4:47 PM, "netmod on behalf of internet-dra...@ietf.org" 
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the NETCONF Data Modeling Language Working Group 
> of the IETF.
>
>Title   : NETMOD Operational State Requirements
>Authors : Kent Watsen
>  Thomas Nadeau
>   Filename: draft-ietf-netmod-opstate-reqs-01.txt
>   Pages   : 8
>   Date: 2015-12-15
>
>Abstract:
>   This document defines requirements for servers enabling better
>   visibility and control over the server's operational state.  To
>   achieve this end, this document also defines terminology describing a
>   conceptual model enabling the requirements to be expressed.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-01
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-01
>
>
>Please note that it may take a couple of minutes from the time of submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] FW: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

[Ersue, Mehmet (Nokia - DE/Munich)]

FYI and attention.

Please provide your comments to NETCONF WG maillist.

Mehmet

From: Ersue, Mehmet (Nokia - DE/Munich)
Sent: Tuesday, December 15, 2015 9:59 PM
To: netc...@ietf.org
Cc: 'c...@ietf.org' ; 'i...@ietf.org' ; 
'6...@ietf.org' <6...@ietf.org>; '6ti...@ietf.org' <6ti...@ietf.org>
Subject: WG Last Call for draft-ietf-netconf-restconf-09, 
draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03

Dear NETCONF WG,

we hereby issue a WG Last Call for the drafts below:

http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt
http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt
http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt

Please review and send your comments to the NETCONF WG mailing list by January 
22, 2015 EOB PT.

The drafts on RESTCONF, YANG patch and YANG library are planned to publish as 
standard track documents.

As RESTCONF is a major protocol we seek a detailed and thorough review within 
NETCONF WG but also by the related WGs before publishing.
Therefore the WGLC is planned to finalize on January 22th (covering the holiday 
time in between) and APP, INT and RTG area ADs will be informed as well as 
Core, I2RS, 6lo, and 6tisch WGs are invited to review.

Please take your time to review the documents and send your comments to the 
NETCONF maillist by the deadline.
Please state on NETCONF maillist also explicitly, whether you have 
read/reviewed and whether you support the publication.
Furthermore please indicate if you plan to implement or have already 
implementations for RESTCONF and its supplementary drafts.

Thank you for your review and kind help getting RESTCONF specifications stable.

Best Regards,
Mehmet and Mahesh

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] operational state: next step

[Benoit Claise]

Dear all:

Background: the operational state is a blocking factor for the 
publication of the YANG models. For example, I've been told that the 
ISIS and OSPF models are ready, pending resolution on the operational state.


Let me try to clarify the situation and the next steps.

During the NETMOD WG meeting in Yokohama, Kent, as a chair, did a hum 
related to draft-ietf-netmod-opstate-reqs-00 

As explained during the previous operational state-related interim 
meetings, we wanted to extract the requirements.
Kent carefully asked: "humm if in you are in favor of the definitions of 
the requirements", meaning: have we correctly documented the requirements?
draft-ietf-netmod-opstate-reqs-01 
 will 
be published soon, with no changes to the requirements scope, but only 
clarifying text and editorial changes.

Once published, a WGLC will follow, with hopefully a quick publication.

Now, what is the next step regarding the solution?
As mentioned during the NETMOD meeting in Japan, there are currently 3 
proposals:
1. openconfig draft-openconfig-netmod-opstate-01 

2. based on the data stores draft-kwatsen-netmod-opstate-00 

3. based on the metadata draft-wilton-netmod-opstate-yang-01 



During the NETMOD WG meeting, Kent asked the sense of the room on which 
solution the community favored. There was an advantage for solution 2.

However, we want to make that the WG to make an informed decision.

Kent and I have searching for independent people who could analyze the 
different solutions, and provide the pros/cons of each solutions. Note 
that some of this has already been done (Rob Wilton's presentation in 
Yokohama, YANG Model Coordination Group email to the list, etc.)
Lou Berger and Acee Lindem have agreed to help with this, with a 
tentative date of Jan 15 for an initial analysis.
They will start collecting the arguments. Please direct emails to both 
of them (lber...@labn.net, a...@cisco.com). Note that for discussions, 
the WG mailing list is more appropriate.


This process should ease the solution selection.

Regards, Benoit












___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft

[Ladislav Lhotka]

> On 15 Dec 2015, at 13:34, Nadeau Thomas  wrote:
> 
> 
>   NETMOD:
> 
>   The Broadband Forum and the members of the design team who worked on the
> IETF Entity module have asked that the working group considerthe ietf-entity 
> YANG module
> (currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ 
> which is
> still in individual draft status) as a working group item.
> 
>   Should we move to adopt draft-entitydt-netmod-entity as a WG item and 
> correspondingly add this to the WG charter as a milestone?  Please comment by
> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will 
> gauge whether or not there is consensus to move forward with the document.

I would strongly prefer to finish the existing items first, or at least the 
critical ones on which other work depends. Adding more items would mean that 
both old and new items receive less attention on the average. We already have 
at most one or two reviews per WGLC, and this is IMO insufficient.

Lada

> 
>   —Tom
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft

[Nadeau Thomas]

NETMOD:

The Broadband Forum and the members of the design team who worked on the
IETF Entity module have asked that the working group considerthe ietf-entity 
YANG module
(currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which 
is
still in individual draft status) as a working group item.

Should we move to adopt draft-entitydt-netmod-entity as a WG item and 
correspondingly add this to the WG charter as a milestone?  Please comment by
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will 
gauge whether or not there is consensus to move forward with the document.

—Tom

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod