Re: [ippm] IPPM WG Status and Agenda for IETF 95 Buenos Aires

[Brian Trammell <[e-mail]>]

hi Joachim,

You raise good points.

On the other hand, we have limited face to face agenda time to spend on individual drafts which have not generated much (any?) discussion on the mailing list since the previous face-to-face meeting. When we put the agenda together, we let the mailing list be our guide, as discussed in Yokohama.

On the third hand, there was discussion of this approach in the final processing on the bis drafts, so that kind of counts.

(I'd suggest, personally, that "2330-stdform-typep" is not a very useful draft name for letting people who know they care about IPv6 measurements that this document is important to them. I guess there are two 3's in the document name, and 3 + 3 = 6...?)

As I understand it, what's happened since Yokohama that you'd like face-to-face time to discuss is "document ready, call for adoption"? There seems to be WG support for that, so we can certainly wedge ten minutes in for that between model-based-metrics and the hybrid/coloring cluster.

Cheers,

Brian (chair hat)


> On 11 Mar 2016, at 17:14, Joachim Fabini <[e-mail]> wrote:
> 
> Brian, IPPM,
> 
> Thumbs up, excellent work and RFC-publishing performance. This brings me
> to a somewhat related topic: fixing of legacy shortcomings seems to not
> be that thrilling and gains little attention/priority in ippm. The
> process of finding new ippm topics may benefit from some
> priority-elevation scheme. In particular, we must make sure to advance
> work that a) ippm has committed to as part of RFC approval processes
> and/or b) approved RFCs depend on.
> 
> (co-author hat off) Specifically I'm concerned about the 2330-update for
> IPv6 and IP options not even being on the agenda. During the GenArt
> review of RFC 7679 and 7680 the IESG asked ippm to fix the missing IPv6
> support in RFC2330. When reading
> https://www.ietf.org/mail-archive/web/ietf-announce/current/msg14489.html it
> is my understanding that these two essential RFCs have passed the
> standardization process only because ippm proposed/committed to fix the
> RFC2330 shortcomings wrt IPv6 in a separate document. This is
> draft-morton-ippm-2330-stdform-typep, which has not been adopted as WG
> item and not even on the agenda for IETF-95.
> 
> It's a fundamental question of the ippm being credible. The same
> question about IPv6 support will be asked again by the IESG latest when
> the next IPv6-related ippm draft is in their queue. The active-passive
> RFC now is in AUTH48 and references
> draft-morton-ippm-2330-stdform-typep, PDM-options may be next, so we
> have at least two RFCs and two almost-RFCs that reference and badly need
> the IPv6 update.
> 
>> From my perspective the ippm work can and must prioritize new topics
> that are in the attention and focus of ippm participants. Still, the
> fixing of such substantial legacy issues like IPv6 should have at least
> the same level of priority. Ippm must prioritize and complete the
> homework it has committed to while adopting earlier RFCs to stay
> credible vs. the IESG. And it is my feeling that this needs to be
> reflected somehow by ippm processes and priorities.
> 
> Any opinions?
> 
> thanks
> Joachim
> 
> 
> 
> On 11.03.2016 14:00, Brian Trammell wrote:
>> Greetings, all,
>> 
>> First, let us congratulate the IPPM working group on its excellent productivity in finally-published-RFC terms: we've seen five(!) documents published since Yokohama:
>> 
>> - RFC 7679 (was draft-ietf-ippm-2679-bis)
>> A One-Way Delay Metric for IP Performance Metrics (IPPM)
>> - RFC 7680 (was draft-ietf-ippm-2680-bis)
>> A One-Way Loss Metric for IP Performance Metrics (IPPM)
>> - RFC 7717 (was draft-ietf-ippm-ipsec)
>> IKEv2-Derived Shared Secret Key for the One-Way Active Measurement
>> Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
>> - RFC 7718 (was draft-ietf-ippm-owamp-registry)
>> Registries for the One-Way Active Measurement Protocol (OWAMP)
>> - RFC 7750 (was draft-ietf-ippm-type-p-monitor)
>> Differentiated Service Code Point and Explicit Congestion
>> Notification Monitoring in the Two-Way Active Measurement
>> Protocol (TWAMP)
>> 
>> In addition:
>> 
>> - RFC-to-be 7799 (draft-ietf-ippm-active-passive-06) just entered AUTH48
>> - draft-ietf-ippm-checksum-trailer-06 has been approved and is in queue
>> 
>> Well done, IPPM!
>> 
>> 
>> With that, it's time to consider what to work on next, in order to plan our agenda for the meeting in Buenos Aires. We have a couple of active Working Group drafts:
>> 
>> - draft-ietf-ippm-6man-pdm-option, in WGLC until next Friday.
>> - draft-ietf-ippm-metric-registry, to be revised on WGLC comments.
>> - draft-ietf-ippm-model-based-metrics, which needs work before a second WGLC.
>> 
>> We'll want time on the agenda for all three of these.
>> 
>> We've also adopted two new WG documents, for which we expect to see dratf-ietf-ippm- revisions before Monday 21 March:
>> 
>> - draft-cmzrjp-ippm-twamp-yang
>> - draft-morton-ippm-initial-registry
>> 
>> We'll want time on the agenda for these, too.
>> 
>> Beyond that, we've reviewed discussion on the mailing list to see where the working group's energy seems to be for additional documents. First, we have seen a lot of discussion on what we call the "hybrid/coloring cluster", so I think we should have a discussion about approaches here, how they fit together, and what if anything we should consider adopting in this space:
>> 
>> - draft-tempia-ippm-p3m
>> - draft-chen-ippm-coloring-based-ipfpm-framework
>> - draft-fioccola-ippm-rfc6812-alt-mark-ext
>> 
>> We've already talked to Giuseppe Fioccola about these, and would like to propose a single presentation about all three followed by a long discussion slot.
>> 
>> There's also been some discussion on draft-mirsky-ippm-time-format, and it seems like this one might be close enough to make an adoption call for too.
>> 
>> All other drafts: As discussed in Yokohama, we'd like to reserve time for work that's actually already being discussed on the list, so at the end of the agenda we'll have time for discussion of new work without any substantial discussion so far. These will be organized as 5 minute lightning talks, and allocated FCFS in two queues, with completely new drafts having priority over ones that have already been presented.
>> 
>> We're tentatively scheduled for a 2.5 hour slot on Monday morning, but there is discussion about moving us back to a 2 hour slot on Friday, so we'd propose the following agenda, with the last slot being either 15 or 45 minutes long:
>> 
>> 10:00: Note well, intro, status, agenda bash (chairs, 10m)
>> 10:10: draft-ietf-ippm-metric-registry
>>      WGLC discussion completion, as req'd (10m)
>> 10:20: draft-ietf-ippm-6man-pdm-option
>>      WGLC discussion completion (N. Elkins, 15m)
>> 10:35: draft-ietf-ippm-model-based-metrics
>>      new revision / second WGLC kickoff (M. Mathis, 10m)
>> 10:45: Coloring/Hybrid Approach Presentation and Discussion (TBD, 45m)
>>      draft-tempia-ippm-p3m
>>      draft-chen-ippm-coloring-based-ipfpm-framework
>>      draft-fioccola-ippm-rfc6812-alt-mark-ext
>>      Discussion; decision on call to adopt?
>> 11:30: draft-mirsky-ippm-time-format (G. Mirsky, 15m)
>>      Discussion: decision on call to adopt?
>> 11:45: Lightning talks for new work: two requests received so far:
>>      draft-bailmir-ippm-twamp-dscp-ctrl-mon-00 (G. Mirsky)
>>      draft-mirsky-ippm-twamp-light-yang-02 (G. Mirsky)
>> 
>> Authors: please let us know if you have any corrections here. Those with new work to present: please let us know if you'd like a lightning talk slot.
>> 
>> Cheers,
>> 
>> Brian and Bill (chair hats)
>> 
>> 
>> 
>> _______________________________________________
>> ippm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ippm
>> 
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm