Subject: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 9 Feb 2009 16:35:23 +0200

Hi all,

this is a DIME Working Group Last Call for comments on

http://www.ietf.org/internet-drafts/draft-ietf-dime-nai-routing-01.txt

Please send your comments to the list by Feb 23, 2009.

Ciao
Hannes

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 11 Feb 2009 10:37:58 +0700

I must admit that I am extremely confused by this document: first, I don't
understand why it even exists, since basically all it says is to follow RFC
4282 & second (and this has me really confused) the claim is made that it is
somehow incompatible w/RFC 3588 routing.  I suppose that might be true if
one were to take 3588 in a vacuum (how is that possible?), but in
combination with 4282 it's rather painfully obvious that the only way to
handle decorated NAIs in Diameter is the way discussed in the draft.  So
what is the point?

---

From: Stefan Winter <[email-masked]>
Date: Tue, 17 Feb 2009 11:23:00 +0100

Hi,

> Please send your comments to the list by Feb 23, 2009.

This revision looks better than the previous one. Most points of my
original review of -00 were adressed (and the rest is so minor that I
don't care). One point in my original review still stands though
(quoting myself):

"The mechanisms in this document have such a wide-reaching use that I
would much rather recommend to put it into 3588bis and require it also
for existing Apps."

This draft does little more than state that 3588 was ambiguous,
clarifies it and updates the NAI reference. There is ongoing work on
3588bis which could easily achieve the same result with just a few
sentences, be standards-track and binding for all Diameter apps. Going
all the way for an own RFC looks like overkill to me.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Tina TSOU <[email-masked]>
Date: Tue, 17 Feb 2009 18:33:10 +0800

Hi,
I'm happy with the current version of the document and that the  
document is ready for the IESG.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 17 Feb 2009 15:05:15 +0200

Hi Stefan, 

We took this approach into consideration earlier but the group did not want to put this functionality into RFC3588bis. 
Hence, a separate document was created. 

Ciao
Hannes

>-----Original Message-----
>From: ext Stefan Winter [mailto:[email-masked]] 
>Sent: 17 February, 2009 12:23
>To: Tschofenig, Hannes (NSN - FI/Espoo)
>Cc: [email-masked]
>Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt
>
>Hi,
>
>This revision looks better than the previous one. Most points 
>of my original review of -00 were adressed (and the rest is so 
>minor that I don't care). One point in my original review 
>still stands though (quoting myself):
>
>"The mechanisms in this document have such a wide-reaching use 
>that I would much rather recommend to put it into 3588bis and 
>require it also for existing Apps."
>
>This draft does little more than state that 3588 was 
>ambiguous, clarifies it and updates the NAI reference. There 
>is ongoing work on 3588bis which could easily achieve the same 
>result with just a few sentences, be standards-track and 
>binding for all Diameter apps. Going all the way for an own 
>RFC looks like overkill to me.
>
>Greetings,
>
>Stefan Winter
>
>--
>Stefan WINTER
>Ingenieur de Recherche
>Fondation RESTENA - Réseau Téléinformatique de l'Education 
>Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi
>L-1359 Luxembourg
>
>Tel: +352 424409 1
>Fax: +352 422473
>
>

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 17 Feb 2009 20:29:45 +0700

Tschofenig, Hannes (NSN - FI/Espoo) [mailto:[email-masked]]
writes:

> Hi Stefan,
> 
> We took this approach into consideration earlier but the group did not
> want to put this functionality into RFC3588bis.

As I mentioned in my review, I can't find any functionality in this
document; at best, it's just making even more obvious what should already be
painfully so from reading RFCs 3588 & 4282.  Therefore, I've got to agree
with Stefan: unless I'm missing something huge, this is at most a
clarification & belongs in 3588bis.

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

---

From: Mark Jones <[email-masked]>
Date: Tue, 17 Feb 2009 10:26:58 -0500

Same here. Ship it.

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: February 17, 2009 04:33
To: Stefan Winter
Cc: [email-masked]
Subject: Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt

Hi,
I'm happy with the current version of the document and that the document is ready for the IESG.

B. R.
Tina

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 16:41:12 +0100

Hi,
 
The last version of draft captured all my previous comments/concerns et is ready for me me for IESG evaluation and RFC publication.
 
BR,
 
Lionel

	De : [email-masked] [mailto:[email-masked]] De la part de Mark Jones
	Envoyé : mardi 17 février 2009 16:27
	À : [email-masked]
	Objet : Re: [Dime] WGLC : draft-ietf-dime-nai-routing-01.txt

	Same here. Ship it.

		
		Hi,

		

		

		
		B. R.
		Tina

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 17:05:27 +0100

Hi Glen and Stefan,

I can just acknowledge what it is said in this draft.

The initial proposal was to put this material inside the RFC3588bis document. But it was decided to let it out and to go for a stand-alone document that could be see as as a RFC3588bis's companion document.

If I remember correctly, the motivation for this path was the potential backward compatibility issue with pre-existing Diameter implementations that might not support the Decorated NAI. And the objectives of the RFC3588bis was to minimize this kind of impacts.

But at least, I'm glad with the fact that the content of the draft seems right, clear and even obvious ;)

BR,

Lionel

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De 
> la part de Glen Zorn
> Envoyé : mardi 17 février 2009 14:30
> À : 'Tschofenig, Hannes (NSN - FI/Espoo)'; 'ext Stefan Winter'
> Cc : [email-masked]
> As I mentioned in my review, I can't find any functionality 
> in this document; at best, it's just making even more obvious 
> what should already be painfully so from reading RFCs 3588 & 
> 4282.  Therefore, I've got to agree with Stefan: unless I'm 
> missing something huge, this is at most a clarification & 
> belongs in 3588bis.
> 
> > >would much rather recommend to put it into 3588bis and require it 
> > >also for existing Apps."
> > >
> > >sentences, be standards-track and binding for all Diameter apps. 
> > >Going all the way for an own RFC looks like overkill to me.
> > >
> > >Greetings,
> > >
> > >Stefan Winter
> > >
> > >--
> > >Stefan WINTER
> > >Ingenieur de Recherche
> Nationale 
> > >et de la Recherche 6, rue Richard Coudenhove-Kalergi
> > >L-1359 Luxembourg
> > >
> > >Tel: +352 424409 1
> > >Fax: +352 422473
> > >
> > >

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 18 Feb 2009 11:13:56 +0900

Hello,

> If I remember correctly, the motivation for this path was the potential backward compatibility issue with pre-existing Diameter implementations that might not support the Decorated NAI. And the obj…

In this case, I guess the situation is worth re-examination, since it
looks like rfc3588bis will not be backward-compatible with 3588 anyway
(hence the proposal from Victor to bump the version number in the protocol).

I would believe the most important question is: is the support for this
feature optional or mandatory for Diameter implementations? That should
direct the choice of creating a separate RFC or merging in 3588bis....

My 2 cents...
Sebastien.

---

From: jouni korhonen <[email-masked]>
Date: Wed, 18 Feb 2009 13:59:52 +0200

Hi,

On Feb 18, 2009, at 4:13 AM, Sebastien Decugis wrote:

>> If I remember correctly, the motivation for this path was the  
>> potential backward compatibility issue with pre-existing Diameter  
>> implementations that might not support the Decorated NAI. And the  
>> objectives of the RFC3588bis was to minimize this kind of impacts.
>>
>

Due my ultimate xml skills the -01 draft does not show that also  
rfc3588 is in the "updates" list of affected documents. As Glen's  
detailed review pointed out, the changes this draft proposes are  
straight forward. There are few points why the draft exists. One,  
rfc3588 is ambiguous related to aspects what the draft clarifies (and  
also picks up one decoration approach of several possibilities that  
rfc4282 has). Second, the draft allows small incremental upgrade to  
rfc3588 (with clearly pointed out backwards compatibility concerns)  
without mandating a full rfc3588bis changes. This was envisioned to be  
easier approach as we can maintain full rfc3588 backwards  
compatibility, except in cases where the draft's solution is  
explicitly referenced (i.e. per application within a deployment).  
Third, it was earlier asked to implement the draft content to  
rfc3588bis. We were advised to make a separate draft to keep  
rfc3588bis request routing part intact compared to rfc3588. I am more  
than happy to implement the draft's solution as a mandatory feature to  
rfc3588bis. I would still need a solution for rfc3588 during the  
migration period.

Cheers,
	Jouni

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 18 Feb 2009 13:29:32 -0500

Hi,

> (hence the proposal from Victor to bump the version number in the protocol).

To me, it seems that decorated NAI is something specific to certain 
deployment situations. There are a lot of things in bis that remain 
generalized specifically because it is a "base" protocol. Adding 
specific solutions for specific scenarios into bis is probably not a 
good choice ... obviously because the list of specific items is 
exponential. We would also like to retain a certain level of modularity 
and this is why we have diameter extensibility.

> direct the choice of creating a separate RFC or merging in 3588bis....

I doubt that this should be a mandated feature for all implementations 
but certain aspects of this functionality can be mandated within the 
scope of this document and hence required by the implementations that 
support this document.

regards,
victor