[Tsvwg] IETF 62 Proceedings

Transport Area WG (tsvwg)

Monday, March 7 at 1530-1730
=============================

CHAIRS:	Allison Mankin <mankin@psg.com> 
        Jon Peterson   <jon.peterson@neustar.biz>

Matt Zekauskas acted as scribe and produced these minutes.
Thank you to Matt for the usual excellent reporting.

A prize to the first person who finds the message about
Paris hidden in the minutes below (by this co-chair).

AGENDA
  Charter Discussion (chairs)
  Quickstart Update (Sally Floyd) (5 mins)
   draft-amit-quick-start-04.txt
  RSVP over MPLS-TE/DS-TE (Bruce Davie) (10 mins)
    draft-lefaucheur-rsvp-dste-01.txt
  RSVP IPSec (Bruce Davie) (10 mins)
    draft-lefaucheur-rsvp-ipsec-00.txt
  SCTP Chunk Authentication and Threats (Michael Tuexen) (20 mins)
    draft-tuexen-sctp-auth-chunk-03.txt
    draft-stewart-tsvwg-sctpthreat-02.txt
  SCTP Implementer's Guide (Randall Stewart) (10 mins)
    draft-ietf-tsvwg-sctpimpguide-13.txt
  TCP MIB (Matt Mathis) (10 mins)
    draft-ietf-tsvwg-tcp-mib-extension-06.txt
  Real-time Congestion Notification (Jozef Babiarz) (10 mins)
    draft-babiarz-tsvwg-rtecn-03.txt
  Diffserv Service Class (Kwok Ho Chan) (10 mins)
    draft-ietf-tsvwg-diffserv-service-classes-00.txt
  Diffserv Service Class Aggregation (Kwok Ho Chan) (10 mins)
    draft-chan-tsvwg-diffserv-class-aggr-01.txt
  MLPP Update (Fred Baker/James Polk) (15 mins)
    draft-ietf-tsvwg-mlpp-that-works-00.txt
    draft-ietf-tsvwg-mlef-concerns-00.txt
    draft-ietf-tsvwg-rsvp-bw-reduction-00.txt
    draft-baker-tsvwg-vpn-signaled-preemption.02.txt

Quickstart Update (Sally Floyd)

Sally quickly reviewed Quickstart.  Quickstart IP option, requested
rate & TTL in SYN.  Routers may decrement request, and decrement
RTT if they understand.  SYNACK has RTT measurement and rate.  The
sender knows if all routers approve of the rate request.  There were
three main changes: the addition of a citation (discussion of router
algorithms), and a discussion of misbehaving middleboxes, and a section
on attacks on quickstart.

The citation is for a paper that evaluates a whole range of router algorithms,
from a minimum algorithm, to "extreme Quickstart", as well as a discussion
of how to size your bandwidth request at the start.

The attacks on Quickstart include attacking a router by bombarding it
with many packets with Quickstart requests (router can rate-limit);
Attack Quickstart itself by sending many requests that are not used
(again, the router must have a mechanism to limit requests); won't
hurt folks that don't want to use Quickstart.

If have a misbehaving middlebox, something that rewrites the IP TTL,
it will interfere with Quickstart (you can't tell if all routers
agree to the request).  There's no good answer to this one, it's
just noted in the draft.

Sally asked for feedback, and thinks it can be WGLC as experimental.
There were a couple of "ship it"s from the audience.  Jon said that
if no other feedback, will issue WGLC.

Allison said that they would like to see a couple of reviews from
the WG during WGLC on the mailing list.  Please contribute to
the value of the WGLC.

RSVP over MPLS-TE/DS-TE (Francois LeFaucheur) (10 mins)

The key change to the draft is a closer alignment with the LSP hierarchy
draft in the MPLS WG, which we agreed to do at the last meeting.

They requested feedback from MPLS WG. They got some feedback, but
at this stage, mostly suggestion for clarifications, nothing major.

An appendix was added for informational purposes.  A use case, how
the aggregation solution can fit together with a VOIP architecture.

The authors want to have accepted as a WG document; they feel it is
pretty stable now.

Jon asked for opinions.  Fred Baker and James Polk both said they thought
it should be a WG document.

Jon asked for a hum.
In favor of adopting: <major>
opposed:  <fewer>
Jon declared a consensus to adopt this document as a working group item.

Francois asked what were the concerns of those opposed.  Joe Touch
said that given silence of the room, individual submission seems in
order instead of a working group submission.  It's hard to say the
document came out of the WG, if there is no support.

Jon felt that there was substantial enough response to the hum that
it should be a WG item.  Any other opinions?

Joe commented that the apathy is deafening.

Allison proposed making a review group for RSVP.  TSVWG is a big catch-all
group, and so there can be a majority that doesn't care.  However, we
don't want to do a lot of work in an ad-hoc manner.  RSVP also has some
legacy issues, and Allison isn't comfortable spinning up a WG for this.

In the use of this review group, we can do better than the
not long enough face-to-face meeting sessions and times.
Presentations have been more devoted to discussion of
apathy than necessarily getting at the needed comment and
review so one hopes that a review group will elicit the
in depth consideration that is sought, while also 
sending onto the mailing list the public results in summary,
very promptly.  If this is useful, we might choose to create
in addition review groups for other topics, for instance for the
next up SCTP implementation guide.   Rsvps for rsvp group a moi...

People that are interested in working on RSVP should send a message to
the chairs.  There are a lot of RSVP workers around, some from NSIS.
This is not the best environment for active discussion, and we need
to improve.  So identify yourself in person over the next few
days or by email to the chairs.  The chairs will name an RSVP review
group of the active RSVP people, and get you activated.

Melinda Shore said that she wasn't apathetic; wasn't sure what to say except
"uh huh".  She thinks this work should be done.  Why?  To get through IESG,
has to go through WGLC.  There were calls of "not trues" from audience.

Joe wanted to know if there were any standards here, or was this document
informational?  He thought Allison's point was well taken; get a group
of people, and show that there is energy.  if so, then we can make a
decision about it being a working group document.  If no one reads
it except the authors, and there is no one to review the document
it shouldn't be here.

Tom Phelan said that he was not apathetic, not an author, and has
given lots of feedback to the authors.  Like Melinda, he didn't know
what to say except uhhuh.   

Francois noted that many others outside group have read the document
and commented on it.

Allison noted that there has been discussion both in past meetings and 
on the mailing list.  There are a lot of different topics in the group,
and an a RSVP discussion group is one way to move forward; she didn't think
there was a big problem.

RSVP IPSec (Francois LeFaucheur) (10 mins)

See slides.  Looking for aggregation solutions for RSVP, in the context
of IPSEC VPNs.  Hide and aggregate reservations on IPSEC tunnels, given
a core cloud that supports diffserv.

We want end-to-end RSVP reservations.  These must be hidden in core inside
IPsec tunnels.  But once you hide them, to support right e2e reservation,
need to reserve resource for aggregate traffic carried over the IPsec tunnels.

They thought problem was solved with existing RFCs - 2207 & 3175.  Looking
harder, that is not the case.  2207 is RSVP extensions for IPSec flows, but
it doesn't address aggregation.  3175 describes aggregation of RSVP.
However, it doesn't support IPSec between aggregator and deaggregator.
This draft: do both at same time.

Francois showed a picture, and a new packet format that has both bits of
information necessary. (See slides.)

The remaining open items:

* Add text delineating the responsibilities of aggregators & deaggregators.
  There are no specific issues, there is only some explanation needed.

* Add text about how to handle dynamic updates of security associations.  There
  may be an elegant solution: change the SPI to renew the association.  Give
  a mechanism to do it without deallocating and reallocating resources.
  Right now there is a discussion in the middle of the security section,
  and it needs to be moved.

This is new work, the authors would like feedback.  They would also like
to progress the work, hopefully here.

Allison asked if the authors had ever viewed the RSVP security analysis 
document from the NSIS group.  They should review it, and look at the
security piece.  2207 was done a while ago, and it's security review
might not be good enough.

Allison asked for the issues to be put onto the mailing list, and get
discussion going.

SCTP Chunk Authentication and Threats (Michael Tuexen) (20 mins)

The origin of document is a paper by T. Aura P. Nikander and G Camarillo
analyzing SCTP from protocol point of view, and looking at implementations.

Given that paper, we changed some things in the protocol, and listed these
threads in the ID, and added some other possible attacks.  Michael
then went through the threats at high level.

* Address camping or stealing.  Attacker guesses port number the victim will
  use next, and the victim must be multihomed.

  Path verification procedure in the implementation guide will prevent,
  and random port number selection makes it harder.

* Association hijacking.  Attacker must take over IP addresses.  Gets a
  VTAGs in cookie according to the original RFC 2960.
  Implementer's guide now requires what is in cookie are random numbers,
  not real tags, so vtags still protect against blind attacker.

* Association hijacking #2.  If application doesn't pay attention to restart,
  it doesn't realize endpoint may have changed.

  Pay attention to notifications.

* Bombing attack (1).  Trick server into sending packets to a victim.
  Only works if victim doesn't understand SCTP.  (If it did, it will
  send an ABORT.)  Server isn't paying attention to ICMP.  Attacker
  is also spoofing acknowledgements.

  The implementer's guide now says how to handle ICMP messages.
  If you get acks for data you have never sent, abort the association.
  Finally, do the path verification procedure to make sure the IP
  address is correct.

* Bombing II.  Send INIT give address of victim.  Get cookie that
  you send to endpoint.  Now the path verification mechanism is itself
  used as an attack.

  Have a low number of heartbeats that send at any time.  Want a high number
  for preventing attacks, but here want to limit.  The Implementer's guide
  says to limit the hartbeats to a "maxburst" parameter.

* Association redirection.  Same info in two different places in the
  packet... but some implementations only use the common header.  Can
  get receiver of the packet into an unstable state.  The implementer's
  guide says to drop the packet if the numbers don't match.

In summary, some attacks are not possible if you implement new procedures.
Some can be limited in time  by tuning appropriate parameters.
The authors are interested in if someone has more attacks or ideas... such that
we can list and analyze.  They are not interested in attacks against 
implementations (bugs) all protocol related.  any questions...

Jon asked if Gonzalo (who has written a lot on SCTP) thinks it is good.  He
gave it a thumbs up :)

Next Michael turned to the chunk authentication draft.

An SCTP extension on dynamic IP (LIP) has been stable for 2 years,  but 
not progressed due to security concerns.  This draft is the missing
security part.

With LIP one can change the address of an association.  This draft
provides a mechanism to ensure that chunks have been sent from an
endpoint that you think they came from.  At the beginning of the
SCTP association, exchange some material so can verify.  This does
not address man-in-the-middle attacks from the beginning of the
connection (but that is true without LIP too).  LIP will be required
to use this extension.  (See slides.)

Michael asked if we can we adopt this draft.  It is needed to progress
the other document.  There were no comments.

Jon asked for a hum, in favor of adoption as an official working group
document.
  <moderate>
opposed?
  <none>

Jon declares consensus (within room) to adopt.

SCTP Implementer's Guide (Randall Stewart) (10 mins)

There are two outstanding issues.  First, one that is just
on the implementer's list: PPID field, and text change for byte order.
There was lots of discussion, and we have a wording proposal.
Second, Armando and Randy (Stewart) were supposed to put in a note
regarding Karn's algorithm and RTT.  Doing that now.

After both of these go in it's ready for WGLC.  It is an informational
document.  Original idea with Scott Bradner, is that it's a way forward
to get a 2960bis.  Start up a bis once this gets into the RFC Editor's
queue.

We'd like to set up some RFC2960bis ground rules.  It's up to the ADs,
but what we'd prefer, is that when we open up the bis (after the implementer's
guide is in the RFC Editor's queue), only changes in the implementer's
guide are applied to 2960.  E.g.: wording, missed references to
adler-32 checksum.  But no field day on let's add "X".
At end result would be obsolete 2960 and 3309 (the checksum
change), and the new draft would cycle back at Proposed.
We would move it forward after a couple of more interops (but
not until the implementer's guide is in the RFC Editor's queue).

Jon felt that, speaking personally, it was a well thought out way
to go forward.  Randy said he had lived through three WGLC and
three IESG LC, and he doesn't want to do it again.

Jon said that if there are any outstanding issues, get them to Randy
quickly.

TCP ESTATS MIB (Matt Mathis) (10 mins)

Matt reviewed the motivation for the MIB.

TCP already measures lots of stuff, and knows where bottlenecks are.
We added explicit instrumentation on what causes TCP to stop sending data
controls to support useful workarounds.  The big motivation is a
hard end-to-end diagnostic problem.  With TCP, symptoms scale with
RTT.  Tests in local paths pass, move to longer paths and they can fail.
This leads to false logic and lots of "buck passing".
The ESTATS MIB would let you rescale properties of short path to longer path.
(See slides for details.)

The latest revision is 06.  We haven't changed details of objects,
but did change the structure of the MIB.  There are three sets
of required variables:
 * state vars
 * performance instrumentation
 * first tier diagnostic instrumentation

There are also three sets of optional variables (focus on where problems are).
 * path (loss, reordering, dup, etc)
 * stack (impact and state of control algs)  e.g. for cwnd validation
 * app (is app stalling or tcp?)

And a little table of writeable controls
 * limit cwnd and limit rwind: can do instead of starving tcp for buffer space.
     (starving: interferes with recovery alg, retrans, and app that doesn't
      have stable perf (eg disk seeks causing dry spells)
 * ssthresh: for slow-start.  like limited sstart.

The TCP roadmap was helpful in this rewrite.

The big open tech issue:  there have been two Industrial implementers
looking at the MIB.  They have commented that there is too
much required, that may make it unimplemented in practice.
It's easy to juggle variables between tables.

There are also SMI representation issues.  We need help - the duration
object has proven problematic.  Want high precision for short flows.
MIB uses 0 based counters.  All counters start at O; can always look
at stats,  but then need duration object, which could be around for
weeks and months.  Need more than 32 bits of microseconds, anyway.
We also want to delta on duration, so compute rates.  That means no
time-of-day numbers in duration... because of discontinuities in clock
adjustments.

Allison: do you have an SNMP expert?  Should we ask for volunteers here?
Dan Romascanu volunteers.

In addition, big worry is if we have overlooked something obvious.
65 page MIB, and description is terse. Allison mentions that Dan Romascanu
has experience writing for extension in the future.

Fred Baker noted that he doesn't know anything about mibs, but if you have
a 65 page MIB, and descriptions are terse, this causes concern.  If I can
think of algorithm that can be described, and want... can mail in object.
Find myself wondering how many objects are specific to one implementation
or another, and not general.

Matt said they are pretty careful about that.  My background is BSD, and
this was done with Linux, so we believe it can be done at least twice.
As much as possible, objects are described in terms of standards (RFCs)
or TCP state vars.

Fred said that older TCPs had SRTT... more recent ones keep mean RTT
and variance in RTT. There are differences in way mean and variance
are calculated. Start high and average down, or start at initial RTT
of SYN/ACK, and end up with different things.  He's concerned.  How
standardize something like that?

The RTO calculation is on standards track, the MIB refers to that RFC. 
Ones that do something different are not compliant.

Matt is getting tired of this project; he will get more implementer's
experience, and get MIB doctor review, and hopes to have WGLC sometime
this summer.

Allison thought that we need MIB advice right now.  We've go a volunteer
to help with MIB formalisms;  do that in parallel with additional 
implementers and researchers.  There is a formal thing called
"MIB doctor review", which happens after WGLC; a second round.
So, take Dan's advice now, and go through a round of MIB formalism
first.

There were no other comments.

Real-time Congestion Notification (Jozef Babiarz) (10 mins)

Jozef started with a quick status update.  Sally is reviewing.
The semantics have been changed to align with 3168.  Added
a token bucket example, but it is an example; vendors are
free to use whatever they want for marking.  A description
of ECN marking behavior has been added.  A description of
mis-marking or cheating detection was added.

Jozef then compared 3168 semantics to what is proposed in
this draft.  (See slides.)  Two levels of congestion versus
1 level in 3168.  Use a real-time measurement technique to
detect congestion, versus AQM in 3168.

The next steps include cleaning up the text so that ECN semantics
are uniformly described; describe how ECN capable and non-ECN
capable endpoints interact; address how real-time inelastic
ECN-capable flow will react when it encounters a non-diffserv
router that supports 3168.

Looking for feedback and comments.

David Black volunteered to be a reviewer.  This draft is related to
trouble he's making in NSIS.  NSIS has draft that is proposing to
signal and react to congestion.  He thinks the use cases are RT,
but it's not clear.  ECN is a candidate mechanism for what they want to do,
and this may be related.  The draft is the RMD draft in NSIS.  Look
for the congestion signaling support in it.  Second Sally's comment:
figuring  out how this works when you have just 3168 in a router
is crucial.

Sally followed up, and said she needed to get back to an old chore,
writing an ID for requirements for alternate semantics to ECN.
There have been a number of proposals.
Think that the requirements are one of
(1) only deployable in closed environment (and not safe for general use)
(2) provide some mechanism that makes sure that traffic that requires
    alternate ECN semantics only encounters routers that support semantics
    (perhaps something like Quickstart)
(3) if traffic happens to encounter older router 3168... that the end node
    response is TCP-friendly.

Colin Perkins noted that a companion draft was mentioned that tried to
define an RTP payload format for ECN.  Will that go to AVT, or discuss here.

Jozef was not planning to bring the draft forward at this time; he wants to
"socialize it" and decide.  If there is interest, let's talk offline.
Colin mentioned that he was AVT co-chair.  He wanted to make sure that
it was reviewed by people that understood RTP as well as the TSV
community.

Brian Carpenter, as the guardian of the "diffserv flame", said that
way the draft is written it is not immediately apparent that it is
intimately associated with diffserv; but the draft only makes sense
in a diffserv context.  The presumption is that EF DS is being used
for this traffic.  That's part of the mechanism for knowing that it is
not regular ECN.  However, it could also could be a new PHB
(association of a diffserv codepoint with the new ECN behavior).  The
discussion of that issue should be in this draft, and if you can run
this simultaneously with EF PHB and no ECN.  It gets complicated needs
a discussion.  Also realize that we mucked around with transport
philosophy in DS... the TOS byte doesn't exist.  If David becomes a
reviewer, he would find that.

Gorry Fairhust didn't quite get a strong case for 2 levels, which
seems to be main point.  Is there a use case?  Jozef said that the
companion draft describes how to use it for admission control.
There are a bunch of uses:  admission control, calls with high precedence,
preemption, ... and we felt that 2 levels would address.   Perhaps
we need text to say how someone would use this if they only 
want one level.

Fred Baker asked if Jozef had followed a comment related to this
that he made on the mailing list.  Jozef said that he got part,
had a partial response, and wanted to talk. Fred said that he
was wondering how to use this in a world with different people
having different policies.  It gives us a measurement, but what
do we do with the measurement.  It may be that someone else needs
to do something -- a different SIP proxy, or in some different space.
It's not clear how the application can be depended on to handle that.
This is something that draft needs to go into, and not just say 
"application's problem".  Jozef asked if it's more appropriate for
a separate draft, describing use.  There is mechanism here.  Policy
will depend on the application, and how to use.  This needs to
be stated and guidance given, but a separate draft seems more appropriate.

Fred thought that might be, but RFC 3247 has updates to EF to make
it predictable.  If traffic is experiencing marks, predictability
goes away.  Perhaps a different draft, or an appendix, but there
must be guidance for real applications.

James Polk agreed.  You've mentioned that one or more of these indications
could provide for session pre-emption.  How?  Jozef stated that the marking
is passed to the end points.   They can send to the network manager controlling
preemption.  Flows indicate that they have reached the 2nd level of congestion.
The manager can select those flows, and check policy.  If they can be 
preempted, then they can be removed.

James asked if a interface has 1000 flows, and reaches capacity, is this
second level?  If all those flows are marked, all endpoints may react at
the same time.  Tell server to tell router?

Jozef says that one way with a centralized manager that gets all these,
and it can then decide which to kill.

David said that is exactly where NSIS RMD is headed; we need to rationalize
and do it once.

Stephen Norys from BT had another question about 2 levels.  In particular,
how do you cope with toggling between levels?  If the algorithm is
vendor dependent; different vendors could produce different answers,
and the stream may switch back and forth between the two levels.
Think you want some kind of ramp effect, rather than just 2 levels.

Georgios Karagiannis, an author of the NSIS draft resource management
in diffserv:  Related to David's remark... on Thursday we will discuss
different alternatives, only one of them is this one.

Allison noted that it is reasonable for people to go to NSIS on Thursday. 
It would be good to have more discussion.  This is only part of the RMD work.

Resolved:  Jozef and the RMD folks are to talk about their work's 
potential overlap.

Diffserv Service Class (Kwok Ho Chan) (10 mins)

This is the fourth version, but first as WG item.  The notion of
administrative service classes has been removed; the network control
class (because of the first change) is now just routing and network control,
everything else is just a standard class; the multimedia conferencing
discussion changed from "elastic flows" to rate-adaptive flows, since
they are really inelastic flows that can change rate; the ring clipping
discussion has been moved to the appendix.  Updated references.

The authors feel all outstanding issues have been resolved, and
would like to start WGLC.

No comments.

Allison asked for the opinion of group on this, by a hum.
Jon and Allison reserve right to review it prior to WGLC,
because they haven't done the chairs' review yet.  

Those that support WGLC at this time for this document, which
has been at four or five meetings now, please hum:
<loud>

Those that don't support, or oppose it, please hum:
<none>

Allison declares consensus towards moving to LC
good.  Will review it, and look towards moving it forward.

Diffserv Service Class Aggregation (Kwok Ho Chan) (10 mins)

This is an extension of the last draft: how to aggregate service
classes if you don't need detail.

Want to allow less-granular treatment where not needed, but preserve
end-to-end notion of service requirements that application wants.
After discussions, think four treatment aggregates are the right number.
Network control, real time, assured elastic, and elastic.

Would like feedback on the number, and the names.

The draft would provide guidance as to how perform aggregation,
and could be used as a foundation for indications between providers.
Not sure how yet...

See slides for detail.

Next steps are to cleanup guidelines on aggregation, and add a discussion
about using MPLS to express aggregates.  We would like comments back.

Jon said it would be good to see mailing list discussion.

MLPP Update (Fred Baker/James Polk) (15 mins)

Four drafts.  

First, the MLEF concerns draft has been posted as a WG document
pursuant to discussion last time.  This changed the draft handle only.

Second, our MLPP proposal which is RSVP based.  We did a minor update
and submitted as a WG draft.  There were errors in the appendix with
respect to SIP call flows; they have been fixed.  Other than that
it's the same.

Third, at last meeting, James talked about RSVP bandwidth reduction thing.
This identified a bug in RFC 3181 when it comes to dealing with aggregate
reservations.   If I need to preempt call within reservation, it has me
tear down and set up with new number.  This has a giant hole...
this draft suggests that one simply reduce bandwidth.  "accept if doesn't
exceed X", and the endpoint changes codec or whatever is the right thing.
This draft considers backwards compatibility.

Fourth, the last draft, is a use case for bw reduction thing.
A VPN network with multiple levels of VPNing.  This is still
an individual submission.    The draft posits that VPN router
might be two boxes.  Talk about what crosses the private interface
between them.

The other 3 pretty sure about.  This one needs work; dinner tomorrow
night is a discussion of this draft with others that are interested.

we want:

We want the first three to move forward.
mlef-concerns -> informational
mlpp that works: informational or BCP
bw-reduction -> proposed.  it's a protocol.

As to the last one... If the way we get people to read & comment
is to go to last call, I would like to go to last call.  We
want people to read & comment.  So LC to informational?

Mike Pierce: object vehemently to MLEF concerns going anywhere.
The MLEF concerns document is to object to and provide comments on draft
that myself and Steve Silverman wrote on MLEF.  We have seen it..
and responded to it two years ago.  We have made changes.
To show you how bad it is... look in the draft reference section.
It references the Jan. 2004 version that has concerns with.
However, the MLEF document has been revised twice, and this draft
doesn't reference updates, much less recognize modifications made to MLEF.

The MLEF concerns actual title is
"MLEF without capacity admission does not satisfy MLPP requirements",
but we said that from the beginning.
The version from way back when that was referred to... included
explicit statement that it would not work without call admission control.
We strengthened that statement.  Yet this doc keeps arguing that point.

In addition, this document contains a large number of technical inaccuracies.
For example, g709 increasing throughput in face of loss.
It is theoretically possible for a codec to do that, but this one doesn't.
It talks about having 3 specific rates...

Jon: don't want to take exception, but this is a more detailed discussion
than we have time for.

But we need to have the discussion.  Mike objects to the document
proceeding, and is not sure how it to WG status; his recollection is
that there was no agreement.

Jon believe there was consensus, and the first time that Mr. Baker
spoke to us about it, there was strong consensus for this work.

James Polk: to last point, about ILBC not being variable... 
Alan Durek wrote part of that.  He is the author of that protocol.
He is who helped write section.

Mike said it's not in rfcs, though.

Scott Bradner agreed that this particular document that was reviewed
at ieprep was a very important document in it's day.  However, he's
not sure if needs to be RFC, unless it is recast as
"concerns about non-admission controlled attempts at priority".
It is an instructive document, but not sure it deals with the alternatives
on table today.  Would agree that it should fade out, but strongly support
moving the others forward.

Jon asked for Fred to comment.  Fred stated that when the
document was first published, he didn't expect it to be an RFC.
He could go either way.

James said that one of reasons why we regenerated  this six months
ago or so is that we had a couple other customers, other than us government,
that wanted to promote diffserv-based QoS using that mechanism.  So we wanted
to have the concerns documented.  He agreed with Scott that the
scope ought to be broader.

Fred said that he heard that if this document is to become an RFC at all,
the working group must tell him what to see.

Jon said that he believed the working group requested that rather than
document the problems with a specific proposal, speak to general design
principles that are objectionable.

Scott agreed.

Jon noted that we are out of time; clearly there should be more discussion
on issues.  Jon invited Mike to bring technical objections to list.  Jon
then declared the meeting to be closed.

------- End of Forwarded Message

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg

[Tsvwg] IETF 62 Proceedings - TSVWG meeting (can be updated)