Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-05.txt

[Behcet Sarikaya <[e-mail]>]

Hi Jouni,
  Thank you for your reply.
Please see inline.



----- Original Message ----
> From: jouni korhonen <[e-mail]>
> To: Behcet Sarikaya <[e-mail]>
> Cc: [e-mail]
> Sent: Wed, September 15, 2010 4:12:19 PM
> Subject: Re: [netlmm] I-D Action:draft-ietf-netlmm-lma-discovery-05.txt
> 
> Dear Behcet,
> 
> On Sep 15, 2010, at 10:38 PM, Behcet Sarikaya  wrote:
> 
> >>>> 
> >>>> IETF  can.. but does  not have to. I like the current content  of Section 

>7. 
>
> >> For 
> >> 
> >>> 
> >>>> the record, the 3GPP boat has  already sailed. Not much to  do  there.
> > 
> > 
> > Who  should take the responsibility for this?
> 
> I guess it is the evil telecom  companies to blame here for coming up with a 
>solution where they could use  existing DNS specifications without even 
>bothering IANA.
> 
> > Look back  at the mail archive, Julien and Christian pointed at the right 
> >  direction on DNS discovery long time ago.
> 
> I assume you are referring to:  
>http://www.ietf.org/mail-archive/web/netlmm/current/msg06183.html
> 
> We did  add the main body of the MN ID based deterministic FQDN selection idea 

>to  Section 4 (was earlier Section 5). Since then above guys seem to have been 
>OK,  at least that is how I interpreted the silence.
> 

I like the second paragraph in Section 4 as well! Except that you don't let the 
reader know what  the LMA FQDNs via SRV [RFC2782] query is?
If you did (maybe in Section 3.3) the case would be closed on DNS discovery.
Please see below.

> > 
> > I have been  shouting since then what should be done and having a dialogue 
>des 
>
> >  sourds with you and Jonne.
> 
> I assume you are referring to:  
>http://www.ietf.org/mail-archive/web/netlmm/current/msg06468.html
> 
> We did  follow the suggestion to drop the Section 4 ;) Btw, I still don't 
>understand  what is the problem if a MAG behaves as "an ordinary host makes a 
>DNS query".  The simpler the better.
> 
> > 
> > Anyways, DNS discovery is mission  not accomplished in this draft.
> 
> Go ahead and actually _propose_ text on  DNS based discovery that a) does not 
>cause IANA actions and b) aligns with  Section 3 (e.g. where the Service Name != 
>
>RFC2782 _Service).
> 

I already did. Give the QNAME in Section 3.3 that will be it. I think that the 
document can stay as informational.
In Section 3.3, you mention APN as service name for LMA. This contradicts with 
your v6ops draft which says APN is used to identify P-GW for a (GTP) MN. Not all 
P-GW's could be LMAs.

In Section 3.3 you mention names agreed on among    operators that belong to the 
same inter-operator roaming consortium like 

3gpp-pgw:x-s8-pmip S-NAPRT app-service/protocol. This seems to be PMIPv6 related 
because it has pmip but I think such names are out of scope for your draft, they 
address different needs. 


So my conclusion is that Sec. 3.3 on service names fails short of coming up with 
one and yet it is somehow assumed in Section 4 2nd paragraph.
What a mystery.

Cheers,

Behcet