Re: [Ecrit] ECRIT Status Update - December 2008 (esnet namespace)

["James M. Polk" <[e-mail]>]

At 03:39 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Hi James,
>
> >At 05:53 PM 12/30/2008, Hannes Tschofenig wrote:
> >>8) draft-ietf-ecrit-local-emergency-rph-namespace
> >>
> >>We had some discussions about this document triggered by mails around
> >>IETF#73 asking for the purpose and the scope.
> >>I read through the e-mail exchange but I need to read through some
> >>RFCs/drafts as well in order to summarize the topic.
> >>
> >>A few folks have provided feedback (James, Brian, Janet, Keith) but
> >>more reviews from the rest of the group would be useful.
> >>
> >>Action item: Hannes to summarize the discussions and to draw
> >a conclusion.
> >
> >Hannes - why are you artificially creating such a high hurdle
> >for this ID to progress?
>
>Summarizing a discussion is not "a high hurdle".

if you only said you would summarize this, then I wouldn't be writing 
anything here. You also include this comment above

         "...but more reviews from the rest of the
         group would be useful..."

when did 6 or 7 reviewers saying one thing (in the positive) and 1 
saying another thing (in the "I don't understand") mean anything 
other than _rough_consensus_?

What we are hearing you say is "until I (Hannes) understand and agree 
with this, this ID will not progress".

Jon admitted on the mic in Minn that he's "not the biggest fan of 
RP"... which is widely known, yet he decided to say into the mc in 
Minn that he is not going to fight this effort either.

SIP has one defined way to mark the priority of a request  - and 
that's in RFC 4412 (Resource-Priority).

You have said a number of times that the To: field can be used, that 
the R-URI value can be used... claiming that using the RP header 
would add another meant of marking the priority of a request.

Yet the SIP WG chair has confirmed to you in front of several others 
(including me, Brian, Marc (your co-chair)) that SIP has one, 
singular way to priority mark its requests - and that is defined by 
RFC 4412 (Resource-Priority).

Anything else, (i.e., any other way of marking the priority of a SIP 
request) would in fact be an additional way SIP entities would have 
to be coded to perform this function.

You have repeatedly refused to acknowledge that fact.  I believe that 
is at least most of why you are resisting this ID from becoming a WG 
item, and are continuing to find manufactured faults with it.

You are standing alone in your views, my friend - which is contrary 
to IETF procedures of rough consensus, and I ask that you agree with 
the core philosophy of the IETF that rough consensus makes decisions 
in the IETF, and move on.


> >
> >The WG hummed for this ID to become a WG item in Dublin.
>
>I know. Like the group did with a number of other items.
>Officially, the document is not a WG item yet given that we would
>require the charter to change as mentioned at the last meeting.

Yeah, and that recharter - for whatever reason, didn't happen in the 
last 5 months since the Dublin meeting why?

How long before the WG can expect this recharter? (a year?)


> >
> >There hasn't been one other opinion contrary to this (save for
> >yours) on the list or at the Minneapolis meeting.
>
>Well. I raised several issues which I would like to summarize.

you raised many issues, nearly all of which had the answer "this is 
not how SIP works", but you didn't seem to like that answer.

>To pick one "PSAP callback" where there does not seem to be agreement,
>referencing Brian:
>http://www.ietf.org/mail-archive/web/ecrit/current/msg05686.html

"PSAP Callback" - hmmmmmm..... let's see....

You have a requirement that "priority" needs to be e2e in one 
direction but not the other?

Where's that written down?

Do you believe there's a chance in heck that all SIP UAs will have 
the code in them to process the priority of this PSAP Callback?

Funny, that's the same argument that you gave me that (paraphrasing) 
"because most UAs will not have RFC 4412 code in them, why are you 
(James) pushing this solution on ECRIT?"

the sword cuts both ways.

This ID doesn't have the UAC needing to set the RP within the 
INVITE.  Nor does it prioritize the RP in the received INVITE either.

Therefore PSAP Callback is pointless at this point in time for UAs at 
all, right?  It's more for the ESNET and perhaps one admin domain out 
from that network.

Look at figure 1 of this ID, and tell me where (i.e., which 
element(s) in which domain(s)) PSAP Callback is mandatory to set the 
priority of that Callback INVITE?



> > Therefore,
> >it is impossible to conclude with evidence that anyone other
> >than you are delaying this progression.
>
>Delaying? Given that we have to change the charter first

hmmm.... again... that decision was made 2 meetings ago. How much 
longer should the WG have to wait for this recharter?

>before this
>document can actually be picked up as an item (like the other documents
>as well) I am not delaying anything here.

ok, so who is writing the recharter (if not the WG chair) and why are 
they taking so long? Let me know who this other person is and I'll 
ask them to inform the WG themselves (directly) with the ETA on this.


>Getting the new charter approved is only possible if we are able to
>finish our main items, as Jon says. Despite our pushing Phone BCP and
>Framework are still not finished.

yet, I can't help but notice that both
http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-location-hiding-req/
and
http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-specifying-holes/
are recent additions to the ECRIT charter...

indeed, these two IDs weren't event though about when phoneBCP and 
Framework were WGLCd the first time, yet they made the charter within 
a few months from their hum by the WG...

this is inconsistent with the stance you are taking now with the 
esnet namespace ID, Hannes.


> >
> >Many have expressed in email to the list, and in person at
> >Minneapolis to you that you are not understanding the topic as
> >much as you believe (SIP signaling and SIP header usage, and
> >this includes the SIP chair that has given you his opinion in
> >front of others), and each of the rest of us (that have voiced
> >an opinion) are in unison in our understanding (and have
> >attempted nearly countless times to explain how you have a
> >misunderstanding of SIP communications).
>
>Maybe I don't understand this particular item well enough. If I don't
>understand it given that I am working in this space already for many
>years gives me the impression that maybe I am not the only one.

So, bluntly, how much do you understand about SIP signaling and headers?

This is the question. WG chairs do not need to understand everything 
within their WG perfectly, but need to trust a select few that do 
understand the topics you don't.  Is Keith, the SIP WG chair, not a 
good enough person to trust in this instance?

And from the point of view of "...maybe I am not the only one..." 
isn't it also the burden of those that do not understand something to 
voice their opinions at the meeting mic or on the mailing list (else 
they are to be considered in agreement with a proposal)?

I believe this is another IETF procedure you are not adhering to on this case.

>At least
>in the past I was never wrong with such an assumption.

Unless there is another who says so on the public list, you have no 
proof this is the case here.


>I don't think it can be wrong to ask questions about documents we have
>in the group (even if they appear irrelevant to the authors of the
>mechanism as he knows it better than anybody else).

Hannes, many individuals answered your questions as "you're wrong" or 
"you're not understanding SIP signaling" during the threads during 
the Minn IETF meeting.  If everyone who has responded to you is 
saying "you're not right in this opinion", what does it take for you 
to consider the possibility *each* of them is right, and you are not?

>
> >Furthermore - your co-chair does not agree with you, and
> >believes as others do that this ID is needed, necessary and
> >wants it to progress
> >- including other SDOs and organizations (NENA for one) that
> >want to reference this document as an RFC.
>
>I am actually participating in various NENA conf. calls and have
>participated in discussions around resource priority for
>citizen-to-authority emergency calls. I have not heard you on those
>calls.

not being an active participant does not mean I don't understand the 
issues. Besides, I trust Brian Rosen here, the NENA WG chair (since 
the WG formed), who is one of the ones telling you that you don't 
understand what you are saying wrt RP esnet namespace ID.


>In short, I am not delaying -- I am trying to understand. No reason to
>worry.
>
>Ciao
>Hannes
>
> >
> >James

_______________________________________________
Ecrit mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ecrit