![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.
-ken
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.