Subject: [Tsvwg] Status of draft-ietf-tsvwg-emergency-rsvp

From: Magnus Westerlund <[email-masked]>
Date: Fri, 27 Feb 2009 18:47:21 +0100

WG,

This is to make you all aware of the following. The RSVP-Emergency draft
has been with the IESG for a while. However, the document has 6 abstain
ballots. Despite discussion this has not been resolved and it was
requested that I do follow the procedure for when a draft becomes
deadlocked, namely to send it back to the WG.

This is according to IESG balloting procedures:
http://www.ietf.org/u/ietfchair/voting-procedures.txt

The reasons is a bit varied but mostly are operational and security
related.

This is the closest the IESG can do to say No to a document. Which means
it needs to be very clear that the WG has resolved the fundamental
issues before bringing it back to the IESG, if at all.

The authors will discuss privately with the abstainers to get some
clarification on what the issues are. Based on these we can decide what
the next steps are.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 27 Feb 2009 12:30:04 -0600

I, as an author, do not need to be as polite as Magnus is below.

One of the complaints by the IESG is that with 
this extension, RSVP will have to work - and 
misbehave - around the world, when this document 
clearly scopes its usage to within one 
administrative domain -- so there is a 
disagreement between what's written in the ID and 
what the IESG is imagining will be the scope of usage.

I even added a diagram that illustrates this 
concept that it works between nodes within the 
same domain, and not between domains (because of 
the SBCs peering between domains).

Another complaint is that this effort (RSVP based 
obviously) is inappropriately in this WG 
(remember, TSVWG is chartered with doing RSVP 
extensions and maintenance), one member of the 
IESG even saying TSVWG accepting this ID as a WG 
item was an "end-run around" (their words)  from 
the real WG that this ID should have been brought to, namely ECRIT.

Now, for those of you that do not know this, 
ECRIT handles, exclusively, 911 and 112 and 999 
type of local emergency calling.  Our ID does not 
apply to these environments - and applies to 
environments more like MLPP and GETS/GTPS 
scenarios.  This fact seems to elude the IESG, 
even when we say this to them face-to-face. No 
reasonable person would say that every 
911/112/999 call has to be authorized to get 
answered, yet this seems to be the case the IESG is thinking we're saying.

Interestingly, not a single mention of anything 
wrong with the mechanism as defined and created, 
but a lot to say about scoping, preventing 
leakage of this authorization-token (in RSVP 
only) into other domains, and the fact that ECRIT 
is the chartered WG to handle this effort.

The ECRIT charter sez: "no GETS, no MLPP" here in 
their WG... see this from the ECRIT charter:

http://www.ietf.org/html.charters/ecrit-charter.html

"Explicitly outside the scope of this group is the question of
pre-emption or prioritization of emergency services traffic. This
group is considering emergency services calls which might be made by
any user of the Internet, as opposed to government or military
services that may impose very different authentication and routing
requirements."

Needless to say - I'm rather beside myself wrt 
each of these issues as they are (and I can prove 
it for the scope/operational issue) a moving 
target, with a dose of insanity/unreasonableness 
applied, so I ask the WG, how do we tell the IESG:

- we are the proper WG for this work (and not ECRIT, which is in the RAI Area)
- how this document says this is for within a 
single domain, and not the open Internet (where 
RSVP doesn't work anyway, so they have nothing to fear)
- this document is scoped properly

?

James