Subject: Re: 3588bis review was: Re: [Dime] (no subject)

From: Victor Fajardo <[email-masked]>
Date: Tue, 22 Jan 2008 11:25:35 -0500

Hi Jouni,

Thanks for the review and sorry for the very late reply. I'm currently 
updating 3588bis based on comments from reviewers. I've integrated most 
of your comments below. Some answers to your post are inlined:

>> ------------------
>>
>> o This bis version e.g. deprecates a few things from the RFC3588 like
>>   E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are considerable
>>   changes in the security department.  I would like to see a small
>>   section actually describing the major changes. For a new reader that
>>   would be a nice quick-start.

Good idea.

>>
>> o Application Id has been written using 3-4 different conventions
>>   in the text. Pick one and stay with it ;)

Ok.

>>
>>
>> Section 4.1. AVP Header
>>
>>   I would actually leave the P-flag in place but have a description
>>   in flags related text stating something like "The 'P' bit has been
>>   deprecated and MUST be set to zero when sending and ignored on
>>   receiving". IMHO this is more cleaner way than changing it to 'r'
>>   bit.

Good point.

>>
>> 6.11. Vendor-Specific-Application-Id AVP
>>                
>>      "..           
>>     The Vendor-Id AVP is an informational AVP pertaining to the vendor
>>     who may have authorship of the vendor-specific Diameter application.
>>     It MUST NOT be used as a means of defining a completely 
>> separate           
>>     vendor-specific application identifier space.           
>>                
>>   o A question.. now that section 11.3. under IANA considerations say:
>>
>>   "Vendor-Specific Application Identifiers, are for Private Use. Vendor-
>>    Specific Application Identifiers are assigned on a First Come, First
>>    Served basis by IANA."
>>
>>   o what is the actual value of having Vendor-Id AVP in the group if
>>     the vendor specific application Ids need to be reserved from AINA
>>     anyway? If it is just FYI, couldn't that be removed..? though that
>>     might hurt backwards compatibility, slightly ;)

As you mentioned, backward compatibility is the reason why we had to 
keep vendor-id avp despite it being redundant from the base protocol 
perspective. If I'm not mistaken, its actually being used by other SDO's.

>>
>> 6.11. Vendor-Specific-Application-Id AVP   
>>                 
>>     <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >   
>>     { Vendor-Id }   
>>     ({ Auth-Application-Id } /   
>>     { Acct-Application-Id })
>>
>>   o I think the above does not comply with the ABNF described in
>>     section 3.2.

We've fixed this by integrating reviews from Ralph.

regards,
victor

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

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 00:06:49 +0100

Hi Victor,

I have two more nits ;)

 o Section 4.1 AVP format acsii figure. It seems you
   forgot to put the deprecated 'P' bit back even if
   the text mentions it again.

 o Appendix B and DNS RR examples are still formatted
   wrong imho. They should be:

    ;;          order  pref  flags   service      regexp  replacement
    IN NAPTR    50     50    "s"     "AAA+D2S"    ""      
      _diameter._sctp.example.com
    IN NAPTR    100    50    "s"     "AAA+D2T"    ""
      _aaa._tcp.example.com

  and:

    ;;       Priority  Weight  Port    Target
    IN SRV   0         1       5060    server1.example.com
    IN SRV   0         2       5060    server2.example.com

Cheers,
	Jouni

> -----Original Message-----
> From: Victor Fajardo [mailto:[email-masked]]  
> Sent: 22. tammikuuta 2008 18:26
> To: Jouni Korhonen
> Cc: [email-masked]
> Subject: Re: 3588bis review was: Re: [Dime] (no subject)
> 
> 
> Hi Jouni,
> 
> Thanks for the review and sorry for the very late reply. I'm 
> currently updating 3588bis based on comments from reviewers. 
> I've integrated most of your comments below. Some answers to 
> your post are inlined:
> 
> 
> >> ------------------
> >>
> As you mentioned, backward compatibility is the reason why we 
> had to keep vendor-id avp despite it being redundant from the 
> base protocol perspective. If I'm not mistaken, its actually 
> being used by other SDO's.
> 
> >>

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 22 Jan 2008 18:31:23 -0500

Hi Jouni,

Thanks :) We'll fix the nits.

-- victor

>>>> o This bis version e.g. deprecates a few things from the 
>>>>         
>> RFC3588 like
>>     
>>>>   E2E-Sequence AVP, SLP2 and AVP P-flag. Also there are 
>>>>         
>> considerable
>>     
>>>>   section actually describing the major changes. For a new 
>>>>         
>> reader that
>>     
>>>>   in flags related text stating something like "The 'P' 
>>>>         
>> bit has been
>>     
>>>>     The Vendor-Id AVP is an informational AVP pertaining 
>>>>         
>> to the vendor
>>     
>>>>     who may have authorship of the vendor-specific 
>>>>         
>> Diameter application.
>>     
>>>>   o A question.. now that section 11.3. under IANA 
>>>>         
>> considerations say:
>>     
>>>>   "Vendor-Specific Application Identifiers, are for 
>>>>         
>> Private Use. Vendor-
>>     
>>>>    Specific Application Identifiers are assigned on a 
>>>>         
>> First Come, First
>>     
>>>>    Served basis by IANA."
>>>>
>>>>   o what is the actual value of having Vendor-Id AVP in 
>>>>         
>> the group if
>>     
>>>>     the vendor specific application Ids need to be 
>>>>         
>> reserved from AINA
>>     
>>>>     anyway? If it is just FYI, couldn't that be removed..? 
>>>>         
>> though that
>>