Subject: Re: [Dime] draft-korhonen-dime-nai-routing-00.txt

From: "Korhonen, Jouni /TeliaSonera Finland Oyj" <[email-masked]>
Date: Sat, 5 Jul 2008 00:30:28 +0300

Hi Hannes,

Our impression after previous discussion was rather clear that routing issues would not be part of rfc3588bis and splitting the concepts of draft-tsou into smaller issues was encouraged. At least i was told so. I would be happy, if we could have the content described in this draft as a part of the rfc3588bis.

Backwards compatibility issues are imho clear.. With existing apps and rfc3588 you just don't have quarantees. So you better only apply enhanced routing to newly defined applications that can be explicit on the routing behavior.

And what is wrong with short drafts? Here we just have one issue that we want to be explicit about.

Cheers,
         Jouni

--- alkuperäinen viesti ---
Lähettäjä: "Hannes Tschofenig" <[email-masked]>
Aihe: [Dime] draft-korhonen-dime-nai-routing-00.txt
Päivämäärä: 4. heinäkuuta 2008
Aika: 21:55:16

I am a bit surprised about this document given the discussions we had in 
the context of 
http://tools.ietf.org/html/draft-tsou-dime-base-routing-ext-03. My 
impression was that we need to provide the text relevant to this aspect 
within RFC 3588bis. In fact, I naively thought that this has already 
been done...

Without going into the details of the NAI decoration itself, which is 
discussed already in RFC 4282 and RFC 5113, the real content is quite 
short.

The backwards compatibility considerations make me a bit nervous

Ciao
Hannes

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 05 Jul 2008 01:21:22 +0300

Hi Jouni,

> Our impression after previous discussion was rather clear that routing issues would not be part of rfc3588bis and splitting the concepts of draft-tsou into smaller issues was encouraged. At least i…
Interesting. I thought that the content of "route pinning" would be 
separated from the remaining description.

> Backwards compatibility issues are imho clear.. With existing apps and rfc3588 you just don't have quarantees. So you better only apply enhanced routing to newly defined applications that can be ex…
Having this to work only for new applications sounds OK although it 
raises the question on what todo with Diameter EAP, for example. Would 
you expect Diameter application designers to go for the new routing 
style for every new Diameter applications or only selectively (or even 
to define two application IDs -- one following the old style and another 
one for the new style). Consider, for example, the current Diameter 
MIPv6 HA<->AAAS work.

> And what is wrong with short drafts? Here we just have one issue that we want to be explicit about.
Nothing wrong with short drafts. I was just wondering whether you have 
thought that the discussion would be too long for the RFC 3588bis 
document and therefore it was put into a separate draft.

Ciao
Hannes