Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Jun 2015 19:15:24 +0000

Hi,

I've submitted a new draft to dispatch: draft-holmberg-dispatch-received-realm-00. The draft defines a new Via header field parameter, "received-realm", which network entry entities can insert in order to inform other entities in the network from which network the request was received.

Previous versions of the draft have been submitted to SIPCORE, but I was advised by the SIPCORE chairs to submit it to DISPATCH.

Compared to previous versions, there is a technical change: the entity which inserts a parameter also calculates a HMAC value, which is inserted together with the network value.

Regards,

Christer

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 10 Jun 2015 13:06:26 +0000

Hi Christer,
I agree that it is useful for a (transit) network to know which network a request arrived from, as this draft argues. But isn't this information to be in the Via header field already in the entry before the transit network? The draft mentions that inter-operator identifier cannot be used but I think the draft should expand on why a new header field parameter is needed.

Regards,
Peter

From: dispatch [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 08 June 2015 20:15
To: [email-masked]
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00

Hi,

Regards,

Christer

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 10 Jun 2015 13:10:33 +0000

I support this draft moving forward

From: dispatch [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Monday, June 08, 2015 3:15 PM
To: [email-masked]
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00

Hi,

Regards,

Christer

---

From: Georg Mayer <[email-masked]>
Date: Wed, 10 Jun 2015 15:16:45 +0200

+1

On 06/10/2015 03:10 PM, DOLLY, MARTIN C wrote:
> *From:* dispatch [mailto:[email-masked]] *On Behalf Of 
> *Christer Holmberg
> *Sent:* Monday, June 08, 2015 3:15 PM
> *To:* [email-masked]
> *Subject:* [dispatch] New draft: draft-holmberg-dispatch-received-realm-00
>
> Hi,
>
> I’ve submitted a new draft to dispatch: 
> draft-holmberg-dispatch-received-realm-00. The draft defines a new Via 
> header field parameter, “received-realm”, which network entry entities 
> can insert in order to inform other entities in the network from which 
> network the request was received.
>
> Previous versions of the draft have been submitted to SIPCORE, but I 
> was advised by the SIPCORE chairs to submit it to DISPATCH.
>
> Compared to previous versions, there is a technical change: the entity 
> which inserts a parameter also calculates a HMAC value, which is 
> inserted together with the network value.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

-- 
--
Georg Mayer
3GPP CT Chairman
HUAWEI Technologies
Mobile: +43 699 1900 5758

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Jun 2015 15:20:03 +0000

Hi Peter,

Thanks for your comments! See inline.

> I agree that it is useful for a (transit) network to know which network a request arrived from, as this
> draft argues. But isn't this information to be in the Via header field already in the entry before the
> transit network? The draft mentions that inter-operator identifier cannot be used but I think the
>draft should expand on why a new header field parameter is needed.

Via headers may contain IP addresses, and they cannot always be used to identify the network. Also, the consumer of the information would have to scan through the Via headers, and figure out which belongs to the consumer network and which belongs to the adjacent network.

The purpose of the identifier is to have an explicit indicator, which prevents such scanning etc.

I try to explain that in the draft, but maybe more text is needed :)

Regards,

Christer

From: dispatch [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 08 June 2015 20:15
To: [email-masked]<mailto:[email-masked]>
Subject: [dispatch] New draft: draft-holmberg-dispatch-received-realm-00

Hi,

Regards,

Christer

---

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 11 Jun 2015 12:50:08 +0000

Thanks Christer,
I would like to see this draft progress, I think it describes functionality that is needed. I have other comments and questions on the text but they can be raised later.

Regards,
Peter

From: Christer Holmberg [mailto:[email-masked]]
Sent: 10 June 2015 16:20
To: Dawes, Peter, Vodafone Group; [email-masked]
Subject: RE: New draft: draft-holmberg-dispatch-received-realm-00

Hi Peter,

Regards,

Christer

Hi,

Regards,

Christer

---

From: Victor Pascual Avila <[email-masked]>
Date: Thu, 25 Jun 2015 10:22:05 +0200

+1

On Thu, Jun 11, 2015 at 2:50 PM, Dawes, Peter, Vodafone Group <
[email-masked]> wrote:

>  Thanks Christer,
>
> I would like to see this draft progress, I think it describes
> functionality that is needed. I have other comments and questions on the
> text but they can be raised later.
>
>
>
> Regards,
>
> Peter
>
>
>
> *From:* Christer Holmberg [mailto:[email-masked]]
> *Sent:* 10 June 2015 16:20
> *To:* Dawes, Peter, Vodafone Group; [email-masked]
> *Subject:* RE: New draft: draft-holmberg-dispatch-received-realm-00
>
>
>
> Hi Peter,
>
>
>
> > draft argues. But isn’t this information to be in the Via header field
> already in the entry before the
>
> Via headers may contain IP addresses, and they cannot always be used to
> identify the network. Also, the consumer of the information would have to
> scan through the Via headers, and figure out which belongs to the consumer
> network and which belongs to the adjacent network.
>
>
>
> *From:* dispatch [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Christer Holmberg
> *Sent:* 08 June 2015 20:15
> *To:* [email-masked]
> header field parameter, “received-realm”, which network entry entities can
> insert in order to inform other entities in the network from which network
> the request was received.
>
>
>
> Previous versions of the draft have been submitted to SIPCORE, but I was
> advised by the SIPCORE chairs to submit it to DISPATCH.
>
>
>
> which inserts a parameter also calculates a HMAC value, which is inserted
> together with the network value.
>
>
>
> Regards,
>
>
>
> Christer
>

-- 
Victor Pascual Ávila