>>>>> "ken" == ken carlberg <carlberg@xxxxxxxxxx> writes:
ken> Sam, One of the objectives of the work produced by IEPREP was
ken> to lay down the ground work and put together a baseline set
ken> of requirements to start with when considering solutions.
ken> Our intention was that the baseline then becomes a starting
ken> point where more specific requirements can be put forth.
ken> Outside of this, solutions were definitely out of scope.
ken> My understanding is that there are others that now wish to
ken> present some more specific requirements and potential
ken> solutions that do not fall into the scope of other working
ken> groups. So the proposed re-charter looks to be a natural
ken> extension to what has been done.
ken> Interestingly enough, the work that you mention below in your
ken> original posting...
ken> ... rfc-4542, rfc-4411, and draft
ken> -ietf-tsvwg-vpn-signal-preemption (along with some other
ken> related work) has actually not been done in IEPREP because
ken> the group was not allowed to consider solutions. Instead,
ken> some of the work has been pushed to TSVWG, to the groans and
ken> sometimes confusion of some of the participants of that
ken> group, who wondered what the subject of prioritization had to
ken> do with TSVWG. Part
I think the work you cite belongs in tsvwg. AT least 4542 and
vpn-signaling-preemption.
ken> of the revised charter is meant to
ken> remove this obstacle.
Which work would be permitted under the revised charter that is
currently udone elsewhere? I may have more concerns about the revised
charter than I thought I did.
ken> Also, as Scott Brimm has mentioned, there is a proposed
ken> liaison from the ITU to work with the IETF, with one of the
ken> working groups of interest being IEPREP. It would seem
ken> odd to close down the group and punt the subject to them when
ken> they are approaching "us" for assistance If IEPREP is
ken> closed, does that mean the subject gets pushed over to TSVWG?
that rather depends on what question they're asking, now doesn't it?
IF they're asking for enhancements to RSVP to deal with some ETS
issues, then yes, I'd hope the work would be done in tsvwg. That way,
ETS requirements can be balanced against other requirements. If they
want to change SIP, I'd hope that it would go through sipping and
eventually sip.
If they want us to do non-protocol work closer to 4542, then perhaps
we need a WG to do it in.
--Sam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf