Subject: [sipcore] IPv6 in the sip core wg

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 6 Dec 2013 14:20:17 +0100

Hi!

Coming back to an earlier discussion, it seemed to me that we had a few people that supported adding IPv6 dual stack issues to the charter of this wg - if it's not in there already. 

I would like to propose that we add this to the charter and that we plan a meeting at the IETF in London to discuss this and happy eyeballs issues.

We have two drafts in the pipeline and one that should have been written about the actual happy eyeballs connection setup, but currently only exists as promiseware...

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Dec 2013 12:28:46 -0500

Olle,

Yes, this is something it seems evident we should take on.
I don't believe we need to change the "charter", but we should add a 
milestone for this.

If you would like to propose milestone text (in the same style as the 
existing milestones) and take a first guess at a date for it, that would 
be great.

Now that we have this, and some other things, that are on the table we 
are planning on having a sipcore session in London. This will be one (or 
more) of the agenda items for that meeting.

	Thanks,
	Paul

On 12/6/13 8:20 AM, Olle E. Johansson wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 10 Dec 2013 04:49:37 +0000

Paul - 

On Dec 6, 2013, at 12:28 PM, Paul Kyzivat <[email-masked]> wrote:

> I don't believe we need to change the "charter", but we should add a milestone for this.
> 
> If you would like to propose milestone text (in the same style as the existing milestones) and take a first guess at a date for it, that would be great.

How about:

Apr 2014  Amended procedures for dual-stack server handling of SIP URIs containing domain names

> 
> Now that we have this, and some other things, that are on the table we are planning on having a sipcore session in London. This will be one (or more) of the agenda items for that meeting.

Sounds good.

Gonzalo

---

From: Mary Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 09:19:02 -0600

On Mon, Dec 9, 2013 at 10:49 PM, Gonzalo Salgueiro (gsalguei) <
[email-masked]> wrote:

> existing milestones) and take a first guess at a date for it, that would be
> great.
>
> How about:
>
[MB] I would suggest to just use the term "Updated" as opposed to "Amended".
While all of our dates are always optimistic, I think June 2014 is probably
beyond the usually level of optimism, since that's the date for the doc to
go to the IESG.   It often takes at least 2 months to get a doc from WGLC
to ready for IESG review.  That would mean the document completes WGLC in
February 2014.  If you think that's possible, then April is fine, but I
would anticipate that it could take a tad longer.
[/MB]

> >> Coming back to an earlier discussion, it seemed to me that we had a few
> people that supported adding IPv6 dual stack issues to the charter of this
> wg - if it's not in there already.
> >>
> >> I would like to propose that we add this to the charter and that we
> plan a meeting at the IETF in London to discuss this and happy eyeballs
> issues.
> >>
> >> We have two drafts in the pipeline and one that should have been
> written about the actual happy eyeballs connection setup, but currently
> only exists as promiseware...
> >>
> >> /O

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Dec 2013 11:59:26 -0500

Gonzalo,

Mary made the comment on schedule before I got the chance. :-)

June is between the London meeting and the Toronto meeting. Its a 
reasonable time if we we have substantial agreement coming out of the 
London meeting. If we need another meeting cycle, then of course it will 
take longer.

I don't yet have a sense how much controversy and debate there might be 
on this subject. For now I'm ok with a June date. (They don't hang us 
for missing dates.)

So does the following work for you?

     June 2014  Updated procedures for dual-stack server handling of SIP
     URIs containing domain names

	Thanks,
	Paul

On 12/10/13 10:19 AM, Mary Barnes wrote:
> On Mon, Dec 9, 2013 at 10:49 PM, Gonzalo Salgueiro (gsalguei)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Paul -
>
>     On Dec 6, 2013, at 12:28 PM, Paul Kyzivat <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>      > Olle,
>      >
>      > If you would like to propose milestone text (in the same style as
>     the existing milestones) and take a first guess at a date for it,
>     that would be great.
>
>     How about:
>
> While all of our dates are always optimistic, I think June 2014 is
> probably beyond the usually level of optimism, since that's the date for
> the doc to go to the IESG.   It often takes at least 2 months to get a
> doc from WGLC to ready for IESG review.  That would mean the document
> completes WGLC in February 2014.  If you think that's possible, then
> April is fine, but I would anticipate that it could take a tad longer.
> [/MB]
>
>
>      >
>      > Now that we have this, and some other things, that are on the
>     table we are planning on having a sipcore session in London. This
>     will be one (or more) of the agenda items for that meeting.
>
>     Sounds good.
>
>     Gonzalo
>
>      >
>      >       Thanks,
>      >       Paul
>      >
>      >> Coming back to an earlier discussion, it seemed to me that we
>     had a few people that supported adding IPv6 dual stack issues to the
>     charter of this wg - if it's not in there already.
>      >>
>      >> I would like to propose that we add this to the charter and that
>     we plan a meeting at the IETF in London to discuss this and happy
>     eyeballs issues.
>      >>
>     written about the actual happy eyeballs connection setup, but
>     currently only exists as promiseware...
>      >>
>      >> /O
>      >> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 10 Dec 2013 17:08:49 +0000

Hi Mary - 

Agree with both points raised. Thanks.

Gonzalo

On Dec 10, 2013, at 10:19 AM, Mary Barnes <[email-masked]> wrote:

> On Mon, Dec 9, 2013 at 10:49 PM, Gonzalo Salgueiro (gsalguei) <[email-masked]> wrote:
> Paul -
> 
> While all of our dates are always optimistic, I think June 2014 is probably beyond the usually level of optimism, since that's the date for the doc to go to the IESG.   It often takes at least 2 months to get a doc from WGLC to ready for IESG review.  That would mean the document completes WGLC in February 2014.  If you think that's possible, then April is fine, but I would anticipate that it could take a tad longer. 
> [/MB] 
> 
> >

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 10 Dec 2013 17:08:58 +0000

Works for me. 

BTW - I¹m perfectly fine if we want to be conservative and push the
milestone deadline out further, if that is desirable. If we get it done
prior, then all the better.

Gonzalo

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 Dec 2013 10:14:01 -0700

>    URIs containing domain names

Before we use update, can someone tell me what normative text of the current RFCs need to be changed?

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 10 Dec 2013 14:21:22 -0500

> Before we use update, can someone tell me what normative text of the current RFCs need to be changed?

That's part of the problem, RFC 3263 is not very clear to me in indicating what exactly is normative. If you read our draft, you will see that we point to a few sections that clearly says that a UA needs to look up "A or AAAA" records, which has been proven wrong and doesn't follow the intention of the DNS SRV RFC. If this was unintentional or normative, I don't know, but it's written enough times to cause issues in implementations and have been copied to other documents, like the MSRP RFC.

We need to clarify that a SIP implementation needs to follow the DNS SRV RFC and look up all addresses for a host name (ipv4, IPv6 or future address families) and test them all before moving to the next priority and host.

I've checked this with members of the IETF DNS directorate two times now, and they agree with this.

When we clarified/updated/extended/informed the audience - developers - about this, we need to get down to how to connect - serially, in parallell, in reverse random order controlled by the phases of the moon or other planets - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs like in HTTP would not work unless we have both A and AAAA records. RFC 3263 doesn't really indicate that.

Someone else needs to help out to clarify to me what is really normative in 3263 and what the relationship between 3263 and RFC 2782 really is - if RFC 2782 is the normative one and RFC 3263 just can be seen as a happy story that points to 2782 without making any normative changes, we might have to clarify that in an informational document and move on to connection setup in a dual stack world. If RFC 3263 changes the behaviour intended by 2782 and really forces a developer to select A or AAAA records, then we need to change that behaviour.

Either way, we have work to do in ths wg.
/O

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 Dec 2013 16:13:08 -0700

Well from a milestone point of view there is a big difference between we need the change an existing RFC (i.e. update) or we need to define a new RFC that tells developers who want to implement the new RFC what they need to do. 

I think what is needed here is the later item and not the update. I have asked about this a bunch of times and and I always get answers that suggest that a new document is needed but it does not need to replace or update 3263. It needs to be a new document that provides more detailed advice. If we are going to say this updates something, I want to be convinced first that there is something that is wrong and needs to be changed. I'm fine with the idea that ore detailed specifications are needed to do something like happy eyeballs for SIP but I don't think that requires an update of 3263.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 11 Dec 2013 09:50:42 -0500

> I think what is needed here is the later item and not the update. I have asked about this a bunch of times and and I always get answers that suggest that a new document is needed but it does not ne…

I am fine with a milestone that doesn't say update. If we discover later that an update really is required, we can still add a milestone for that. I just want to get the work started at this point.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Dec 2013 15:49:07 -0500

Cullen,

Would you be satisfied if the milestone is sufficiently vague that we 
can leave it to the deliverable to decide whether an update is needed or 
not?

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Thu, 12 Dec 2013 10:59:44 -0600

The question in my mind becomes how you can word it properly.  There are
already procedures for dual stack, so you can't just say:

Procedures for dual-stack server handling of SIP URIs containing domain
names

Any of the adjectives proposed so far "Amended" or "Updated" or others that
might seem appropriate, e.g., "Enhanced" imply that the existing procedures
are being changed or corrected.  Although maybe "Enhanced" is general
enough to not necessarily imply an "Update" to RFC 3263?   But, then would
you be talking about an Informational versus standards track document?   I
think it's usual for milestones to indicate whether the work is
informational, standards track or BCP.  But, if the AD will approve the new
milestone without that level of specificity, that's fine. But, I also don't
think it's useful for the group to rathole on that later in the process and
it will definitely cause confusion if the WG doesn't have a clear reason
why the specific type of specification was selected.

Regards,
Mary.

On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat <[email-masked]> wrote:

> Cullen,
>
> Would you be satisfied if the milestone is sufficiently vague that we can
> leave it to the deliverable to decide whether an update is needed or not?
>
>         Thanks,
>         Paul
>
>
>> Well from a milestone point of view there is a big difference between we
>> need the change an existing RFC (i.e. update) or we need to define a new
>> RFC that tells developers who want to implement the new RFC what they need
>> to do.
>>
>> I think what is needed here is the later item and not the update. I have
>> asked about this a bunch of times and and I always get answers that suggest
>> that a new document is needed but it does not need to replace or update
>> 3263. It needs to be a new document that provides more detailed advice. If
>> we are going to say this updates something, I want to be convinced first
>> that there is something that is wrong and needs to be changed. I'm fine
>> with the idea that ore detailed specifications are needed to do something
>> like happy eyeballs for SIP but I don't think that requires an update of
>> 3263.
>>
>>
>>> That's part of the problem, RFC 3263 is not very clear to me in
>>> indicating what exactly is normative. If you read our draft, you will see
>>> that we point to a few sections that clearly says that a UA needs to look
>>> up "A or AAAA" records, which has been proven wrong and doesn't follow the
>>> intention of the DNS SRV RFC. If this was unintentional or normative, I
>>> don't know, but it's written enough times to cause issues in
>>> implementations and have been copied to other documents, like the MSRP RFC.
>>>
>>> We need to clarify that a SIP implementation needs to follow the DNS SRV
>>> RFC and look up all addresses for a host name (ipv4, IPv6 or future address
>>> families) and test them all before moving to the next priority and host.
>>>
>>> When we clarified/updated/extended/informed the audience - developers -
>>> about this, we need to get down to how to connect - serially, in parallell,
>>> in reverse random order controlled by the phases of the moon or other
>>> planets - or simply Happy Eyeballs. But even with TCP, doing happy eyeballs
>>> like in HTTP would not work unless we have both A and AAAA records. RFC
>>> 3263 doesn't really indicate that.
>>>
>>> Someone else needs to help out to clarify to me what is really normative
>>> in 3263 and what the relationship between 3263 and RFC 2782 really is - if
>>> RFC 2782 is the normative one and RFC 3263 just can be seen as a happy
>>> story that points to 2782 without making any normative changes, we might
>>> have to clarify that in an informational document and move on to connection
>>> setup in a dual stack world. If RFC 3263 changes the behaviour intended by
>>> 2782 and really forces a developer to select A or AAAA records, then we
>>> need to change that behaviour.
>>>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 12 Dec 2013 17:21:37 +0000

Normative procedure are being prescribed, so it is undoubtedly Standards Track IMO. Enhanced/Improved/Refined all seem fine to me and don't imply that this work formally updates 3263.  That is a discussion detail we can have once we actually have some concrete text adopted and the WG can weigh in with their preference. 

Gonzalo

On Dec 12, 2013, at 11:59 AM, Mary Barnes <[email-masked]> wrote:

> The question in my mind becomes how you can word it properly.  There are already procedures for dual stack, so you can't just say:
> 
> Procedures for dual-stack server handling of SIP URIs containing domain names
> 
> Any of the adjectives proposed so far "Amended" or "Updated" or others that might seem appropriate, e.g., "Enhanced" imply that the existing procedures are being changed or corrected.  Although maybe "Enhanced" is general enough to not necessarily imply an "Update" to RFC 3263?   But, then would you be talking about an Informational versus standards track document?   I think it's usual for milestones to indicate whether the work is informational, standards track or BCP.  But, if the AD will approve the new milestone without that level of specificity, that's fine. But, I also don't think it's useful for the group to rathole on that later in the process and it will definitely cause confusion if the WG doesn't have a clear reason why the specific type of specification was selected.
> 
> Regards,
> Mary. 
> 
> 
> 
> Would you be satisfied if the milestone is sufficiently vague that we can leave it to the deliverable to decide whether an update is needed or not?
> 
>         Thanks,
>         Paul
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Dec 2013 12:59:44 -0500

On 12/12/13 11:59 AM, Mary Barnes wrote:
> Any of the adjectives proposed so far "Amended" or "Updated" or others
> that might seem appropriate, e.g., "Enhanced" imply that the existing
> procedures are being changed or corrected.  Although maybe "Enhanced" is
> general enough to not necessarily imply an "Update" to RFC 3263?   But,
> then would you be talking about an Informational versus standards track
> document?   I think it's usual for milestones to indicate whether the
> work is informational, standards track or BCP.  But, if the AD will
> approve the new milestone without that level of specificity, that's
> fine.

ISTM that we are in a situation where we need to consider the details of 
the proposed mechanism(s) before deciding if the desired mechanism will 
be an update or not. So I think it makes sense to word the milestone to 
be non-specific about this.

Maybe its not the term itself that is the problem, but rather what the 
term references. IOW, is it that we intend to 
ammend/update/enhance/improve the *procedures*, or the *description* of 
the procedures?

IIUC the intent is to clarify the description, and if that is 
insufficient to get a satisfactory result, then to update the procedures 
themselves.

	Thanks,
	Paul

> But, I also don't think it's useful for the group to rathole on
> that later in the process and it will definitely cause confusion if the
> WG doesn't have a clear reason why the specific type of specification
> was selected.
>
> Regards,
> Mary.
>
>
>
> On Wed, Dec 11, 2013 at 2:49 PM, Paul Kyzivat <[email-masked]
>     Would you be satisfied if the milestone is sufficiently vague that
>     we can leave it to the deliverable to decide whether an update is
>     needed or not?
>
>              Thanks,
>              Paul
>
>
>         Well from a milestone point of view there is a big difference
>         between we need the change an existing RFC (i.e. update) or we
>         need to define a new RFC that tells developers who want to
>         implement the new RFC what they need to do.
>
>         I think what is needed here is the later item and not the
>         update. I have asked about this a bunch of times and and I
>         always get answers that suggest that a new document is needed
>         but it does not need to replace or update 3263. It needs to be a
>         new document that provides more detailed advice. If we are going
>         to say this updates something, I want to be convinced first that
>         there is something that is wrong and needs to be changed. I'm
>         fine with the idea that ore detailed specifications are needed
>         to do something like happy eyeballs for SIP but I don't think
>         that requires an update of 3263.
>
>
>         On Dec 10, 2013, at 12:21 PM, Olle E. Johansson <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>
>             On 10 Dec 2013, at 12:14, Cullen Jennings <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>
>                 On Dec 10, 2013, at 9:59 AM, Paul Kyzivat
>                 <[email-masked] <mailto:[email-masked]>>
>                 wrote:
>
>                 Before we use update, can someone tell me what normative
>                 text of the current RFCs need to be changed?
>
>
>             That's part of the problem, RFC 3263 is not very clear to me
>             in indicating what exactly is normative. If you read our
>             draft, you will see that we point to a few sections that
>             clearly says that a UA needs to look up "A or AAAA" records,
>             which has been proven wrong and doesn't follow the intention
>             of the DNS SRV RFC. If this was unintentional or normative,
>             I don't know, but it's written enough times to cause issues
>             in implementations and have been copied to other documents,
>             like the MSRP RFC.
>
>             We need to clarify that a SIP implementation needs to follow
>             the DNS SRV RFC and look up all addresses for a host name
>             (ipv4, IPv6 or future address families) and test them all
>             before moving to the next priority and host.
>
>             When we clarified/updated/extended/__informed the audience -
>             developers - about this, we need to get down to how to
>             connect - serially, in parallell, in reverse random order
>             controlled by the phases of the moon or other planets - or
>             simply Happy Eyeballs. But even with TCP, doing happy
>             eyeballs like in HTTP would not work unless we have both A
>             and AAAA records. RFC 3263 doesn't really indicate that.
>
>             Someone else needs to help out to clarify to me what is
>             really normative in 3263 and what the relationship between
>             3263 and RFC 2782 really is - if RFC 2782 is the normative
>             one and RFC 3263 just can be seen as a happy story that
>             points to 2782 without making any normative changes, we
>             might have to clarify that in an informational document and
>             move on to connection setup in a dual stack world. If RFC
>             3263 changes the behaviour intended by 2782 and really
>             forces a developer to select A or AAAA records, then we need
>             to change that behaviour.
>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 12 Dec 2013 19:18:54 +0000

On Dec 12, 2013, at 12:59 PM, Paul Kyzivat <[email-masked]> wrote:

> ISTM that we are in a situation where we need to consider the details of the proposed mechanism(s) before deciding if the desired mechanism will be an update or not. So I think it makes sense to word the milestone to be non-specific about this.
> 
> Maybe its not the term itself that is the problem, but rather what the term references. IOW, is it that we intend to ammend/update/enhance/improve the *procedures*, or the *description* of the procedures?
> 
> IIUC the intent is to clarify the description, and if that is insufficient to get a satisfactory result, then to update the procedures themselves.

So what is the proposed text for the milestone?

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 12 Dec 2013 21:45:51 +0000

I was losing track of this discussion so I had to go back.

The only document we seem to have on the table at the moment is:

http://www.ietf.org/id/draft-johansson-sip-dual-stack-01.txt

This currently contains no normative provisions (no MUST, SHOULD, MAY) so it is a bit difficult to judge what the scope of a normative document should be.

Could I suggest that before we scope the work and as a consequence write the milestone, we see another version of the author draft containing at least the minimum set of normative requirements the authors think we need.

That may be because it is written in the style of RFC 3263 which also contains no normative provisions. It might be that in order to scope this work we actually need a bis version of RFC 3263, rather than something that adds some more requirements in this area.

In response to Cullen, I would say there is another reason why something should be an update rather than just being regarded as an extension. If it contains provisions that all RFC 3263 implementations (or most of) should also implement, and it is within the scope of the original RFC, then I believe that may also justify and update. But I agree that we need to write the requirements first and then do this analysis.

I'd also remind you that Vijay has some comments that the issue was wider than RFC 3263, so there may be a need to scope round that.

None of these comments should be taken as a suggestion that we should not do the work (I think the issue has been justified), only that I do not understand the scope and there is not enough on the table to judge that.

Keith

> -----Original Message-----
> From: sipcore [mailto:[email-masked]] On Behalf Of 
> Gonzalo Salgueiro (gsalguei)
> Sent: 12 December 2013 19:19
> To: Paul Kyzivat
> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro 
> (gsalguei); Cullen Jennings
> Subject: Re: [sipcore] IPv6 in the sip core wg
> Importance: High
> 
> 
> >> The question in my mind becomes how you can word it 
> properly.  There 
> >> are already procedures for dual stack, so you can't just say:
> >> 
> >> Any of the adjectives proposed so far "Amended" or "Updated" or 
> >> others that might seem appropriate, e.g., "Enhanced" imply 
> that the 
> >> existing procedures are being changed or corrected.  
> Although maybe "Enhanced" is
> > ISTM that we are in a situation where we need to consider 
> the details of the proposed mechanism(s) before deciding if 
> the desired mechanism will be an update or not. So I think it 
> makes sense to word the milestone to be non-specific about this.
> > 
> > Maybe its not the term itself that is the problem, but 
> rather what the term references. IOW, is it that we intend to 
> ammend/update/enhance/improve the *procedures*, or the 
> *description* of the procedures?
> > 
> > IIUC the intent is to clarify the description, and if that 
> is insufficient to get a satisfactory result, then to update 
> the procedures themselves.
> 
> >> But, I also don't think it's useful for the group to 
> rathole on that 
> >> later in the process and it will definitely cause 
> confusion if the WG 
> >> doesn't have a clear reason why the specific type of specification 
> >> was selected.
> >> 
> >> Regards,
> >> Mary.
> >> 
> >> 
> >> 
> >>                    June 2014  Updated procedures for 
> dual-stack server
> >>                    handling of SIP
> >>            I've checked this with members of the IETF DNS 
> directorate
> >>            two times now, and they agree with this.
> >>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 12 Dec 2013 17:21:26 -0700

> I am fine with a milestone that doesn't say update. If we discover later that an update really is required, we can still add a milestone for that. I just want to get the work started at this point.

That sounds reasonable way forward but when I read draft-johansson-sip-dual-stack, I don't think the things it claims are a change to 3263 actually are a change. 

I'm fine this a new RFC that tells you how to do the things in the happy eye balls way, but that does not need to update 3261. Nothing in 3263 says lookups can't be tried in parallel and the this can just be a new RFC.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 13 Dec 2013 00:54:10 +0000

(as co-author)

I'm happy to publish a new version of the document that makes use of 2119 language.  

I think we might be trying to over-complicate matters. As stated earlier, this work is merely an extension to the procedures in 3263 and should not make the myriad existing deployments non-compliant to a core SIP specification. The intent here is only to provide supplemental best practices that we have learned along the way through extensive interop testing. To emblazon this point into everyone's psyche, the next version will not have the "Updates: 3263 (if approved)" label.

With this in mind, I propose the following as the milestone text:

Supplemental procedures for dual-stack server handling of SIP URIs containing domain names

To your point regarding Vijay, the authors will stay in sync with him throughout.

Cheers,

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Dec 2013 01:04:24 +0000

Lets look at the specification.

Your mail seems to being its best to justify it as a BCP, which I assume is not what you intend.

Keith 

> From: Gonzalo Salgueiro (gsalguei) [mailto:[email-masked]] 
> Sent: 13 December 2013 00:54
> To: DRAGE, Keith (Keith)
> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE WG; 
> Olle E. Johansson; Cullen Jennings
> I think we might be trying to over-complicate matters. As 
> stated earlier, this work is merely an extension to the 
> procedures in 3263 and should not make the myriad existing 
> deployments non-compliant to a core SIP specification. The 
> intent here is only to provide supplemental best practices 
> that we have learned along the way through extensive interop 
> testing. To emblazon this point into everyone's psyche, the 
> next version will not have the "Updates: 3263 (if approved)" label.
> 
> > This currently contains no normative provisions (no MUST, 
> SHOULD, MAY) so it is a bit difficult to judge what the scope 
> of a normative document should be.
> > 
> > Could I suggest that before we scope the work and as a 
> consequence write the milestone, we see another version of 
> the author draft containing at least the minimum set of 
> normative requirements the authors think we need.
> > 
> > That may be because it is written in the style of RFC 3263 
> which also contains no normative provisions. It might be that 
> in order to scope this work we actually need a bis version of 
> RFC 3263, rather than something that adds some more 
> requirements in this area.
> > 
> > In response to Cullen, I would say there is another reason 
> why something should be an update rather than just being 
> regarded as an extension. If it contains provisions that all 
> RFC 3263 implementations (or most of) should also implement, 
> and it is within the scope of the original RFC, then I 
> believe that may also justify and update. But I agree that we 
> need to write the requirements first and then do this analysis.
> > 
> > I'd also remind you that Vijay has some comments that the 
> issue was wider than RFC 3263, so there may be a need to 
> scope round that.
> > 
> > None of these comments should be taken as a suggestion that 
> we should not do the work (I think the issue has been 
> justified), only that I do not understand the scope and there 
> is not enough on the table to judge that.
> > 
> > Keith
> > 
> > 
> > 
> >> From: sipcore [mailto:[email-masked]] On Behalf 
> Of Gonzalo 
> >> Salgueiro (gsalguei)
> >> Cc: SIPCORE WG; Olle E. Johansson; Gonzalo Salgueiro (gsalguei); 
> >> Cullen Jennings
> >> the details of the proposed mechanism(s) before deciding if the 
> >> desired mechanism will be an update or not. So I think it 
> makes sense 
> >> to word the milestone to be non-specific about this.
> >>> 
> >> is insufficient to get a satisfactory result, then to update the 
> >> procedures themselves.
> >>

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 13 Dec 2013 01:07:45 +0000

> Your mail seems to being its best to justify it as a BCP, which I assume is not what you intend.

You're right, t is not at all my intent.  What I intend is to provide a stand-alone RFC that provides some useful supplemental procedures for improved performance in SIP dual-stack environments.

Gonzalo

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Dec 2013 11:17:01 -0500

> I'm fine this a new RFC that tells you how to do the things in the happy eye balls way, but that does not need to update 3261. Nothing in 3263 says lookups can't be tried in parallel and the this c…
The problem is really that RFC 3263 repeats "A or AAAA" - which means that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 addresses to connect to. I have not claimed that it talks about how we connect.

It seems like no one can say whether this text is normative or not, which really means we have to clarify this, since developers will be (or already am) confused on how to implement properly.

/O

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Dec 2013 10:26:34 -0600

On 12/13/2013 10:17 AM, Olle E. Johansson wrote:
> The problem is really that RFC 3263 repeats "A or AAAA" - which means
> that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6
> addresses to connect to. I have not claimed that it talks about how
> we connect.

I am sorry to keep interjecting rfc6157 here, but it does say to perform
name lookup using getaddrinfo(), which, if rfc3484 is adhered to will
produce an ordered list of IPv6/IPv4 destination addresses.

> It seems like no one can say whether this text is normative or not,
> which really means we have to clarify this, since developers will be
> (or already am) confused on how to implement properly.

Sure, rfc6157 does not update rfc3263 so this point may be lost in the
noise.  To be sure, I am not against adding a milestone to better
specify this behaviour; all I am pointing out is that more than rfc3263
may be impacted.

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Dec 2013 11:28:22 -0500

> You're right, t is not at all my intent.  What I intend is to provide a stand-alone RFC that provides some useful supplemental procedures for improved performance in SIP dual-stack environments.

If these procedures are supplemental, will there be anything that should 
be normative?

Contrary to what Keith said, I do find normative language in the draft 
now. (A SHOULD in the last paragraph of 3.1.) And this is a change to 
language in 3263 - changing "A or AAAA" to "A and AAAA".

It is arguable whether this has normative impact on existing 
implementations of 3263. 3263 has no normative language regarding "A or 
AAAA", but it does have normative language ("SHOULD") about how to use 
the results of the lookup. I think it can be viewed as a normative 
change to 3263 for dual stack devices.

And 3263 suffers from the common problem of using "SHOULD" widely 
without any explanation of when it makes sense to violate the "SHOULD". 
This gives people the opportunity to say that implementations that do 
otherwise are still compliant. I would be uncomfortable publishing a new 
normative RFC that doesn't say it updates 3263 while mandating behavior 
that is different from the SHOULDs of 3263.

Having said that, I suggest the following as the milestone:

     May 2014  WGLC of procedures to supplement RFC3263 for dual-stack
     client and server handling of SIP URIs containing domain names (PS)

This assumes that the work will be standards track, but doesn't say 
whether or not it will update 3263. I've made the milestone to be for 
WGLC, so we take the time for IESG processing out of the schedule. The 
date is after the London meeting but before the Toronto meeting. It is 
assuming that we will get much of the work done on the mailing list 
before London, thrash out any controversial issues in London, then do 
cleanup and WGLC. It is optimistic, but possible if there isn't a lot if 
dissent.

Richard - does this work for you?

Olle & Gonzalo - does it work for you?

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Dec 2013 11:34:41 -0500

> You're right, t is not at all my intent.  What I intend is to provide a stand-alone RFC that provides some useful supplemental procedures for improved performance in SIP dual-stack environments.

Yes, we need to help developers with a specification that makes SIP work properly in dual stack environments.

Whether or not it's an update to another RFC is nothing I can judge, I was told to add the update statement earlier on and just did so. At this point, I have no opinion about that part, but really want us to write specs so that
we can build working implementations. RFC 3263 alone doesn't help in doing that, so we clearly
need to add a new document to the series, update our code and test at SIPit. :-)

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 13 Dec 2013 12:19:30 -0500

Vijay,

> produce an ordered list of IPv6/IPv4 destination addresses.

It's ok to keep bringing it up, because it seems to be relevant.

I just glanced through it to refresh my memory. It seems to cover, at 
least implicitly, some of the same scope. But that part of the draft 
appears to have been somewhat of an afterthought.

I find the following problematic:

"IPv6-only or dual-stack clients MUST use the newer getaddrinfo() name 
lookup function, instead of gethostbyname()."

It is a normative statement to use a particular API function as an 
alternative to a different API function. But there was never a 
requirement to use "gethostbyname", so the "instead" isn't meaningful, 
and we shouldn't be requiring use of any particular API functions. It 
would make a lot more sense if it had a MUST on the algorithms in 3484.

(I no doubt participated in the WGLC on this document, so I have only 
myself to blame for not complaining about this earlier.)

Since that is now an RFC, I guess we should assume that people will "do 
the right thing" if those APIs don't work for them, and follow the 
intent of the RFC.

> specify this behaviour; all I am pointing out is that more than rfc3263

At the very least, we should include that in the scope of the work.
Here is a revised milestone:

     May 2014  WGLC of procedures to supplement RFC3263 and RFC6157 for
     dual-stack client and server handling of SIP URIs containing domain
     names (PS)

	Thanks,
	Paul

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Fri, 13 Dec 2013 17:22:10 +0000

On Dec 13, 2013, at 11:28 AM, Paul Kyzivat <[email-masked]> wrote:

> If these procedures are supplemental, will there be anything that should be normative?
> 
> Contrary to what Keith said, I do find normative language in the draft now. (A SHOULD in the last paragraph of 3.1.) And this is a change to language in 3263 - changing "A or AAAA" to "A and AAAA".
> 
> It is arguable whether this has normative impact on existing implementations of 3263. 3263 has no normative language regarding "A or AAAA", but it does have normative language ("SHOULD") about how to use the results of the lookup. I think it can be viewed as a normative change to 3263 for dual stack devices.
> 
> And 3263 suffers from the common problem of using "SHOULD" widely without any explanation of when it makes sense to violate the "SHOULD". This gives people the opportunity to say that implementations that do otherwise are still compliant. I would be uncomfortable publishing a new normative RFC that doesn't say it updates 3263 while mandating behavior that is different from the SHOULDs of 3263.
> 
> This assumes that the work will be standards track, but doesn't say whether or not it will update 3263. I've made the milestone to be for WGLC, so we take the time for IESG processing out of the schedule. The date is after the London meeting but before the Toronto meeting. It is assuming that we will get much of the work done on the mailing list before London, thrash out any controversial issues in London, then do cleanup and WGLC. It is optimistic, but possible if there isn't a lot if dissent.
> 

I'm ok with it.  

The authors will make some changes to the current version of the document and submit a new version that hopefully makes clearer the original intent: a stand-alone RFC offering improved procedures for dual-stack environments (i.e., does not invalidate or render non-compliant the myriad of 3263 implementations out there that work fine with v6).

Gonzalo

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 13 Dec 2013 17:26:48 +0000

Yes, I've found the SHOULD now in the draft. Mozilla did one of its tricks on me and as a result I was searching for the wrong things.

I agree with your comment on 3263 in regard to the use of SHOULD. It does contain normative provisions, but they are substantially SHOULD requirements with no additional guidance.

I could not find anything in RFC 3263 than mandated in any form the use of A versus AAAA, eithewr together or separately.

On that basis it adds rather than updates. But there may be other requirements that come out of the discussion.

But Vijay keeps mentioning RFC 6157 so I had a look and there it states:

   "IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses
   using the ICE procedures to generate all their offers.  This way,
   both IPv4-only and IPv6-only answerers will be able to generate a
   mutually acceptable answer that establishes a session (having used
   ICE to gather both IPv4 and IPv6 addresses in the offer reduces the
   session establishment time because all answerers will find the offer
   valid.)

      Implementations are encouraged to use ICE; however, the normative
      strength of the text above is left at a SHOULD since in some
      managed networks (such as a closed enterprise network) it is
      possible for the administrator to have control over the IP version
      utilized in all nodes and thus deploy an IPv6-only network, for
      example.  The use of ICE can be avoided for signaling messages
      that stay within such managed networks."

So is that not pretty much saying the same thing as:

  "A dual-stack client SHOULD perform an A and AAAA record lookup of the
   domain name and add the respective IPv4/IPv6 addresses to the list of
   IP addresses to be contacted."

Certainly, if something is missing, we may well be talking about something that updates RFC 6157 rather than RFC 3263.

In regards to your milestone proposal, I do not understand:

"so we take the time for IESG processing out of the schedule"

"to WGLC" is to the start of WGLC
"to IESG" is the publication request

Neither milestone would include IESG processing.

A possible different milestone wording would be "Use of RFC 3263 in dual-stack devices". I would like to get rid of the word "supplement". We'd need to see if that requires changing based on Vijay's input.

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 13 December 2013 16:28
> To: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith)
> Cc: SIPCORE WG; Olle E. Johansson; Cullen Jennings
> > You're right, t is not at all my intent.  What I intend is 
> to provide a stand-alone RFC that provides some useful 
> supplemental procedures for improved performance in SIP 
> dual-stack environments.
> 
> Contrary to what Keith said, I do find normative language in 
> the draft now. (A SHOULD in the last paragraph of 3.1.) And 
> this is a change to language in 3263 - changing "A or AAAA" 
> to "A and AAAA".
> 
> implementations of 3263. 3263 has no normative language 
> regarding "A or AAAA", but it does have normative language 
> ("SHOULD") about how to use the results of the lookup. I 
> think it can be viewed as a normative change to 3263 for dual 
> stack devices.
> 
> And 3263 suffers from the common problem of using "SHOULD" 
> widely without any explanation of when it makes sense to 
> violate the "SHOULD". 
> This gives people the opportunity to say that implementations 
> that do otherwise are still compliant. I would be 
> uncomfortable publishing a new normative RFC that doesn't say 
> it updates 3263 while mandating behavior that is different 
> from the SHOULDs of 3263.
> 
> This assumes that the work will be standards track, but 
> doesn't say whether or not it will update 3263. I've made the 
> milestone to be for WGLC, so we take the time for IESG 
> processing out of the schedule. The date is after the London 
> meeting but before the Toronto meeting. It is assuming that 
> we will get much of the work done on the mailing list before 
> London, thrash out any controversial issues in London, then 
> do cleanup and WGLC. It is optimistic, but possible if there 
> isn't a lot if dissent.
> 
> >>> Cc: Paul Kyzivat; Gonzalo Salgueiro (gsalguei); SIPCORE 
> WG; Olle E. 
> >>> Johansson; Cullen Jennings
> >>> I'm happy to publish a new version of the document that 
> makes use of 
> >>> 2119 language.
> >>>
> >>> I think we might be trying to over-complicate matters. As stated 
> >>> earlier, this work is merely an extension to the 
> procedures in 3263 
> >>> and should not make the myriad existing deployments 
> non-compliant to 
> >>> a core SIP specification. The intent here is only to provide 
> >>> supplemental best practices that we have learned along the way 
> >>> through extensive interop testing. To emblazon this point into 
> >>> everyone's psyche, the next version will not have the 
> "Updates: 3263 
> >>> (if approved)" label.
> >>>
> >>> Supplemental procedures for dual-stack server handling of 
> SIP URIs 
> >>> containing domain names
> >>>
> >>>
> >>> SHOULD, MAY) so it is a bit difficult to judge what the 
> scope of a 
> >>> normative document should be.
> >>>>
> >>> consequence write the milestone, we see another version of the 
> >>> author draft containing at least the minimum set of normative 
> >>> requirements the authors think we need.
> >>>>
> >>> which also contains no normative provisions. It might be that in 
> >>> order to scope this work we actually need a bis version 
> of RFC 3263, 
> >>> rather than something that adds some more requirements in 
> this area.
> >>>>
> regarded as 
> >>> an extension. If it contains provisions that all RFC 3263 
> >>> implementations (or most of) should also implement, and 
> it is within 
> >>> the scope of the original RFC, then I believe that may 
> also justify 
> >>> and update. But I agree that we need to write the 
> requirements first 
> >>> and then do this analysis.
> >>>>
> scope round 
> >>> that.
> >>> we should not do the work (I think the issue has been justified), 
> >>> only that I do not understand the scope and there is not 
> enough on 
> >>> the table to judge that.
> >>>>
> >>>> Keith
> >>>>
> >>>>
> >>>>
> >>>>> On Dec 12, 2013, at 12:59 PM, Paul Kyzivat 
> <[email-masked]>
> >>>>> wrote:
> >>>>>
> >>>>>>> Procedures for dual-stack server handling of SIP URIs 
> containing 
> >>>>>>> domain names
> >>>>>>>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 13 Dec 2013 12:31:57 -0500

>> Olle & Gonzalo - does it work for you?
+1

/O

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Dec 2013 11:35:11 -0600

On 12/13/2013 11:19 AM, Paul Kyzivat wrote:
[...]
> would make a lot more sense if it had a MUST on the algorithms in 3484.

Paul: No doubt true from specifying text in a standards-track RFC, but
I suspect that most implementors are much more familiar with the
differences between gethostbyname() and getaddrinfo() than they
are with the arcana that getaddrinfo() implements rfc3484.

[...]
>      dual-stack client and server handling of SIP URIs containing domain

Works for me.  Thanks for your time, Paul.

Cheers,

- vijay

---

From: Mary Barnes <[email-masked]>
Date: Fri, 13 Dec 2013 11:43:12 -0600

On Fri, Dec 13, 2013 at 10:28 AM, Paul Kyzivat <[email-masked]>wrote:

>> You're right, t is not at all my intent.  What I intend is to provide a
>> stand-alone RFC that provides some useful supplemental procedures for
>> improved performance in SIP dual-stack environments.
>>
>
> AAAA", but it does have normative language ("SHOULD") about how to use the
> results of the lookup. I think it can be viewed as a normative change to
> 3263 for dual stack devices.
>
> And 3263 suffers from the common problem of using "SHOULD" widely without
> any explanation of when it makes sense to violate the "SHOULD". This gives
> people the opportunity to say that implementations that do otherwise are
> still compliant. I would be uncomfortable publishing a new normative RFC
> that doesn't say it updates 3263 while mandating behavior that is different
> whether or not it will update 3263. I've made the milestone to be for WGLC,
> so we take the time for IESG processing out of the schedule.

[MB] What is the point of taking the time for IESG processing out of the
schedule?   I don't see a problem with stating two milestones, but
milestones in a charter always reflect the target completion of work within
the WG (and that's NOT WGLC).  There was a period of time where the ADs
wanted to see the two milestones, so that's certainly not an unacceptable
thing to do, but not listing the IESG milestone isn't normal procedure.
 RFC 2418 explains some of this.   As I said in a previous note, in my
experience, two months is an optimistic average for the time between
completing a 1st WGLC and a doc going to the IESG.   [/MB]

> The date is after the London meeting but before the Toronto meeting. It is
> assuming that we will get much of the work done on the mailing list before
> London, thrash out any controversial issues in London, then do cleanup and
> WGLC. It is optimistic, but possible if there isn't a lot if dissent.
>

Note, I've delated the remainder of this thread as it's gotten insanely
long.
[MB]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 16 Dec 2013 12:30:58 -0700

> The problem is really that RFC 3263 repeats "A or AAAA" - which means that if we follow RFC 3263 verbatim we won't have both IPv4 and IPv6 addresses to connect to. I have not claimed that it talks…

A or B does not mean you are not allowed to do both

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 16 Dec 2013 19:33:05 +0000

>    client and server handling of SIP URIs containing domain names (PS)

Good with me. And if you want to change "WGLC of" to "Request publication of" that seems like it would fix the point Mary raised.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Dec 2013 14:49:00 -0500

> A or B does not mean you are not allowed to do both

English is vague about this.
It can be read as either OR or XOR.
And that is just when considering use by native English speakers.
When you factor in people for whom English is not native, it is probably 
more dubious which it means.

If there is any concern then we should ensure that this is clarified.
Whether that requires an update may still be controversial. But ISTM if 
we are going to produce a standards track RFC anyway, that it would be 
better to be sure by declaring it to be an update.

If your implementation is already consistent with the clarification, 
then you can immediately claim conformance to it. But advertising it as 
an update may provoke some to discover that they aren't consistent with 
the clarified intent. That will cause them some work to conform, but 
will also fix problems.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Dec 2013 14:50:58 -0500

On 12/13/13 12:43 PM, Mary Barnes wrote:
>
>
>
> On Fri, Dec 13, 2013 at 10:28 AM, Paul Kyzivat <[email-masked]
>         On Dec 12, 2013, at 8:04 PM, DRAGE, Keith (Keith)
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>         You're right, t is not at all my intent.  What I intend is to
>         provide a stand-alone RFC that provides some useful supplemental
>         procedures for improved performance in SIP dual-stack environments.
>
>
>     Contrary to what Keith said, I do find normative language in the
>     draft now. (A SHOULD in the last paragraph of 3.1.) And this is a
>     change to language in 3263 - changing "A or AAAA" to "A and AAAA".
>
>     implementations of 3263. 3263 has no normative language regarding "A
>     or AAAA", but it does have normative language ("SHOULD") about how
>     to use the results of the lookup. I think it can be viewed as a
>     normative change to 3263 for dual stack devices.
>
>     without any explanation of when it makes sense to violate the
>     "SHOULD". This gives people the opportunity to say that
>     implementations that do otherwise are still compliant. I would be
>     uncomfortable publishing a new normative RFC that doesn't say it
>     updates 3263 while mandating behavior that is different from the
>     SHOULDs of 3263.
>
>     whether or not it will update 3263. I've made the milestone to be
>     for WGLC, so we take the time for IESG processing out of the schedule.
>
> milestones in a charter always reflect the target completion of work
> within the WG (and that's NOT WGLC).  There was a period of time where
> the ADs wanted to see the two milestones, so that's certainly not an
> unacceptable thing to do, but not listing the IESG milestone isn't
> normal procedure.  RFC 2418 explains some of this.   As I said in a
> previous note, in my experience, two months is an optimistic average for
> the time between completing a 1st WGLC and a doc going to the IESG.   [/MB]

I will defer to your deeper knowledge of this.

>     The date is after the London meeting but before the Toronto meeting.
>     It is assuming that we will get much of the work done on the mailing
>     list before London, thrash out any controversial issues in London,
>     then do cleanup and WGLC. It is optimistic, but possible if there
>     isn't a lot if dissent.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Dec 2013 14:54:56 -0500

> are with the arcana that getaddrinfo() implements rfc3484.

I would not object to this as an implementation note.
But it doesn't seem like a good way to state the normative requirement.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Dec 2013 15:01:16 -0500

> Good with me. And if you want to change "WGLC of" to "Request publication of" that seems like it would fix the point Mary raised.

OK. Latest candidate is:

     June 2014  Request publication of procedures to supplement RFC3263
     for dual-stack client and server handling of SIP URIs containing
     domain names (PS)

(I put back the extra month for Mary.)

	Thanks,
	Paul

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Dec 2013 15:03:39 -0500

Sounds good to me, though a couple of extra months might not hurt, just in
case.
--Richard

On Mon, Dec 16, 2013 at 3:01 PM, Paul Kyzivat <[email-masked]> wrote:

>> Good with me. And if you want to change "WGLC of" to "Request publication
>> of" that seems like it would fix the point Mary raised.
>>
>
> OK. Latest candidate is:
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Dec 2013 14:13:25 -0600

>      for dual-stack client and server handling of SIP URIs containing

Wait ... Sorry, I thought we had agreed to [1]

with s/May/June

No?

[1] http://www.ietf.org/mail-archive/web/sipcore/current/msg05890.html

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Dec 2013 18:03:17 -0500

>      dual-stack client and server handling of SIP URIs containing domain

Oh, sorry. Trying again - merge of those two:

      June 2014  Request publication of procedures to supplement RFC3263
      and RFC6157 for dual-stack client and server handling of SIP URIs
      containing domain names (PS)

Is that ok Vijay?
Any other complaints?

	Thanks,
	Paul

---

From: Mary Barnes <[email-masked]>
Date: Mon, 16 Dec 2013 17:07:51 -0600

I think that's good - it covers all bases.

Mary.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Dec 2013 08:00:43 -0600

>       containing domain names (PS)

Paul: Works for me.  Thanks for attending to this.

Cheers,

- vijay

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 17 Dec 2013 15:19:02 +0100

> Paul: Works for me.  Thanks for attending to this.
I am fine with this too.

/O

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 17 Dec 2013 23:54:55 +0000

I said in a previous mail that I would like to avoid the use of the word "supplement" and did suggest alternative wording. My reason is that some SDOs treat the word "supplement" as identifying informative material, and given that you want reuse in other SDOs it is best not to confuse the issue.

In any case I don't think we need to bring out in either the title or the milestone the exact relationship with RFC 3263, only that one exists. Defining that relationship more accurately belongs to the abstract.

Keith

> Sent: 16 December 2013 20:01
> To: Cullen Jennings (fluffy)
> Cc: Gonzalo Salgueiro (gsalguei); DRAGE, Keith (Keith); 
> SIPCORE WG; Olle E. Johansson
> > Good with me. And if you want to change "WGLC of" to 
> "Request publication of" that seems like it would fix the 
> point Mary raised.
> 
> OK. Latest candidate is:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Dec 2013 12:12:52 -0500

> I said in a previous mail that I would like to avoid the use of the word "supplement" and did suggest alternative wording. My reason is that some SDOs treat the word "supplement" as identifying inf…

I don't see why that should prevent us from using "supplement" in this 
context. We can have that discussion again if the word is used in a 
draft, but I don't see why it's a concern there either. (The definitive 
indication is whether the RFC is standards track, and the normative 
language in the draft.)

> In any case I don't think we need to bring out in either the title or the milestone the exact relationship with RFC 3263, only that one exists. Defining that relationship more accurately belongs to…

My latest proposal was:

Your earlier proposal was: "Use of RFC 3263 in dual-stack devices".

RFC6157 already addresses dual-stack devices. What we are trying to deal 
with is that 3263 and 6157 are insufficient and/or wrong for dual-stack 
clients. I see no way to avoid using *some* verb - supplement, update, 
clarify, expand, ...

Feel free to offer something that addresses both your concerns and the 
others that have been raised.

	Thanks,
	Paul