Subject: Re: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02

From: Avi Lior <[email-masked]>
Date: Sat, 2 Oct 2010 16:48:35 -0400

See inline
On 29-09-2010, at 22:59 , Mark Jones wrote:

> Hi Avi,
> 
> Thanks for the detailed review. Responses are inline.
> 
> On Tue, Sep 28, 2010 at 8:21 PM, Avi Lior <[email-masked]> wrote:
>> I have reviewed draft-ietf-dime-extended-naptr-02.  Here is my review:
>> 
>> Comment  1
>> ==========
>> 
>> Improving understandability.
>> 
>> The introduction does not defines the problem statement that this document addresses.
>> 
>> Even the Abstract does not tell us what problem we are solving.
>> 
>> Why do we want the NAPTR queries to contain Diameter Application-Id information?
>> 
>> The answer is not reached until section 4 which presents a wonderful background to the problem.  But still does not present the problem.
>> 
>> Suggestion move section 4 material to the introduction.  Alternatively, add a Problem Statement / Background section as part of 1.0
>> 
>> 
> 
> Ok. I’ll craft a problem statement. Something along the lines of:
> 
> “Using dynamic peer discovery as described in RFC3588, a given realm
> may advertise  multiple Diameter nodes without revealing which
> Diameter application each node supports. A peer outside the realm
> would have to perform a CER/CEA exchange with every node in order to
> find which one supports the desired application. This draft describes
> an optimization using S-NAPTR entries that allows peer discovery
> including supported applications without doing CER/CEA exchange
> beforehand.”

Works for me except: dont use This draft describes  > use this RFC or this document etc.
> 
> 
>> Comment
>> ==========
>> 
>> Terminology
>> 
>> "The Diameter base protocol specification (Section 1.4 of RFC 3588)
>>   defines most of the terminology used in this document."
>> 
>> Where is the rest defined??? or does it not matter???
>> 
> 
> Ok. I’ll add RFC3958 which introduces the S-NAPTR terms then remove “most of”.

Okay

> 
>> Comment
>> ========
>> 
>> Section 3:
>> 
>> Question:  Does NAPTR Service Field format always consists of Application Service tag and Application Protocol tag?
>> 
> 
> No. It is S-NAPTR (and not NAPTR) that defines the
> appn-svc:appln-proto format which is what this section is covering.

Okay.

> 
>> Check 3958
>> 
> 
> Checked. I believe we're good on this one.

Okay

> 
>> 
>> Comment
>> ========
>> Editorial
>> 
>> Section 3
>> 
>> supporting a specific Diameter application is show below.
>> 
>> s/show/shown
>> 
> 
> Ok.
> 
>> Comment
>> =========
>> Section 3 editorial(s)
>> 
>> Break the last par in this section after the first sentence.
>> 
>> Also change:
>> "The DNS administrator of some domain SHOULD also
>>   provision base RFC 3588 style NAPTR records [RFC2915] in order to
>>   guarantee backwards compatibility with legacy RFC 3588 compliant
>>   Diameter peers. "
>> 
>> To"
>> 
>> "DNS administrators SHOULD also
>>   provision base RFC 3588 style NAPTR records [RFC2915] in order to
>>   guarantee backwards compatibility with legacy RFC 3588 compliant
>>   Diameter peers."
>> 
> 
> Ok.
> 
>> Comment
>> ========
>> 
>> Editorial
>> 
>> Section 4 a:
>> 
>> s/The Diameter implementation performs/The Diameter peer performs/
>> 
>> or client???
>> 
> 
> This text is consistent with Section 5.2 in RFC3588. Which is also
> inconsistent between steps. ;)
> 
>> Align with terminology used in step b.
>> 
>> "If "X" contains the required Application Identifier and "Y"
>>         matches a transport protocol supported by the client,"
>> 
> 
> I believe the "client" here is not a Diameter client but a NAPTR
> client, i.e. the Diameter peer performing the NAPTR query. Pretty
> longwinded but I'll try to reword to clarify.

Okay.

> 
>> Comment
>> ========
>> 
>> Section 4  c:
>> 
>> "c: and d:" is existing behavior right?  So why are we talking about it.  I would mention it first and get it out of the way.  Just elaborate on the new stuff.
>> 
> 
> I repeated step c for readability because I thought having the
> S-NAPTR/NAPTR procedure steps would be more readable than having the
> reader trying to figure out how to mesh it with the logic for dynamic
> peer discovery in RFC3588. I believe I got the balance right here but
> take a look at the full procedure in RFC3588 and let me know if you
> disagree.

Okay.  I will check again...can you also check to see whether we should say "As specifiend in3588" to make sure the reader understands this is not new behavior.  You may already have that - I just dont have the draft infront of me.

> 
>> Comment
>> =========
>> 
>> 5 Usage Guidelines
>> 
>> I am not getting this paragraph.
>> 
>> It is stating the problem (which we could do earlier).  But i am not getting the last sentence.
>> 
>> Why do we care if its a client or a peer: can this be not used by one peer looking for a particular another peer supporting an application and protocol
>> 
> 
> Sure it could in a true peer-to-peer Diameter application there aren’t
> any (AFAIK). The usage guidelines in this section only apply for
> Diameter applications that define client/server roles.
> 
>> why does it have to only apply to client server?  What am I missing????
>> 
> 
> Let’s say I’m an MME (S6a client) looking for an HSS (S6a Server).
> Since the S-NAPTR entry only identifies peers that support S6a then I
> will discover all the other MME in the network in addition to the HSS.
> Not very helpful.
> 
>> Comment
>> ==========
>> IANA Consideration
>> 
>> 
>> 6.1
>> 
>> Is this a new registry????
>> 
> 
> Nope. It reuses the S-NAPTR registry.
> 
>> Too bad we cant just say define a generic string/rule once and not require IANA to create a new entry for each new application.
>> 
> 
> Agreed but you can’t do that without a new DDDS application and it is
> tough to justify that effort for this optimization.
> 
>> 
>> Comment
>> ========
>> 6.2
>> 
>> Why are we doing this.  We should make the usage consistent with first come first served.
>> 
>> Why require an RFC????
>> 
> 
> Because we’re using an existing IANA registry (S-NAPTR) and are bound
> by an existing allocation policy. This was discussed at IETF77 and the
> conclusion in the room was that this was the lesser of evils.

Okay.

> 
>> Specifically if I have a vendor specific application id and I want to use this scheme now I have to write an RFC?
>> 
> 
> Yes but the S-NAPTR allocation policy allows an RFC “of any category”
> (not standards track) so this should not present a major impediment to
> vendors/SDOs that require this optimization.

Okay.  Doesnt scale well at all.  
> 
> ---
> 
> I'll make the above changes in the next rev along with any other
> comments from WGLC.
> 
> Regards
> Mark

Avi Lior
[email-masked]
office: +1 613-591-9104x6417
    cell: +1 613-796-4183

---

From: Mark Jones <[email-masked]>
Date: Mon, 4 Oct 2010 10:38:24 -0400

See inline.

On Sat, Oct 2, 2010 at 4:48 PM, Avi Lior <[email-masked]> wrote:
<snip>
> Okay.  Doesnt scale well at all.

We presented the alternatives at IETF77 and this was the favoured
approach despite the additional specification effort for a non-IETF
SDO. It is the price to be paid for reusing an existing S-NAPTR
registry that does not have a "First Come; First Served" allocation
policy. A small consolation is that the IANA allocation policy for
S-NATPR service tags is not as strict as that originally used for
vendor-specific Diameter command codes ("Specification Required in
form of an RFC" vs "IETF Consensus").

Regards
Mark

---

From: Avi Lior <[email-masked]>
Date: Mon, 4 Oct 2010 12:40:02 -0400

I realize that the issue I am raising is not really with your draft.  Perhaps Dime should liaise with DNS to change this matter.

After all, Dime relaxed SDO requirements for their Diameter Applications and if NAPTR  is going to be used by SDO they will have to write an RFC (sure any old RFC but an RFC nevertheless).  Seems to be that the IETF/IESG should address this issue.

Unless of course we think that NAPTR will hardly ever be used.  Perhaps you can weigh in on how popular NAPTR will be.

Avi Lior

---

From: jouni korhonen <[email-masked]>
Date: Tue, 5 Oct 2010 12:09:35 +0300

Hi Avi,

First, thanks for thorough review comments. Some points below.

> I realize that the issue I am raising is not really with your draft.  Perhaps Dime should liaise with DNS to change this matter.

We did liaise to some extent already.. and that lead to this RFC3958 stuff. But yes, I'll look into this (as in a Dime chair mode)

> Unless of course we think that NAPTR will hardly ever be used.  Perhaps you can weigh in on how popular NAPTR will be.

That is a good question. As far as I know, at least one external body has already put a reference to extended NAPTRs into their own specifications.

- Jouni

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

---

From: Avi Lior <[email-masked]>
Date: Tue, 5 Oct 2010 09:11:01 -0400

> That is a good question. As far as I know, at least one external body has already put a reference to extended NAPTRs into their own specifications.
My 2 cents:  If that body is 3GPP then I suspect there will be many usages to follow.  Also, I think RADIUS folks are also using this.  As well,  as we start expanding beyond core services more and more will will start using mechanisms such as this for discovery.  We should get it right sooner.

Avi Lior

---

From: jouni korhonen <[email-masked]>
Date: Tue, 5 Oct 2010 22:46:11 +0300

On Oct 5, 2010, at 4:11 PM, Avi Lior wrote:

> My 2 cents:  If that body is 3GPP then I suspect there will be many usages to follow.  Also, I think RADIUS folks are 

;) well.. no. I myself don't recall 3GPP being the suspect this time.

> also using this.  As well,  as we start expanding beyond core services more and more will will start using mechanisms such as this for discovery.  We should get it right sooner.

Right. Agree.

- Jouni