Subject: Re: [Sipping] WGLC: draft-ietf-sipping-v6-transition-03.txt

From: [email-masked]
Date: Wed, 5 Jul 2006 14:21:14 -0400

There is something in this draft that I think needs a bit better
explaining:

   If SRV RR's have been used to derive the addresses of the server,
   the "Priority" field of the SRV RR can also aid in such a decision;
   however, the technique in RFC 3484 has precedence.  SRV priority
   levels MUST be used in addition to, but MUST NOT be used as a
   replacement for RFC 3484.

It's not clear to me what is specified here.  Perhaps it has already
been defined how SRV records and RFC 3484 interact, but it isn't clear
to me.  E.g., until one steps through the SRV records, it is not
possible to determine whether a destination is a v4 or v6 address,
much less which address it is, whereas that information is the *input*
to the algorithms in RFC 3484.  Yet the text suggests that RFC 3484 is
the "major sort key".

In addition, the final sentence of that paragraph is:

   Regardless of which network is tried first, each search corresponds
   to a different branch, and as such, mandates that the the normative
   behavior in RFC3261 to handle requests sent on a branch be
   followed.

It is not clear to me what "each search" refers to -- there is no
other use of the word "search" in this I-D, nor any uses at all in RFC
3484.  Nor is it clear why each DNS(?) search (A and AAAA?) would be
considered a separate branch.

And a nit:  In section 3.1.1, "It's route set will" should be "Its
route set will".

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 6 Jul 2006 16:16:39 -0500

I'm wondering if we don't have a backward compatibility problem with the
approach suggested in there
For Record-Route.

What will a hop that doesn't understand IPv6 addresses do with a
Record-Route entry that includes an IPv6 address? Won't it have a
problem with it?

Instead of having 2 separate Record-Route entries for the same interface
(one IPv4 and one IPv6), wouldn't it make more sense to have only 1
entry which includes alternative addresses? I am thinking something
similar to what we do for media with ANAT. Of course it would have to be
backward compatible so that if a hop doesn't understand the new
parameter (the IPv6 address), it would use the IPv4 address.

Or am I missing something?

-----Original Message-----
From: Barnes, Mary [RICH2:B601:EXCH] 
Sent: Thursday, June 29, 2006 10:54 AM
To: [email-masked]
Cc: Vijay K. Gurbani; [email-masked]; [email-masked]
Subject: [Sipping] WGLC: draft-ietf-sipping-v6-transition-03.txt

Hi all,

We would like to working group last call (WGLC) the following draft: 
http://www.ietf.org/internet-drafts/draft-ietf-sipping-v6-transition-03.
txt

We would like to recruit at least 3 volunteers to serve as dedicated
reviewers. 
If you are interested and willing to review this draft, please send an
email to the SIPPING chairs.

As always, anyone else that gets a chance to review should also send
their feedback to the authors and copy the SIPPING mailing list. 

This WGLC will end on July 20th, 2006. 

Thanks,
Mary
SIPPING WG co-chair

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Jul 2006 10:26:06 +0300

Hi,

I do not like the idea of the ANAT stuff for Record-Route. We do not 
have the need to come up with a new mechanism to resolve that problem. 
Instead, you can perform Record-Route rewriting. However, the current 
trend, is to use double Record-Route, as described in RFC 3486.

After asking a bunch of implementers, we concluded that implementations 
simply copy and paste Record-Route and Route entries that do not need to 
use. That is, an implementation will parse the Route entry it needs to 
send the request to, but will not bother parsing the rest of the Route 
entries. It will simply copy them and paste them to the outgoing 
request. So, we do not think this will cause any compatibility problem.

Cheers,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Jul 2006 15:19:47 -0500

> to the algorithms in RFC 3484.  Yet the text suggests that RFC 3484 is

Dale: I went through my emails about when we added RFC 3848 into
the draft ... there was some discussion between Karim and myself
that resulted in the addition of this paragraph.  I need to
revisit that discussion with Karim one more time, since it appears
that he may be concerned about source-address selection
through RFC3484, and I was looking at it to do destination address
selection.

I will resolve this and let the WG know of the outcome.

> considered a separate branch.

OK, I think I see your dilemma.  The phrase "each search" refers
to each element of the set returned by SRV.  So, if a request
to an AAAA address fails, the request will be tried to the
A address as a new transaction (as per Section 4.3 of rfc3263).
I will clarify this in the next revision.

> And a nit:  In section 3.1.1, "It's route set will" should be "Its

Fixed.

Thanks.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 07 Jul 2006 15:34:11 -0500

Francois Audet wrote:
> approach suggested in there for Record-Route.
[...]

Francois: A few more thoughts besides Gonzalo's response...

The draft recognizes the specific situation you bring up; in
Section 3.1.1 is a note that says:

       Note that while this is the recommended practice, some problems
       may still arise if a RFC2543 [17] endpoint is involved in
       signaling.  Since the ABNF in RFC2543 did not include production
       rules to parse IPv6 network identifiers, there is a good chance
       that a RFC2543-only compliant endpoint is not able to parse or
       regenerate IPv6 network identifiers in headers.  Thus, despite a
       dual-stack proxy inserting itself into the session establishment,
       the endpoint itself may not succeed in the signaling establishment
       phase.

       This is generally not a problem with RFC3261 endpoints; even if
       such an endpoint runs on an IPv4-only node, it still is able to
       parse and regenerate IPv6 network identifiers.

Given that most implementations are rfc3261 aware, they should be
able to parse and regenerate IPv6 network identifiers.  Of course,
another way to eliminate this completely is to use fqdns.  Yet
another way is to do R-R re-writing.  In fact, earlier versions
of the draft had the R-R re-writing trick, but I have since been
convinced that double R-R is a better alternative.

Thanks,

- vijay