Subject: Re: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items.

From: Matt Mathis <[email-masked]>
Date: Mon, 1 Apr 2013 14:30:01 -0700

In my comments below, "abstain" generally means that I don't see
enough value in the work to be worth my time, but I see insignificant
harm in others supporting it.  Since there is a risk that such items
draw precious energy out of the working group as a whole, an abstain
vote should be counted as a weak no.

On Tue, Mar 26, 2013 at 1:12 AM, Brian Trammell <[email-masked]> wrote:
> (1) draft-morton-ippm-2330-update-01
> Mon Year - Submit draft of RFC 2330bis (Framework update)
>            to IESG as Proposed Standard
Yes 2330 needs work, and this is a good starting point/placeholder,
although I think this specific document has too narrow of scope.  Yes
I will review and contribute.

> (2) draft-morton-ippm-2679-bis-01
> Mon Year - Submit draft of RFC 2679bis (One-Way Delay update)
>            to IESG as Proposed Standard
Abstain

> (3) draft-morton-ippm-2680-bis-00
> Mon Year - Submit draft of RFC 2680bis (One-Way Loss update)
>            to IESG as Proposed Standard
Abstain

> (4) draft-morton-ippm-lmap-path-01
> Mon Year - Submit draft on reference path for measurement location
>            to IESG as Proposed Standard
Yes, I support this and will help.  Consider folding it into 2330bis.

> (5) draft-mathis-ippm-model-based-metrics-01
> Mon Year - Submit draft on model-based TCP bulk transfer capacity metrics
>            to IESG as Proposed Standard
Yes & Yes

> (6) draft-ko-ippm-streaming-performance-00
> Mon Year - Submit draft on model-based streaming performance metrics
>            to IESG as Proposed Standard
Abstain

> (7) draft-bi-ippm-ipsec-01
> Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard
Yes, we (other person singular) should do this.  No, I can't help.

> With respect to the following milestone, there are two drafts, which we would presume would be unified through the working group process; it's not necessary at this time to indicate which approach you support.
>
> (8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-independent-00
> Mon Year - Submit draft on metrics registry to IESG as Proposed Standard

I wonder if this would be a better fit for LMAP?   I think the root
problem here is certifying implementations and operational
interoperability, which are not areas where we have any experience.
IPPM has been about on the wire measurements and properties, not about
user interfaces, etc.
I would say no for an IPPM work item, but would support it under LMAP.

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat
privacy and security as matters of life and death, because for some
users, they are.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 01 Apr 2013 23:52:31 +0200

El 01/04/13 23:30, Matt Mathis escribió:
> interoperability,

mmm, this is not how i see this.
I mean, the goal here is to define a registry for metrics that are 
specified enough so it is practical to implement them.
Basically, if we intend to have a protocol that can instruct a 
measurement agent something like "run test number 5 with input 
parameters a,b and c" then test number 5 should be specified enough so 
that it is practical to implement it.
For exmaple, leaving an arbitraty P-type, probably in general is too 
generic to leave it open. OTOH, defining that the packet is a UDP packet 
with a variable lenght of padding (where the lentgh of the padding and 
the source and address ports are input parameters) seems like a more 
feasible approach.

So, i dont think certification of implementations is how i would phrase it.
It is certainly about interoperability, but i guess this is what the 
IETF is about.

I believe this belong to IPPM because i think expertise on the metrcis 
is critical. The idea is to define entries in the registry by narrowing 
down some of the input paramters of the metrcis that IPPM has already 
defined.

It probably could be done also in lmap, but it makes more sense to me in 
ippm, as the metrics the registry will cover have been defined here.

Regards, marcelo

>   which are not areas where we have any experience.
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 2 Apr 2013 20:21:34 +1300

hi, Marcelo, Matt, all

As I understand the work, it pretty clearly fits into the (expanded) IPPM charter, with an understanding that what's in the present draft will be elaborated within the working group. This is one of those things that will probably be discussed both on the IPPM and LMAP list, but I agree that expertise on the metrics will be critical in developing the registry; that indicates that it probably belongs in IPPM.

Alternately, if it turns out later that this registry is becoming something LMAP-specific, it could certainly be moved over to LMAP at some point in the future.

Best regards,

Brian

On 2 Apr 2013, at 10:52, marcelo bagnulo braun <[email-masked]> wrote:

> I mean, the goal here is to define a registry for metrics that are specified enough so it is practical to implement them.
> Basically, if we intend to have a protocol that can instruct a measurement agent something like "run test number 5 with input parameters a,b and c" then test number 5 should be specified enough so that it is practical to implement it.
> For exmaple, leaving an arbitraty P-type, probably in general is too generic to leave it open. OTOH, defining that the packet is a UDP packet with a variable lenght of padding (where the lentgh of the padding and the source and address ports are input parameters) seems like a more feasible approach.
> 
> It is certainly about interoperability, but i guess this is what the IETF is about.
> 
> I believe this belong to IPPM because i think expertise on the metrcis is critical. The idea is to define entries in the registry by narrowing down some of the input paramters of the metrcis that IPPM has already defined.
> 
> It probably could be done also in lmap, but it makes more sense to me in ippm, as the metrics the registry will cover have been defined here.
> 
> Regards, marcelo
> 
> 
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 3 Apr 2013 00:56:58 +0000

Hi Brian,

The revised charter mentions near the 2nd last paragraph -
"The WG also encourages work which improves the availability of information about the context in which measurements were taken."  ---> is this alluding to usecase document of TWAMP/OWAMP and some of the asociated metrics ( since the currents documents are not very clear)?  We discussed that during the charter discussion at IETF 86.

Also, at the charter discussion, we agreed on MIB definition for the measurement protocols. Not sure if it was captured in the meeting minutes. Looking at the charter I did not find coverage for it. Could this be clarified?

I have some comments on the list of documents below as you requested comments by April 3rd.
Please see in-line.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Trammell
Sent: Tuesday, March 26, 2013 1:13 AM
To: [email-masked]
Subject: [ippm] Consensus on new IPPM Charter; call for draft adoption as WG items.

Greetings, all,

Having applied comments in this thread to the charter, we've arrived at the draft charter text below this message.

I've seen on the order of a dozen comments supporting adoption of the charter, some with suggestions for improvement that have been applied to the below. Seeing no comments not supporting adoption, it appears that we have clear consensus for the adoption of the draft charter text. Many thanks to all for your comments!

The next step is to adopt drafts from those which have been presented at the IPPM meeting in Orlando and/or discussed to date on the list, and to determine the milestones for those drafts. 

For the following drafts and milestones, please indicate:

(a) whether you support the adoption of the draft as a working group item for the associated milestone, and
(b) whether you have reviewed the draft, and/or are willing to review it as a working group item

==> Yes on adoption. 

==> Yes on adoption. 

==> Yes on adoption. 

==> Yes on adoption. 

===>
This document's intended status is "experimental". I'd support it for wg document as experimental. More experience is needed to make it a std wg document.

===> This document is an INFORMATIONAL document. Not sure why it should be submitted as proposed standard. It has a lot of useful information. But I think it is premature yet to adopt as a wg draft and more time for discussion and understanding is needed.

===> Support adoption. More work is needed.

I'd like to try to evaluate consensus on adoption on each draft by next Wednesday, April 3, absent continuing discussion.

===> Would like to see more discussion on the merged document and working group review before
     they individually become wg documents.

Best regards,
-Samita

[Charter text follows]

IP Performance Metrics (ippm)
-----------------------------

 Charter

 Current Status: Active

 Chairs:
     Brian Trammell 
     Bill Cerveny
     
 Transport Area Directors:
     Martin Stiemerling
     Martin Stiemerling

 Transport Area Advisor:
     Martin Stiemerling

 Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/ippm
     Archive:            http://www.ietf.org/mail-archive/web/ippm

Description of Working Group:

The IP Performance Metrics (IPPM) Working Group develops and maintains standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services and applications. It also develops and maintains protocols for the measurement of these metrics. These metrics are designed such that they can be used by network operators, end users, or independent testing groups. Metrics developed by the IPPM WG are intended to provide unbiased quantitative performance measurements and not a value judgement.

The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. The working group will continue advancing these metrics along the standards track, using the guidelines stated in RFC 6576. To the extent possible, these metrics will be used as the basis for future work on metrics in the WG.

The WG will develop the minimum number of new metrics and models needed to more accurately quantitatively characterize the network path(s) under test and/or the performance of transport and application layer protocols on these path(s).
New metric definitions will state how the definition improves on an existing metric definition, or assesses a property of network performance not previously covered by a defined metric.

Additional methods will be defined for the composition and calibration of IPPM-defined metrics, as well as active, passive and hybrid measurement methods for these metrics. In addition, the WG encourages work which describes the applicability of metrics and measurement methods, especially to improve understanding of the tradeoffs involved among active, passive, and hybrid methods.

The WG may update its core framework RFC 2330 as necessary to accommodate these activities.

The WG has produced protocols for communication among test equipment to enable the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively).
These protocols will be advanced along the standards track. The WG will further develop and improve these protocols. The WG may develop new measurement protocols as necessary to support new metrics. New metric and protocol development will focus on the suitability of measurements for automation, in order to support large-scale measurement efforts.

Agreement about the definitions of metrics and methods of measurement enables accurate, reproducible, and equivalent results across different implementations. To this end, the WG will define and maintain a registry of metric definitions. The WG encourages work which assesses the comparability of measurements of IPPM metrics with metrics developed elsewhere. The WG also encourages work which improves the availability of information about the context in which measurements were taken.

The IPPM WG seeks cooperation with other appropriate standards bodies and forums to promote consistent approaches and metrics. Within the IETF process, IPPM metric definitions and measurement protocols will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersects with the requirement of these specific metrics. The WG will, on request, provide input to other IETF working groups on the use and implementation of these metrics.

Milestones:

Mon Year - Submit draft on access rate measurement protocol problem statement
           to IESG as Informational
Mon Year - Submit draft on RFC 2680 standards-track advancement testing
           to IESG as Informational

---

From: Matt Mathis <[email-masked]>
Date: Tue, 2 Apr 2013 18:35:24 -0700

I think "The WG also encourages work which improves the availability
of information about the context in which measurements were taken." is
alluding to metadata and related issues.   E.g.
draft-mathis-ippm-data-curation-00.txt

But this draft is about to expire.
Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

---

From: Brian Trammell <[email-masked]>
Date: Wed, 3 Apr 2013 14:42:37 +1300

Hi, Samita,

Thanks for your input! Comments and clarifications inline...

> "The WG also encourages work which improves the availability of information about the context in which measurements were taken."  ---> is this alluding to usecase document of TWAMP/OWAMP and some o…

This language is intended for metadata, i.e. as in the expiring data-curation draft, as well as the reference path draft.

TWAMP/OWAMP use cases are covered by the catch-all "...[t]he WG will further develop and improve these protocols."

> Also, at the charter discussion, we agreed on MIB definition for the measurement protocols. Not sure if it was captured in the meeting minutes. Looking at the charter I did not find coverage for it…

I consider this work to be covered, as well, under protocol development and improvement, especially with respect to applicability of automation.

<snip>

> This document's intended status is "experimental". I'd support it for wg document as experimental. More experience is needed to make it a std wg document.

Oops. Thank you for catching this; this was a copy-paste error. The proposed status would be experimental.

> ===> This document is an INFORMATIONAL document. Not sure why it should be submitted as proposed standard. It has a lot of useful information. But I think it is premature yet to adopt as a wg draft…

Again, oops. As above, this is a copy-paste error. We'd adopt as informational.

Many thanks, best regards,

Brian

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Wed, 3 Apr 2013 16:48:36 +0000

Dear Brian, all,

|(a) whether you support the adoption of the draft as a working group
|item for the associated milestone, and
|(b) whether you have reviewed the draft, and/or are willing to review it
|as a working group item

Here's my $0.02:

|(1) draft-morton-ippm-2330-update-01
|Mon Year - Submit draft of RFC 2330bis (Framework update)
|           to IESG as Proposed Standard

Yes to both (a) and (b), and could contribute text from a wireless/mobile network perspective.

|(2) draft-morton-ippm-2679-bis-01
|Mon Year - Submit draft of RFC 2679bis (One-Way Delay update)
|           to IESG as Proposed Standard
|
|(3) draft-morton-ippm-2680-bis-00
|Mon Year - Submit draft of RFC 2680bis (One-Way Loss update)
|           to IESG as Proposed Standard
|
|(4) draft-morton-ippm-lmap-path-01
|Mon Year - Submit draft on reference path for measurement location
|           to IESG as Proposed Standard

For (2)-(4), Yes to both (a) and (b)

|(5) draft-mathis-ippm-model-based-metrics-01
|Mon Year - Submit draft on model-based TCP bulk transfer capacity
|metrics

Yes to both (a) and (b), and could contribute text from a wireless/mobile network perspective as well.

|(6) draft-ko-ippm-streaming-performance-00
|Mon Year - Submit draft on model-based streaming performance metrics
|           to IESG as Proposed Standard

I think this is interesting and would support it as an _informational_ document, as Brian clarified. Although some more discussion and more aspects/considerations should be included in the draft, as I mentioned in the last meeting, I think this can easily be done as this becomes a WG item.

|(7) draft-bi-ippm-ipsec-01
|Mon Year - Submit draft on OWAMP / TWAMP Security to IESG as Proposed
|Standard
|

Yes to both (a) and (b), and as a co-author would be happy to see others from the WG joining this work.

|With respect to the following milestone, there are two drafts, which we
|would presume would be unified through the working group process; it's
|not necessary at this time to indicate which approach you support.
|
|(8) draft-bagnulo-ippm-new-registry-00, draft-bagnulo-ippm-new-registry-
|independent-00
|Mon Year - Submit draft on metrics registry to IESG as Proposed Standard

I think this would be quite useful to have, and therefore Yes to both (a) and (b)

Best regards,

Kostas

---

From: Brian Trammell <[email-masked]>
Date: Fri, 5 Apr 2013 09:59:41 +1300

Greetings, all,

Many thanks to those of you who have already replied on the adoption of drafts under the new IPPM charter. If you have further input, please send it to the list by the end of Friday 5 April (i.e., today or tomorrow, depending on your time zone); we'd like to put together a list of milestones shortly.

Many thanks, and best regards,

Brian (chair hat)

On 26 Mar 2013, at 21:12, Brian Trammell <[email-masked]> wrote:

> The IP Performance Metrics (IPPM) Working Group develops and maintains standard
> metrics that can be applied to the quality, performance, and reliability of
> Internet data delivery services and applications. It also develops and
> maintains protocols for the measurement of these metrics. These metrics are
> designed such that they can be used by network operators, end users, or
> independent testing groups. Metrics developed by the IPPM WG are intended to
> provide unbiased quantitative performance measurements and not a value
> judgement.
> 
> The IPPM WG has produced documents that define specific metrics and procedures
> for accurately measuring and documenting these metrics. The working group will
> continue advancing these metrics along the standards track, using the
> guidelines stated in RFC 6576. To the extent possible, these metrics will be
> used as the basis for future work on metrics in the WG.
> 
> The WG will develop the minimum number of new metrics and models needed to more
> accurately quantitatively characterize the network path(s) under test and/or
> the performance of transport and application layer protocols on these path(s).
> New metric definitions will state how the definition improves on an existing
> metric definition, or assesses a property of network performance not previously
> covered by a defined metric.
> 
> Additional methods will be defined for the composition and calibration of
> IPPM-defined metrics, as well as active, passive and hybrid measurement methods
> for these metrics. In addition, the WG encourages work which describes the
> applicability of metrics and measurement methods, especially to improve
> understanding of the tradeoffs involved among active, passive, and hybrid
> methods.
> 
> The WG has produced protocols for communication among test equipment to enable
> the measurement of the one- and two-way metrics (OWAMP and TWAMP respectively).
> These protocols will be advanced along the standards track. The WG will further
> develop and improve these protocols. The WG may develop new measurement
> protocols as necessary to support new metrics. New metric and protocol
> development will focus on the suitability of measurements for automation, in
> order to support large-scale measurement efforts.
> 
> Agreement about the definitions of metrics and methods of measurement enables
> accurate, reproducible, and equivalent results across different
> implementations. To this end, the WG will define and maintain a registry of
> metric definitions. The WG encourages work which assesses the comparability of
> measurements of IPPM metrics with metrics developed elsewhere. The WG also
> encourages work which improves the availability of information about the
> context in which measurements were taken.
> 
> The IPPM WG seeks cooperation with other appropriate standards bodies and
> forums to promote consistent approaches and metrics. Within the IETF process,
> IPPM metric definitions and measurement protocols will be subject to as
> rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol
> standards. The IPPM WG will interact with other areas of IETF activity whose
> scope intersects with the requirement of these specific metrics. The WG will,
> on request, provide input to other IETF working groups on the use and
> implementation of these metrics.
> 
> Milestones:
>

---

From: Brian Trammell <[email-masked]>
Date: Mon, 8 Apr 2013 21:29:28 +1200

Greetings, all,

Given the response to the consensus call for document adoption, here's where we see consensus on the next milestones for the IPPM working group:

Clear support for adoption, with pledges for reviews and contributions.

Mixed support for adoption, with at least one pledge for review and contribution.

Mixed support for adoption, with at least one pledge for review and contribution.

Clear support for adoption, with pledges for reviews and contributions, and a
suggestion that the WG may consider folding this into -2330-update.

         to IESG as Experimental

Clear support for adoption (with correction of intended status to
Experimental), with pledges for reviews and contributions.

Mixed support for adoption, with correction of intended status and 
indication that the document needs to mature a bit.

Clear support for adoption, with indication that the document needs some work
within the WG.

Mixed support for adoption, with indication that the document should be
discussed and developed further before adoption.

Given this, we propose that we adopt the following drafts as the next set of milestones:

draft-morton-ippm-2330-update
draft-morton-ippm-lmap-path
draft-mathis-ippm-model-based-metrics
draft-bi-ippm-ipsec

Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis may depend on 2330-update, they should be developed in parallel with it, and considered for adoption as it nears completion.

The remaining drafts are all clearly in scope for the new charter, so please continue developing them, with discussion on the list as necessary. Specifically, the new registry drafts should be unified into a single approach, and adopted following further development.

After consulting with the authors, we suggest the following milestones for existing WG drafts:

Jul 2013 - Submit draft on RFC 2680 standards-track advancement testing to IESG as Informational
Dec 2013 - Submit draft on access rate measurement protocol problem statement to IESG as Informational

I'd suggest the following milestones for the new drafts; authors, please respond if these are not realistic:

Dec 2013 - Submit draft updating the IPPM Framework (2330-update) to IESG as Proposed Standard
Dec 2013 - Submit draft on reference path for measurement location to IESG as Proposed Standard
Mar 2014 - Submit draft on model-based TCP bulk transfer capacity metrics to IESG as Experimental
Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed Standard

Please be prompt with any comments on this proposal; we'd like to hand the proposed charter and milestones up to our AD this week.

Best regards,

Brian and Bill

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Apr 2013 12:18:12 +0200

Hi,

I agree with most of this.
One comment about the metric registry work. I agree that the draft need 
more discussion and the WG is not ready for adopting it.

But wouldnt make sense to include a milestone about this in the charter 
even if we dont adopt a document at this stage?

Thanks, marcelo

---

From: Brian Trammell <[email-masked]>
Date: Mon, 8 Apr 2013 22:49:14 +1200

Hi, Marcelo,

Now that we have agreed charter text which will covers all the work we want to do now and that we think we will want to do over the next few years (the hard part), the intention is that we can quickly update milestones, with much less work, coincident with document adoptions as WG items. I suspect we could evaluate subsequent revisions of drafts fitting the charter text and update the milestones as often as once per meeting cycle, if the the individual and WG drafts progress quickly enough. Given that model, I'm not sure I see what the value is in placing a milestone on this charter without a document ready to cover it.

Best regards,

Brian

On 8 Apr 2013, at 22:18, marcelo bagnulo braun <[email-masked]> wrote:

> One comment about the metric registry work. I agree that the draft need more discussion and the WG is not ready for adopting it.
> 
> But wouldnt make sense to include a milestone about this in the charter even if we dont adopt a document at this stage?
> 
> Thanks, marcelo
> 
>

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Mon, 8 Apr 2013 10:01:02 -0400

Hi Brian, Marcelo, all,

IMO, there are a few areas where conscientious working group participants should contribute,
in addition to the natural preference to work on new proposals. These areas are part of 
the overhead of being a standards body. Liaison replies, specification maintenance, and
developing support specifications (registry) are not exciting and won't win the election, 
but they all require attention at some point. In our priorities for the future,
let's keep in mind that the IETF standards process is always on the list.

So, let's move ahead with the new WG drafts and also see what we can accomplish
across the board of proposals, as you've suggested.

regards,
Al

> Sent: Monday, April 08, 2013 6:49 AM
> To: marcelo bagnulo braun
> Cc: [email-masked]
> Subject: Re: [ippm] Consensus on draft adoption as WG items
> 
> Hi, Marcelo,
> 
> Now that we have agreed charter text which will covers all the work we
> want to do now and that we think we will want to do over the next few
> years (the hard part), the intention is that we can quickly update
> milestones, with much less work, coincident with document adoptions as WG
> items. I suspect we could evaluate subsequent revisions of drafts fitting
> the charter text and update the milestones as often as once per meeting
> cycle, if the the individual and WG drafts progress quickly enough. Given
> that model, I'm not sure I see what the value is in placing a milestone on
> this charter without a document ready to cover it.
> 
> Best regards,
> 
> Brian
> 
> >> Given the response to the consensus call for document adoption, here's
> where we see consensus on the next milestones for the IPPM working group:
> >>
> >>
> >> Given that draft-morton-ippm-2679-bis and draft-morton-ippm-2680-bis
> may depend on 2330-update, they should be developed in parallel with it,
> and considered for adoption as it nears completion.
> >>
> >> The remaining drafts are all clearly in scope for the new charter, so
> please continue developing them, with discussion on the list as necessary.
> Specifically, the new registry drafts should be unified into a single
> approach, and adopted following further development.
> >>
> >> I'd suggest the following milestones for the new drafts; authors,
> please respond if these are not realistic:
> >>
> >> Please be prompt with any comments on this proposal; we'd like to hand
> the proposed charter and milestones up to our AD this week.
> >>
> >>
> >> Best regards,
> >>
> >> Brian and Bill

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 08 Apr 2013 16:41:34 +0200

Hi,

I was not aware of the model, im my previous experience milestone 
updating is not so agile, but if this is how plan to run the wg, i am 
fine with yoour approach and i agree we can wait.

Regards, marcelo

---

From: Matt Mathis <[email-masked]>
Date: Mon, 8 Apr 2013 08:53:24 -0700

The agility of updating milestones is sensitive to the clarity of the
charter: changes that are clearly in scope don't require (significantly)
wider discussion.  If the scope is vague, or the item a stretch, others (WG
chairs defending their turf and/or the IESG) have to be involved in a
conversation....

A IESG approved, clear, up to date charter with placeholders for future
projects makes milestone adjustments easy.

Thanks,
--MM--

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Mon, Apr 8, 2013 at 7:41 AM, marcelo bagnulo braun <[email-masked]>wrote:

> Hi,
>
> I was not aware of the model, im my previous experience milestone updating
> is not so agile, but if this is how plan to run the wg, i am fine with
> yoour approach and i agree we can wait.
>
> Regards, marcelo
>
>
>> want to do now and that we think we will want to do over the next few years
>> (the hard part), the intention is that we can quickly update milestones,
>> with much less work, coincident with document adoptions as WG items. I
>> suspect we could evaluate subsequent revisions of drafts fitting the
>> charter text and update the milestones as often as once per meeting cycle,
>> if the the individual and WG drafts progress quickly enough. Given that
>> model, I'm not sure I see what the value is in placing a milestone on this
>> charter without a document ready to cover it.
>>
>> Best regards,
>>
>> Brian
>>
>>>> (1) draft-morton-ippm-2330-update-**01
>>>> (5) draft-mathis-ippm-model-based-**metrics-01
>>>> (6) draft-ko-ippm-streaming-**performance-00
>>>> (8) draft-bagnulo-ippm-new-**registry-00, draft-bagnulo-ippm-new-**
>>>> registry-independent-00
>>>> draft-mathis-ippm-model-based-**metrics
>>>> draft-bi-ippm-ipsec
>>>>
>>>> ______________________________**_________________
>>>> ippm mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/ippm<https://www.ietf.org/mailman/listinfo/ippm>
>>>>
>>>>  ______________________________**_________________
>>> ippm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/ippm<https://www.ietf.org/mailman/listinfo/ippm>
>>>
>>
>>
> ______________________________**_________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ippm<https://www.ietf.org/mailman/listinfo/ippm>
>

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Mon, 8 Apr 2013 22:06:39 +0000

Dear Brian, Bill, all,

|I'd suggest the following milestones for the new drafts; authors, please
|respond if these are not realistic:
|
<snip>

|Mar 2014 - Submit draft on OWAMP / TWAMP Security to IESG as Proposed
|Standard

I think this is a realistic, although a tad pessimistic target. I'm ok with it and I'd like to call for anyone who's interested in this line of work to email me as we will be preparing a much improved version for Berlin. Comments, suggestions, nits, and text most welcome.

Best regards,

Kostas

---

From: Brian Trammell <[email-masked]>
Date: Tue, 9 Apr 2013 10:17:36 +1200

hi, Kostas,

We could certainly move this up to Dec '13, if you like. 

Cheers,

Brian

---

From: Konstantinos Pentikousis <[email-masked]>
Date: Wed, 10 Apr 2013 23:29:56 +0000

Hi Brian, all

|We could certainly move this up to Dec '13, if you like.

Unless someone else objects, it sounds good to me. 

Best regards,

Kostas

---

From: Brian Trammell <[email-masked]>
Date: Thu, 11 Apr 2013 11:50:46 +1200

Hi, Kostas,

Sounds good; will change the milestone.

Thanks,

Brian