Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-domain-registration

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 Oct 2009 17:06:51 +0000

This draft is attempting to provide a well specified alternative to the adhoc solutions that have been
deployed so far.   It builds on REGISTER as it exists today, and therefore I don't see how it would
benefit from, or be related to, attempts to fix other problems that may exist in REGISTER.

Given this, I prefer option #1.   The need for a well-specified solution is fairly urgent, given
the persistent interoperability problems that could result from the continued proliferation
of adhoc solutions.

If people feel it is useful to take on the issues that Dean describes (personally, I'm skeptical),
then that problem should be taken up separately.

Dean Willis said:

"I prefer option 2, given that the WG would take the requirements and not
the solution mechanism from SIP Forum.

This is our one chance to fix REGISTER, and at the same time fix the
request-URI/parameter delivery problem. Let's not waste it on an
incomplete solution.

I think that we can reasonably deliver on the domain-registration
requirement and at the same time solve (for devices that use the new
technique) the problem of URI and parameter delivery during SIP routing.
The "RUPDATE" approach I recently circulated (and that I would like to
call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I
should send a draft.

Let's not be bashful. What we're talking about here is a replacement for
the now-known-to-be-broken SIP REGISTER mechanism (and the
registered-contact routing mechanism that depends on it). While not all
that hard, getting it right is still beyond the scope of an AD-sponsored
draft."

---

From: Alan Johnston <[email-masked]>
Date: Thu, 15 Oct 2009 12:47:33 -0500

I agree with Bernard.

We tend to do good work when we have a narrow scope and well understood 
use cases. A scope like fixing all that is wrong with REGISTER sounds 
like SIP 3.0 to me rather than work that relates to domain registration.

I'd encourage everyone to read the draft and think about it a bit. I 
actually believe this approach makes some sense and is definitely the 
least ugly approach to solving this problem. You could argue that we 
shouldn't solve this problem in SIP, but no one is forced to implement 
anything, and it is really, really bad for SIP interop to have all these 
other solutions out there, as many of us have discovered.

Thanks,
Alan

Bernard Aboba wrote:
> deployed so far. It builds on REGISTER as it exists today, and 
> therefore I don’t see how it would
>
> If people feel it is useful to take on the issues that Dean describes 
> (personally, I’m skeptical),
>
> “I prefer option 2, given that the WG would take the requirements and not
>
> draft.”
> ------------------------------------------------------------------------
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2009 14:07:16 -0400

> benefit from, or be related to, attempts to fix other problems that may 

I've been trying to sit this discussion out. I see both pros and cons.

While this solution builds on REGISTER as it exists today - in that it 
uses the REGISTER message - it doesn't at all build on the mechanisms 
behind REGISTER at all. Its updating a different routing mechanism.

In an ideal world the solution to the problem this addresses would be 
reconsidered from scratch. That is what Dean is getting at.

> Given this, I prefer option #1.   The need for a well-specified solution 

I guess maybe the question is how urgent this is. Aren't the people that 
need this already doing *something*? How likely are they to move to this 
more standardized variant of their existing adhoc solutions?

	Thanks,
	Paul

---

From: Jon Peterson <[email-masked]>
Date: Thu, 15 Oct 2009 12:19:57 -0700

I believe Paul is correct that whatever the urgency of the problem this
draft fixes, neither the problem nor the fix has any particular relevance to
the existing semantics of the REGISTER method.

>From my reading of Section 3, I gather this is intended to work for
administrative domains that don't have domain names "at all." The place
where I think this actually raises serious concerns for standardization is
in the beginning of Section 4.1, where it is proposed that a UA register a
domain name that "may only exist for the purposes of this mechanism", in
other words, a textual string that is structured enough like a domain name
to work in SIP but has not actually been assigned in the global DNS through
a domain registrar.

Providing I don't misunderstand the mechanism here, I see no way this
differs from an "alt-root" of the DNS, and it looks like it gives rise to
all of the same alt-root problems (e.g. Even if a name isn't in use in the
DNS when you first provision it, via this mechanism what if someone later
purchases that domain name and does put it to use in the DNS, which
authority do you consult then to make a routing decision?). The fourth
paragraph of 4.3.2 is pretty typical of such mechanisms. Even if they have
tactical value in some deployment scenarios, I do not think the IETF should
standardize alt-root schemes, and historically it has made statements very
much to the contrary. Domain names are inexpensive and inexhaustible, and
the notion that an SMB cannot afford one is extremely dubious.

This stipulation can be removed without doing great violence to the
mechanism. The argument for not using RFC3263 then becomes a weaker one,
though - it would be that the SMB does not want to provide its own DNS
infrastructure or pony up costs for DNS hosting. Probably the strongest
remaining argument is that the SMB doesn't want to expose the IP address of
its SIP domain publicly. That, however, could just as well be an argument
for using private DNS with RFC3263. Explaining the pros and cons of this
mechanism versus private DNS in the Alternatives section is probably a
worthwhile exercise.

Jon Peterson
NeuStar, Inc.

On 10/15/09 11:07 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> therefore I don¹t see how it would
>> 
>> (personally, I¹m skeptical),
>> 
>> ³I prefer option 2, given that the WG would take the requirements and not
>> 
>> draft.²

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Oct 2009 16:46:34 -0400

If you think it would help, I can certainly remove that "may only exist for the purposes of this mechanism" piece.  I have no problems even stipulating that they MUST be valid DNS domain names, etc.  Or even that they MUST be sub-domains of the SSP's, if that would help.

With regards to it creating to an alt-root or authority issues, of course it can.  So can offering a web page to enter such information manually, or using DynDNS to a private DNS server, or editing your local hostfile on your PC.  It's not the *purpose* of the Domain Registration mechanism to do that - the fact that it can be abused to do so shouldn't keep us from issuing a option-tag, should it?

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jon Peterson
> Sent: Thursday, October 15, 2009 3:20 PM
> 
> >> Given this, I prefer option #1.   The need for a well-specified
> solution
> >> is fairly urgent, given
> >

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 Oct 2009 21:13:55 +0000

Paul said:

"I guess maybe the question is how urgent this is. Aren't the people that
need this already doing *something*? How likely are they to move to this
more standardized variant of their existing adhoc solutions?"

[BA] I know of at least two "implicit" REGISTER mechanisms that are
deployed today. At least one of them is not documented, which 
has resulted in debates as to exactly how it works and what scenarios
are and are not supported.  

We know from experience that creating a well-documented approach does
not necessarily cause existing not-so-well documented approaches to 
vanish.  But it does offer the potential hope of a path to better 
interoperability, whereas a reliance on undocumented mechanisms does
not. 

Jon Peterson said:

"Providing I don't misunderstand the mechanism here, I see no way this
differs from an "alt-root" of the DNS"

[BA] It's important to distinguish between mechanism and policy.  The
draft doesn't talk much about policy, but I don't see why the right to 
register a domain via the proposed mechanism couldn't be tied to ownership 
of the domain in question.  Typically the domain in question is 
owned by the service provider, so the SMB already has the right to 
use it.  

"I do not think the IETF should standardize alt-root schemes"

[BA] I would agree -- but I doubt that this is the intent of the authors. 

"Domain names are inexpensive and inexhaustible, and
the notion that an SMB cannot afford one is extremely dubious."

[BA] Given that the SMB is likely to be allocated a domain by the provider
as part of the contract, we can probably assume that the SMB already
"owns" an appropriate domain. 

Given that, the choice is between standardized dynamic update mechanisms, 
adhoc alternative schemes (e.g. DynDNS update protocol), and a purpose-built 
mechanism such as the one proposed in this draft. 

"This stipulation can be removed without doing great violence to the
mechanism. The argument for not using RFC3263 then becomes a weaker one,
though - it would be that the SMB does not want to provide its own DNS
infrastructure or pony up costs for DNS hosting."

[BA] In my experience, DNS hosting costs are considerably less expensive
than SIP trunking costs, so I doubt that's the concern.  

"Explaining the pros and cons of this mechanism versus private DNS in the 

Alternatives section is probably a worthwhile exercise."

[BA] I agree.  My understanding is that the larger issue is the
operational implications of relying on standardized or adhoc dynamic
DNS registration mechanisms.  I myself own a domain whose A RR I
dynamically register, yet I've been unable to find an inexpensive 
service provider willing to deliver service to me using that domain; 
whereas variants of REGISTER are widely supported.

---

From: Jon Peterson <[email-masked]>
Date: Thu, 15 Oct 2009 14:31:00 -0700

It does help to state that they must be valid domain names assigned to the
administrative domain in question. I think it would vastly improve the
prospects that the IETF could work on this problem.

> With regards to it creating to an alt-root or authority issues, of course it
> can.  So can offering a web page to enter such information manually, or using
> DynDNS to a private DNS server, or editing your local hostfile on your PC.
> It's not the *purpose* of the Domain Registration mechanism to do that - the
> fact that it can be abused to do so shouldn't keep us from issuing a
> option-tag, should it?

To be clear, the way the draft is now written one could easily walk away
with the impression that this is the purpose of the mechanism - one of the
arguments for not using RFC3263 is that this mechanism works for domain
names that haven't been assigned. Some of that motivation goes away if the
mechanism is restricted to assigned domain names.

The more subtle point here is that the risk of alt-roots lies in the
possession of the same name by two administrative entities who potentially
supply conflicting information to the directories used to route messages.
The fault in the domain-registration draft (as written today) is not that it
provides a means of registering names - as you say, that fault would be
shared with any number of existing protocols - but that it implicitly
creates a namespace managed by the back-end of that registration process,
and a namespace that is explicitly permitted to conflict with the DNS by the
text in the draft (nothing in the draft remotely suggests that this would be
an "abuse" as you say above - in fact, it suggests the opposite, that this
is a feature of the proposal!). The properties of that namespace is the
problem from a standardization perspective, not the creation of any
particular mechanism for populating a namespace.

Jon Peterson
NeuStar, Inc.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Oct 2009 18:31:23 -0400

> From: Jon Peterson [mailto:[email-masked]]
> Sent: Thursday, October 15, 2009 5:31 PM
> To: Hadriel Kaplan; Paul Kyzivat; Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [dispatch] DomainRegistration Draftdraft-kaplan-dispatch-
> domain-registration
> 
> 

No problemo - will do next round.

> mechanism is restricted to assigned domain names.

OK, I'll clear up why it's still motivating.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Oct 2009 19:03:25 -0400

I think this thread had substantiated that there *is* some controversy.

	Paul

---

From: Jon Peterson <[email-masked]>
Date: Thu, 15 Oct 2009 16:41:00 -0700

I have been giving some thought to Cullen's original question of what to 
do with this document. Had it shown up without a built-in mechanism, but 
just as a set of proposed requirements, I would probably say, "Hmm. 
Provisioning for a routing systems used to determine the next hop to 
reach an administrative domain. Works for telephone numbers. Why wasn't 
this just submitted to DRINKS?"

So, a fourth option would be to DISPATCH this to DRINKS for 
consideration as a charter item there. Given the overlap with other 
things considered in DRINKS, that might be preferable to spinning up a 
new effort of some kind, were that under consideration.

I'd also have a bunch of comments about the proposed mechanism, 
including a perhaps predictable assessment of the relative merits of 
REGISTER and PUBLISH for this function, but if this document is going to 
get a WG home, that discussion belongs there.

Jon Peterson
NeuStar, Inc.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 15 Oct 2009 20:00:02 -0400

NO .. I don't think so. 

This is NOT a DRINKS issue and I cant possibly imagine any scenario where it
would be. This is about SIP Trunking between S-PBX and a SSP. There are
certainly provisioning issues that need to be dealt with but they are not
even orthogonal to the problem at hand. 

>  Sent: Thursday, October 15, 2009 7:41 PM
>  To: Paul Kyzivat
>  Cc: [email-masked]; Hadriel Kaplan
>  >>> It does help to state that they must be valid domain names
>  assigned
>  >>> to the
>  >>> To be clear, the way the draft is now written one could easily
>  walk
>  >>> away
>  >>> with the impression that this is the purpose of the mechanism -
>  one
>  >>> of the
>  >>> names that haven't been assigned. Some of that motivation goes
>  away
>  >>> if the

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Oct 2009 09:58:33 -0400

Yeah, I can see what you mean, but there really aren't even the 3 options in Cullen's email.  We wanted to get an options-tag because we thought it was "the right thing to do".  ISTM the options-tag concept was put in place for this kind of circumstance, so that an extension can be cleanly indicated and an incompatibility detected/negotiated.  And since an options-tag requires a standards-track, here we are.  

Going the A-D route didn't mean we weren't open to edits/changes of the document's mechanism - we *want* people's feedback - just that we don't have time for a WG charter, a requirements doc, fixing unrelated issues, etc.

But if the consensus is that we can't go the A-D route, then we'll just go with Option-3: submitting an Informational draft and go the individual submission path.  We'll get rid of the options-tag, and either just ask for a SIP Header to do something similar, or not even that.  

There's enough wiggle room in rfc3261 routing procedures that we can document this whole thing to just be a specific implementation of 3261-compliant local-policy routing, based on the reachability information from a "normal" 3261-compliant REGISTER'ed AoR.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Oct 2009 10:33:16 -0500

> even orthogonal to the problem at hand. 

I spent some time talking with Rich yesterday, and we see it a bit
differently.

I do not see this as not just a SIP trunking problem.

I see it entirely as a problem of dynamically associating SIP nodes
(proxies and UAs) with a set of destination URIs at the SIP routing
level. RFC 3261's REGISTER is one way of handling a subset of these
cases. What we're really talking about is a more general mechanism than
REGISTER.

That said, such an extension mechanism is required in order to make the
provisioning envisioned by DRINKS really useful.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Oct 2009 10:43:22 -0500

Hadriel Kaplan wrote:
> Yeah, I can see what you mean, but there really aren't even the 3
> options in Cullen's email.  We wanted to get an options-tag because
> we thought it was "the right thing to do".  ISTM the options-tag
> concept was put in place for this kind of circumstance, so that an
> extension can be cleanly indicated and an incompatibility
> detected/negotiated.  And since an options-tag requires a
> standards-track, here we are.
> 
> Going the A-D route didn't mean we weren't open to edits/changes of
> the document's mechanism - we *want* people's feedback - just that we
> don't have time for a WG charter, a requirements doc, fixing
> unrelated issues, etc.

DISPATCHing the draft to any extant working group eliminates the
chartering phase.

Or are you saying you also don't have time to fix the mechanism, and
it's a case of "publish my extension as a standard or I'll game the
process and publish it more-or-less as is some other way"

> 
> But if the consensus is that we can't go the A-D route, then we'll
> just go with Option-3: submitting an Informational draft and go the
> individual submission path.  We'll get rid of the options-tag, and
> either just ask for a SIP Header to do something similar, or not even
> that.

The procss doesn't allow informational drafts to conflict with chartered
work.

SIPCORE has as a charter item:

Jul 2009 Delivering request-URI and parameters to UAS via proxy to IESG
(PS)

So if we use domain routing as the basis for fixing request URI delivery
(as you said, it allows a sidestep of the problem by using loose routing
to the end), then this work is clearly in SIPCORE's charter domain.

Problem solved: dispatch it to SIPCORE, change the method name (it just
isn't REGSITER anymore), and add the bits needed to discuss how it fixes
target and parameter delivery, and I hope add the simultaneous
registration of other routes and things I mentioned in a separate email.

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Oct 2009 12:23:53 -0400

> From: Dean Willis [mailto:[email-masked]]
> Sent: Friday, October 16, 2009 11:33 AM
> To: Richard Shockey
> 

Yes, I agree - in the long run.  For example it could be something for a new package to be done using PUBLISH or SUB/NOT, which would contain routes and destinations and so on.  But that's a much bigger work item than what we need for the IP-PBX space, and we need it right now.  It will take at least 3-4 years to get something like what you're talking about done.  We don't have that kind of time for SIP Trunking.  We're trying to get SIP Connect 1.1 published in Q1-2010.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Oct 2009 12:44:06 -0400

> Sent: Friday, October 16, 2009 11:43 AM
> 
> 

It still requires a re-charter/charter-update/whatever-they-call-it for the WG.

> process and publish it more-or-less as is some other way"

No, it's not - I'm looking for constructive criticism to help improve it and get it published.  But I/we need it to happen quickly.  The history of this is such that we (in SIP-Connect) were not really intending to have to publish an IETF draft to begin with.  We were just going to do something similar to 3GPP, and I wrote that original model up in draft-kaplan-dispatch-sip-implicit-registrations-00, as an Informational "FYI" so to speak.  But after some more discussion in SIP Forum, we agreed to try to do what we thought would be a more general mechanism in a cleaner way, and that also led us to decide to ask for an option-tag, which turned this thing into a standards-track doc.  It's not a "game the process" - I'm trying the process.

> Jul 2009 Delivering request-URI and parameters to UAS via proxy to IESG

The Domain Registration mechanism does not resolve that problem.  It's not being used for the case that the problem exists: aor-resolution/routing.  Domain Registration is just a means of populating a local table for use in inter-domain routing, which is looked up prior to DNS - nothing to do with aor-resolution/routing.

> to the end), then this work is clearly in SIPCORE's charter domain.

The fact that Domain Registration uses loose-routing to sidestep the AoR-resolution problem, doesn't mean that any future effort to fix the AoR-resolution problem would conflict with Domain Registration.  They are completely orthogonal.  The Domain Registration mechanism doesn't have the problem to begin with.  It uses an already existent solution to get around it: loose-routing, for a different scenario.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 16 Oct 2009 13:07:09 -0400

Dean .. Hadriel is right here, again. Folks must remember that the SIPforum
people that were involved in this effort are exactly the same people that
generally inhabit this list. The SIPforum is not a SDO however we obviously
spend a great deal of time and money trying to make SIP work better. SIPit
for instance, is a formal SIPforum sponsored activity. The SIPconnect
process is in that same spirit.

For over 12 months now almost once a week on calls and several times face to
face we have talked this problem out over and over again. Multiple
approaches were considered and it was the near unanimous opinion of the
participants that bringing this draft forward was " the right thing to do"
tm. This technique is in the field NOW and this draft solves known
interoperability issues.  Should the IETF consider longer term solutions, of
course but we are trying to fix a problem today.

Furthermore as folks have noted there are substantive business issues here
that this draft actually solves. It is specifically addresses issues in the
SMB Market where SIPtrunking has started to deploy at ever increasing rates.
The service enhancements and reduced costs of SIPtrunking are important here
hence the use of the domain registration technique. 

I'm convinced, as were all of the participants in this process that bringing
this draft forward enhances the interoperability of SIP and increases the
deployment opportunities for SIPtrunking in the future by orders of
magnitude.

There is nothing in this discussion so far that makes me alter my belief
that 

A. the draft is the "right thing to do" tm.
B. It can and should go forward as AD sponsored. 
 
>  No, it's not - I'm looking for constructive criticism to help improve
>  it and get it published.  But I/we need it to happen quickly.  The
>  history of this is such that we (in SIP-Connect) were not really
>  intending to have to publish an IETF draft to begin with.  We were
>  just going to do something similar to 3GPP, and I wrote that original
>  model up in draft-kaplan-dispatch-sip-implicit-registrations-00, as an
>  Informational "FYI" so to speak.  But after some more discussion in
>  SIP Forum, we agreed to try to do what we thought would be a more
>  general mechanism in a cleaner way, and that also led us to decide to
>  ask for an option-tag, which turned this thing into a standards-track
>  doc.  It's not a "game the process" - I'm trying the process.
>  
>  
>  The Domain Registration mechanism does not resolve that problem.  It's
>  not being used for the case that the problem exists: aor-
>  resolution/routing.  Domain Registration is just a means of populating
>  a local table for use in inter-domain routing, which is looked up
>  prior to DNS - nothing to do with aor-resolution/routing.
>  
>  
>  The fact that Domain Registration uses loose-routing to sidestep the
>  AoR-resolution problem, doesn't mean that any future effort to fix the
>  AoR-resolution problem would conflict with Domain Registration.  They
>  are completely orthogonal.  The Domain Registration mechanism doesn't
>  have the problem to begin with.  It uses an already existent solution
>  to get around it: loose-routing, for a different scenario.
>  
>  -hadriel

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Oct 2009 13:29:06 -0500

> I think this thread had substantiated that there *is* some  

+1

We're already seeing a fair bit of technical discussion and give-and- 
take about the draft. That discussion belongs in a work group, even if  
you _don't_ include Dean's wish to fix REGISTER in general as part of  
the scope.

If it were not for the time pressure, I think we would see lots of  
complaints that the draft went too quickly from requirements to  
mechanism. IMO, external time pressure is the _worst_ reason to  
circumvent DISPATCH on a draft.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Oct 2009 17:03:02 -0400

Thinking about this some more, seems to me Jon's right (as usual) that dispatching this to DRINKS does kinda make sense - and rechartering ain't that bad. :)

So can we get a consensus call to DISPATCH it to DRINKS?

-hadriel

> To: Hadriel Kaplan
> Cc: Jon Peterson; Paul Kyzivat; [email-masked]

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 16 Oct 2009 23:51:24 -0500

----- Original Message ----- 
From: "Ben Campbell" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: <[email-masked]>; "Hadriel Kaplan" <[email-masked]>
Sent: Friday, October 16, 2009 1:29 PM
Subject: Re: [dispatch] 
DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration

> We're already seeing a fair bit of technical discussion and give-and- take 
> about the draft. That discussion belongs in a work group, even if  you 
> _don't_ include Dean's wish to fix REGISTER in general as part of  the 
> scope.
>

Hi, Ben,

I may have misunderstood what you were saying, but if you're thinking that 
Hadriel is trying to circumvent DISPATCH, that's not how we got here.

We were pretty far down the garden path with Cullen on asking him to 
AD-sponsor an Informational draft that defined a SIP header field that 
identified a domain registration, but we convinced ourselves that this 
really should be a SIP option tag, because we wanted the property that a 
registering SIP-PBX could cause a domain registration to fail (if that was 
the right answer) by Requiring a SIP option tag - with an unknown SIP header 
field, the service provider SIP proxy would just ignore it, and the SIP-PBX 
couldn't detect that "the REGISTER succeeded, but the domain wasn't 
registered".

So we agreed (and agreed with Cullen) that this draft should specify a SIP 
option tag, even though this required a standards-track specification (the 
header field did not), and even though Cullen said he was not willing to 
AD-sponsor a standards-track specification without input from DISPATCH.

We made the decision (in discussions with Cullen) to go to DISPATCH, which 
is the opposite of circumventing DISPATCH.

I guess I should add one observation that I've been making privately. We're 
looking at deployed, undocumented, and inconsistent SIP-PBX behavior with 
SIP REGISTERs that carry no indication that something magic is happening 
behind the scenes. I see Hadriel's draft as an effort to "housebreak" this 
behavior, so that network operators, middleboxes, etc. at least get some 
clue that This Is Not Your Parent's REGISTER Operation, just by looking at a 
packet trace with WireShark. They can't know that today. That's why I 
supported it, when Cullen asked for input earlier this week.

My experience with "housebreaking" pets and small children has been that the 
resulting behavior isn't perfect, but there is a lot less "waste" on the 
carpet after housebreaking - and that seemed like sufficient reason to 
housebreak pets and small children. That's kind of how I'm seeing domain 
registration - as an improvement.

So I guess people can pop Hadriel across the muzzle with a rolled-up 
newspaper, but this still seems like the right thing to do, IMO.

:-)

Thanks,

Spencer

---

From: Ben Campbell <[email-masked]>
Date: Sat, 17 Oct 2009 10:07:27 -0500

On Oct 16, 2009, at 11:51 PM, Spencer Dawkins wrote:

>
> ----- Original Message ----- From: "Ben Campbell" <[email-masked]>
> Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch- 
> domain-registration
>
>
>> We're already seeing a fair bit of technical discussion and give- 
>> and- take about the draft. That discussion belongs in a work group,  
>> even if  you _don't_ include Dean's wish to fix REGISTER in general  
>> as part of  the scope.
>>
> I may have misunderstood what you were saying, but if you're  
> thinking that Hadriel is trying to circumvent DISPATCH, that's not  
> how we got here.

Apologies--that was a bad word choice on my part. I understand that  
_this_ discussion is occurring on DISPATCH. I meant to refer to "being  
DISPATCHed to a work group"

> AD-sponsor an Informational draft that defined a SIP header field  
> that identified a domain registration, but we convinced ourselves  
> that this really should be a SIP option tag, because we wanted the  
> property that a registering SIP-PBX could cause a domain  
> registration to fail (if that was the right answer) by Requiring a  
> SIP option tag - with an unknown SIP header field, the service  
> provider SIP proxy would just ignore it, and the SIP-PBX couldn't  
> detect that "the REGISTER succeeded, but the domain wasn't  
> registered".
>
> So we agreed (and agreed with Cullen) that this draft should specify  
> a SIP option tag, even though this required a standards-track  
> specification (the header field did not), and even though Cullen  
> said he was not willing to AD-sponsor a standards-track  
> specification without input from DISPATCH.
>
> We made the decision (in discussions with Cullen) to go to DISPATCH,  
> which is the opposite of circumventing DISPATCH.
>
> I guess I should add one observation that I've been making  
> privately. We're looking at deployed, undocumented, and inconsistent  
> SIP-PBX behavior with SIP REGISTERs that carry no indication that  
> something magic is happening behind the scenes. I see Hadriel's  
> draft as an effort to "housebreak" this behavior, so that network  
> operators, middleboxes, etc. at least get some clue that This Is Not  
> Your Parent's REGISTER Operation, just by looking at a packet trace  
> with WireShark. They can't know that today. That's why I supported  
> it, when Cullen asked for input earlier this week.
>
> My experience with "housebreaking" pets and small children has been  
> that the resulting behavior isn't perfect, but there is a lot less  
> "waste" on the carpet after housebreaking - and that seemed like  
> sufficient reason to housebreak pets and small children. That's kind  
> of how I'm seeing domain registration - as an improvement.
>

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 Oct 2009 10:17:13 -0500

Ben Campbell wrote:

>> I may have misunderstood what you were saying, but if you're thinking
>> that Hadriel is trying to circumvent DISPATCH, that's not how we got
>> here.
> 

It's not just a matter of being DISPATCHed to a working group; it's a
matter of being DISPATCHed to a working group that can process the task
effectively. This requires that the draft be within the scope of the
charter for the WG, and that the WG have effective change control over
the draft, and that the IETF community as a whole be able to review the
draft as it progresses.

Remember, we pushed really hard on Phil Zimmermann about change control
on his ZRTP draft. Could the IETF process change it if it needs
changing? Since the answer seemed to be "no" (or at least in part
because), we picked a different baseline document.

We have to ask the same questions of anything coming in: What are you
REALLY trying to solve? Is the proposed solution a effective way to
solve it? Will you let us adapt the solution to make it as effective as
reasonably possible within the IETF process?

So far, with this draft, it looks like the authors have only the "tail
of the tiger"; they haven't realized that the problem they're trying to
solve is a sizable subset of a more geeral problem that we're close to
solving. And they seem to be insisting that outside of minor
word-smithing and editing-to-standard-form that the document is
sacrosact and the proposed mechanism not alterable by the IETF. If it
were anybody else, we'd refuse to engage under those terms. Should we be
consistent? in our relationships with other organizations?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Oct 2009 11:39:53 -0400

> Sent: Saturday, October 17, 2009 11:17 AM
> To: Ben Campbell
> 

It was never my intention to avoid community review nor subvert change control.  I was under the impression that even being "A-D sponsored" it would still be debatable/editable, go through a WGLC period, and through IESG processing.  No?  The piece that would be "avoided" would be creating a WG, passing its charter, going through a separate requirements stage if any, selecting an I-D to become a WG doc, etc.  Certainly it assumes the proposed solution is close to the final one, which you and two other people disagree with.

If we dispatch it to DRINKS, then I think that bypasses some of the extra delay and is a good compromise.  Do you concur?

> sacrosact and the proposed mechanism not alterable by the IETF. 

No, that's not what I or anyone has said, afaik.  What we've said is we don't have much time.  Because of that, if the consensus is that the solution we propose is not close to acceptable as a standards-track document in a way which lets us publish it in short time, then we will go to plan B and change it to be a Individual-submission informational doc.  To put it in your analogy with Phil Zimmerman's draft, he had the choice of going the Individual path instead.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 Oct 2009 10:54:48 -0500

On Fri, 2009-10-16 at 23:51 -0500, Spencer Dawkins wrote:
> I see Hadriel's draft as an effort to "housebreak" this
> packet trace with WireShark. They can't know that today.

Then why should we call it REGISTER? Wouldn't it be better to use a
different request method name?

--
Dean

---

From: François AUDET <[email-masked]>
Date: Sat, 17 Oct 2009 09:04:21 -0700

Because it is widely deployed that way, and nobody is going to change  
their implementation drastically as it works fine today.

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 Oct 2009 11:08:27 -0500

Hadriel Kaplan wrote:

> If we dispatch it to DRINKS, then I think that bypasses some of the
> extra delay and is a good compromise.  Do you concur?

That's true for any WG that it can fit into the charter of, including
DRINKS and SIPCORE.

I think you've got a hold of an absolutely critical, core piece of SIP
functionality. You're either revising or replacing one of the
fundamental SIP methods, dating to before RFC 2543. That says SIPCORE to me.

> No, that's not what I or anyone has said, afaik.  What we've said is
> we don't have much time.  Because of that, if the consensus is that
> the solution we propose is not close to acceptable as a
> standards-track document in a way which lets us publish it in short
> time, then we will go to plan B and change it to be a
> Individual-submission informational doc.  To put it in your analogy
> with Phil Zimmerman's draft, he had the choice of going the
> Individual path instead.

I believe that the same objections that might prevent you from making a
"standards track" solution would also keep you from making an
informational solution. You might not notice, but we've held even the
info track documents to a high level of review.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 Oct 2009 11:12:12 -0500

>From a standards perspective, that's a really weak answer. If it's
already widely deployed and works just fine, why should we standardize it?

--
Dean

---

From: François AUDET <[email-masked]>
Date: Sat, 17 Oct 2009 09:15:25 -0700

Because there are some interoperability glitches, but mostly because  
today, it relies effectively on word-of-mouth: go talk to your local  
SIP expert (TM).

This is not scalable, especially for those of us on the receiving end  
of the requests.

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Oct 2009 12:18:46 -0400

> Sent: Saturday, October 17, 2009 11:55 AM
>
> Then why should we call it REGISTER? 

Well, it really is "registering" something.

> Wouldn't it be better to use a

I don't think so, for several reasons:  

1) there is quite a bit of angst with new methods.  I don't think it's any news to folks that people believe it's a "big deal" to use a new method name vs. a new option-tag, header, or param.

2) there're quite a number of extensions which would be needed or useful for this, which are tied to REGISTER in their RFC text.  For example: sip-outbound, Path, Service-Route, reg-event.  We would have to update the text.

3) the difference between domain-registration and aor-registrations for the request transaction that does the registering is only in the specific DB it populates/updates.  PUBLISH could be used instead, but populating reachability information has a bunch of very specific needs, as provided by sip-outbound and Path.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Oct 2009 12:33:56 -0400

> Sent: Saturday, October 17, 2009 12:08 PM
> 

We're not updating 3261, 3262, or 3263.  We're not revising or replacing REGISTER.  We're extending, using an options-tag to indicate it.  Otherwise what you're saying is every extension that needs an options-tag for any request Method name documented in 3261 needs to be in sipcore - including any applying to INVITE.  I don't think you want that.

> info track documents to a high level of review.

There would be nothing to discuss.  It wouldn't require an informational draft to even be published.  There's enough wiggle room in 3261 routing procedures and Registration procedures to avoid any need - the draft would effectively be an "FYI".  Effectively it would be something along the lines of the older draft-kaplan-dispatch-sip-implicit-registrations-00.  

We would register an AoR in a REGISTER transaction - for requests to that specific AoR things would follow 3261 as is.  For all intents, it's a fake AoR.  Internally, in the Registrar DB, that AoR's reachability information (contact/path) would just not-so-coincidentally happen to be used for Route header fields for that domain.  Since that routing portion is effectively up to local policy (ie, implementations), it would comply with 3261 as well.  Nothing in 3261 demands that local policy routing results follow any prescribed data, so we'd just document that it happens to be data populated from that AoR's reachability data.  

There isn't even a need for a new header.  We'd just try for one to help troubleshooting and avoiding erroneous manual configuration.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sun, 18 Oct 2009 23:40:18 -0500

On Oct 17, 2009, at 11:33 AM, Hadriel Kaplan wrote:

>> fundamental SIP methods, dating to before RFC 2543. That says  
>> SIPCORE to
>> me.
>
> We're not updating 3261, 3262, or 3263.  We're not revising or  
> replacing REGISTER.  We're extending, using an options-tag to  
> indicate it.  Otherwise what you're saying is every extension that  
> needs an options-tag for any request Method name documented in 3261  
> needs to be in sipcore - including any applying to INVITE.  I don't  
> think you want that.
>

I normally try not to say things like this, but . . .

Bullshit.

You're adding a raft of new functionality to REGISTER, abusing an  
option tag, requiring registrars to differentiate between AoR and  
domain registrations, adding a 2nd routing database to the proxy/ 
registrar, etc.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Oct 2009 10:25:45 +0200

No, the draft is extending, not updating, RFC 3261, in the same way that RFC 3262, and many other RFCs, extend RFC 3261.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 19 October 2009 05:40
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [dispatch] 
> >> I think you've got a hold of an absolutely critical, core 
> piece of  
> >> SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2009 10:01:26 -0400

I continue to sit on the fence about this one:

I understand and agree with what Hadriel is saying about this behavior 
falling within the latitude given to proxies on how they route things. 
Thus I think it is *conforming* for SIPForum or some other group to make 
an agreement about a convention that does things this way.

But it is a hack. It is not a *clean* way to do it. I expect more from 
IETF approved documents. Maybe we are to the point with SIP where there 
is too much inertia to afford "clean", and that hacks are now the way 
forward. But if so, that is at least sad.

	Thanks,
	Paul

---

From: Henry Sinnreich <[email-masked]>
Date: Mon, 19 Oct 2009 07:29:25 -0700

>Maybe we are to the point with SIP where there is too much inertia to afford "clean",
>and that hacks are now the way

Agree and it makes one wonder how an Internet SIP architecture document would look like.
Having in Mind something like REST
http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

Thanks, Henry

On 10/19/09 9:01 AM, "Paul Kyzivat" <[email-masked]> wrote:

        Thanks,
        Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 19 Oct 2009 09:38:59 -0500

I have a minor apology to make on-list.

John Elwell pointed out in a private post that "housebreaking" in UK English 
means "burglary", not "teaching pets and small children how/when/where we 
deposit body wastes", so he was totally mystified by this part of my 
previous post:

> I guess I should add one observation that I've been making privately. 
> We're looking at deployed, undocumented, and inconsistent SIP-PBX behavior 
> with SIP REGISTERs that carry no indication that something magic is 
> happening behind the scenes. I see Hadriel's draft as an effort to 
> "housebreak" this behavior, so that network operators, middleboxes, etc. 
> at least get some clue that This Is Not Your Parent's REGISTER Operation, 
> just by looking at a packet trace with WireShark. They can't know that 
> today. That's why I supported it, when Cullen asked for input earlier this 
> week.
>
> My experience with "housebreaking" pets and small children has been that 
> the resulting behavior isn't perfect, but there is a lot less "waste" on 
> the carpet after housebreaking - and that seemed like sufficient reason to 

So if your $LOCALE means you were also mystified, I apologise, and if 
s/housebreaking/housetraining/g is clearer, please make the substitution 
retroactively.

Thanks,

Spencer

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 19 Oct 2009 12:33:36 -0400

Paul please remember ..we are trying to fix something that is in the field
right now and widely deployed that is causing interoperability problems.  

There are probably better ways to approach the bindings between PBX's and
SSP's and the larger issues of provisioning but that is not what the draft
is trying to accomplish and there is a substantial community here that is
trying to do the right thing. 

>  Behalf Of Paul Kyzivat
>  Sent: Monday, October 19, 2009 10:01 AM
>  To: Hadriel Kaplan
>  Cc: [email-masked]
>  replacing REGISTER.  We're extending, using an options-tag to indicate
>  it.  Otherwise what you're saying is every extension that needs an
>  options-tag for any request Method name documented in 3261 needs to be
>  in sipcore - including any applying to INVITE.  I don't think you want
>  that.
>  >
>  >
>  > There would be nothing to discuss.  It wouldn't require an
>  informational draft to even be published.  There's enough wiggle room
>  in 3261 routing procedures and Registration procedures to avoid any
>  need - the draft would effectively be an "FYI".  Effectively it would
>  be something along the lines of the older draft-kaplan-dispatch-sip-
>  implicit-registrations-00.
>  >
>  > We would register an AoR in a REGISTER transaction - for requests to
>  that specific AoR things would follow 3261 as is.  For all intents,
>  it's a fake AoR.  Internally, in the Registrar DB, that AoR's
>  reachability information (contact/path) would just not-so-
>  coincidentally happen to be used for Route header fields for that
>  domain.  Since that routing portion is effectively up to local policy
>  (ie, implementations), it would comply with 3261 as well.  Nothing in
>  3261 demands that local policy routing results follow any prescribed
>  data, so we'd just document that it happens to be data populated from
>  that AoR's reachability data.
>  >
>  > There isn't even a need for a new header.  We'd just try for one to
>  help troubleshooting and avoiding erroneous manual configuration.
>  >
>  > -hadriel

---

From: "Brian Lindsay" <[email-masked]>
Date: Mon, 19 Oct 2009 12:43:40 -0400

Hi,

   Would like to chime in and express support for
standardization/formalization of a REGISTER-based solution to this
problem, to address the SIP PBX problem space in a timely fashion by
building on currently deployed approaches, rather than inventing
something new. The draft should be DISPATCH'ed in a manner to best
facilitate that.

  Thanks.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Shockey
Sent: Monday, October 19, 2009 12:34 PM
To: 'Paul Kyzivat'; 'Hadriel Kaplan'
Cc: [email-masked]
Subject: Re:
[dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain-registrati
on

Paul please remember ..we are trying to fix something that is in the
field right now and widely deployed that is causing interoperability
problems.  

There are probably better ways to approach the bindings between PBX's
and SSP's and the larger issues of provisioning but that is not what the
draft is trying to accomplish and there is a substantial community here
that is trying to do the right thing. 

>  I understand and agree with what Hadriel is saying about this 
> behavior  falling within the latitude given to proxies on how they
route things.
>  Thus I think it is *conforming* for SIPForum or some other group to  
> make  an agreement about a convention that does things this way.
>  
>  But it is a hack. It is not a *clean* way to do it. I expect more 
> from  IETF approved documents. Maybe we are to the point with SIP 
> where  there  is too much inertia to afford "clean", and that hacks 
> are now the way  forward. But if so, that is at least sad.
>  
>  	Thanks,
>  	Paul
>  
>  Hadriel Kaplan wrote:
>  >> Sent: Saturday, October 17, 2009 12:08 PM  >>  >> I think you've 
> got a hold of an absolutely critical, core piece of  SIP  >> 
> functionality. You're either revising or replacing one of the  >> 
> fundamental SIP methods, dating to before RFC 2543. That says  SIPCORE

> to  >> me.

> that.
>  >
>  >
>  >> I believe that the same objections that might prevent you from  
> making a  >> "standards track" solution would also keep you from 
> making an  >> informational solution. You might not notice, but we've 
> held even  the  >> info track documents to a high level of review.
>  >

>  > We would register an AoR in a REGISTER transaction - for requests 
> to  that specific AoR things would follow 3261 as is.  For all 
> intents,  it's a fake AoR.  Internally, in the Registrar DB, that 
> AoR's  reachability information (contact/path) would just not-so-

---

From: Jon Peterson <[email-masked]>
Date: Mon, 19 Oct 2009 11:39:28 -0700

The question of whether or not the mechanism can (or should) be improved 
is entirely separable from whether or not it normatively updates RFC3261 
or 3263. Well, even before that separation, we should quarantine the 
problem from the solution here: I'd say the problem should be able to 
live outside of SIPCORE, and if the eventual solution does entail a 
normative update to one of the SIPCORE specs, then certainly it must 
have gone down the wrong path. I see no serious bar to bringing this 
work to DRINKS.

Once it does have a home, then we can see if the solution can be 
improved on the way through. Again, personally I'd have some few words 
to say in favor of doing this with PUBLISH.

Jon Peterson
NeuStar, Inc.

Paul Kyzivat wrote:
> be something along the lines of the older 
> draft-kaplan-dispatch-sip-implicit-registrations-00. 
> >
> reachability information (contact/path) would just 
> not-so-coincidentally happen to be used for Route header fields for 
> that domain.  Since that routing portion is effectively up to local 
> policy (ie, implementations), it would comply with 3261 as well.  
> Nothing in 3261 demands that local policy routing results follow any 
> prescribed data, so we'd just document that it happens to be data 
> populated from that AoR's reachability data. 
> >

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Oct 2009 21:50:25 +0200

REGISTER-based solutions are what exist in the field, unfortunately with slight variations. The domain registration draft aims at standardising something pretty close to all of these, and therefore is not too much of an ask to get present deployments upgraded to support it. Although there are undoubtedly other approaches to solving the problem, they are unlikely to cause present service providers and PBXs to depart from their present REGISTER-based practice. I support what Brian, Richard and several others are saying.

John

> [mailto:[email-masked]] On Behalf Of Brian Lindsay
> Sent: 19 October 2009 17:44
> To: Richard Shockey; Hadriel Kaplan; [email-masked]
> Subject: Re: [dispatch] 
> [mailto:[email-masked]] On
> 
> > Behalf Of Paul Kyzivat

---

From: Alan Johnston <[email-masked]>
Date: Mon, 19 Oct 2009 16:44:17 -0500

I agree 100% with Jon that SIPCORE and normative updates to RFC 326x  
would not be needed.

I also have sympathies for a PUBLISH based mechanism.  One could  
definitely define an interconnect event package which could have all  
kinds of interesting information in it besides just a URI (congestion  
information, alternate routes, services available, etc).  This would  
be a good multi-year task for a working group.

Unfortunately, this doesn't meet the needs for simple SIP trunking,  
where the mechanism must be REGISTER based for the reasons Hadriel  
oulined earlier.

Thanks,
Alan

On Oct 19, 2009, at 1:39 PM, Jon Peterson <[email-masked]>  
wrote:

>
> The question of whether or not the mechanism can (or should) be  
> improved is entirely separable from whether or not it normatively  
> updates RFC3261 or 3263. Well, even before that separation, we  
> should quarantine the problem from the solution here: I'd say the  
> problem should be able to live outside of SIPCORE, and if the  
> eventual solution does entail a normative update to one of the  
> SIPCORE specs, then certainly it must have gone down the wrong path.  
> I see no serious bar to bringing this work to DRINKS.
>
> improved on the way through. Again, personally I'd have some few  
> words to say in favor of doing this with PUBLISH.
>
> Jon Peterson
> NeuStar, Inc.
>
> Paul Kyzivat wrote:
>>
>> behavior
>> make
>> from
>> making a
>> informational draft to even be published.  There's enough wiggle  
>> room in 3261 routing procedures and Registration procedures to  
>> avoid any need - the draft would effectively be an "FYI".   
>> Effectively it would be something along the lines of the older  
>> draft-kaplan-dispatch-sip-implicit-registrations-00. >
>> domain.  Since that routing portion is effectively up to local  
>> Nothing in 3261 demands that local policy routing results follow  
>> any prescribed data, so we'd just document that it happens to be  
>> data populated from that AoR's reachability data. >
>> > There isn't even a need for a new header.  We'd just try for one  
>> to help troubleshooting and avoiding erroneous manual configuration.
>> >
>> > -hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 20 Oct 2009 00:00:30 -0500

On Oct 19, 2009, at 4:44 PM, Alan Johnston wrote:

> kinds of interesting information in it besides just a URI  
> (congestion information, alternate routes, services available,  
> etc).  This would be a good multi-year task for a working group.

But a simple PUBLISH-based mechanism would require no more text than a  
REGISTER-based mechanism, while providing easy graft-on points for the  
more advanced features you mention here. If it can be done in IETF in  
the same time frame as hacking up REGISTER would require, what's your  
problem?

> where the mechanism must be REGISTER based for the reasons Hadriel  

That argument just doesn't hold up. We're told that it has to be  
REGISTER because of the huge installed base for the mechanism. Yet  
clearly, none of the installed base does it exactly the way that the  
draft proposes to do it. Further, the draft's proposed approach breaks  
many of the rules about how SIP operates (like its bogus use of  
Require to invoke a feature, contextual overloading of Contact to mean  
something else, and so on).

We know we made mistakes early in SIP, but you'd think we'd have  
learned something by now about how not to repeat them. This approach,  
however, operates by combining a handful of existing mistakes in a new  
and misguided way to make something even more convoluted than I had  
imagined possible. Impressive, but still not a good idea.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Oct 2009 09:46:02 -0400

> Sent: Tuesday, October 20, 2009 1:01 AM
> To: Alan Johnston
> 

As I've already mentioned, the REGISTER request has some already-defined mechanisms which are necessary: sip-outbound and Path.  Plus some that are maybe not necessary, but at least useful: Service-Route and reg-event.
Considering how long it took us to do sip-outbound, I'm fairly confident starting from scratch on a PUBLISH way of doing this will be a multi-year project.

Furthermore, this isn't just about how long it takes to document it - it's also about how long it takes to get it adopted.

> draft proposes to do it. 

It's true the installed base doesn't use the exact mechanism in domain-registration draft, but it's not far off for the IP-PBX side.  The amount of installed base which uses REGISTER, both on the IP-PBX side and the proxy/middlebox and Registrar side is pretty darn big.  We're trying to keep the changes as minimal as possible.

> Further, the draft's proposed approach breaks

Now you're sounding like a "deeply disingenuous response".  It does NOT "break many of the rules about how SIP operates".  We're extending, which by definition means doing something new SIP didn't do before.  With regards to the Require usage, I've already said if what you demand is a new header as well, then let's debate that.  The Contact, however, is not overloaded - it means the same thing a Contact did in 3261 REGISTER.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Oct 2009 09:51:55 -0400

> imagined possible. Impressive, but still not a good idea.

Some of us feel the "mistakes" made include our history of expanding the problem being solved from being a focused one, to a large set of unrelated issues, resulting in large documents and years of time spent in the IETF to get published.
You'd think we'd have learned something by now about how not to repeat that.

-hadriel