Subject: re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)

From: ken carlberg <[email-masked]>
Date: Thu, 2 Nov 2006 13:58:01 -0500

Sam,

One of the objectives of the work produced by IEPREP was to lay down  
the ground work and put together a baseline set of requirements to  
start with when considering solutions.  Our intention was that the  
baseline then becomes a starting point where more specific  
requirements can be put forth.  Outside of this, solutions were  
definitely out of scope.

My understanding is that there are others that now wish to present  
some more specific requirements and potential solutions that do not  
fall into the scope of other working groups.  So the proposed re- 
charter looks to be a natural extension to what has been done.

Interestingly enough, the work that you mention below in your  
original posting...

<snip>
"I would assume we'd ask people working in this space to
take a look at the existing ieprep output, RFC 4542, RFC 4411,
draft-ietf-tsvwg-vpn-signal-preemption and other appropriate
documents."

... rfc-4542, rfc-4411, and draft -ietf-tsvwg-vpn-signal-preemption   
(along with some other related work) has actually not been done in  
IEPREP because the group was not allowed to consider solutions.   
Instead, some of the work has been pushed to TSVWG, to the groans and  
sometimes confusion of some of the participants of that group, who  
wondered what the subject of prioritization had to do with TSVWG.   
Part of the revised charter is meant to remove this obstacle.

Also, as Scott Brimm has mentioned, there is a proposed liaison from  
the ITU to work with the IETF, with one of the working groups of  
interest being IEPREP.  It would seem odd to close down the group and  
punt the subject to them when they are approaching "us" for  
assistance  If IEPREP is closed, does that mean the subject gets  
pushed over to TSVWG?

-ken

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Thu, 02 Nov 2006 14:45:16 -0500

>>>>> "ken" == ken carlberg <[email-masked]> 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

---

From: ken carlberg <[email-masked]>
Date: Thu, 2 Nov 2006 15:03:15 -0500

> vpn-signaling-preemption.

I mentioned the above as examples, not as a case-by-case examination  
of what should or should not be in IEPREP.  But along those lines,  
rfc-4542 (titled "Implementing an Emergency Telecommunications  
Service"), where ETS was first established in IEPREP and the draft  
deals with priority and preemption, seems odd to me to be in TSVWG.   
But if you feel differently, then we agree to disagree.

> charter than I thought I did.

I am not speaking of any specific work other than what has been  
discussed in the proposed re-charter.  to consider otherwise is to go  
beyond what I stated.

> want to change SIP, I'd hope that it would go through sipping and

we will have to wait to see what they request.  all I stated was that  
they were coming to us and that it was odd to close down a group they  
were interested in working with.  Anticipating hypotheticals are not  
useful because they can put us down a rat hole that may or may not  
have substance.

-ken