Subject: [Dime] (no subject)

From: Jouni Korhonen <[email-masked]>
Date: Sat, 22 Dec 2007 10:10:59 +0200

Hi all,

I promised to do some reading of rfc3588bis. Mark already did cover
most of the stuff but few initial nits below. More to follow probably.

Cheers,
	Jouni

------------------

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.

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

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.

Section 4.3. Derived AVP Data Formats

      "The IPFilterRule format is derived from the OctetString AVP Base
       Format.  It uses the ASCII charset.  Packets may be filtered  
based
       on the following information that is associated with it:"

   o I would suggest rewriting:

      "The IPFilterRule format is derived from the OctetString AVP Base
       Format and uses the ASCII charset. The rule syntax is a modified
       subset of ipfw(8) from FreeBSD. Packets may be filtered based on
       the following information that is associated with it:"

   o And revome the following one sentence paragraph.

      "The rule syntax is a modified subset of ipfw(8) from FreeBSD, and
       the ipfw.c code may provide a useful base for implementations."

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 ;)

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.

8.4.2. Session-Termination-Answer

                   * [ Redirect-Host ]
                     [ Redirect-Host-Usage ]
                                        ^
                     [ Redirect-Max-Cache-Time ]

   o what is this '^' ?

11. IANA Considerations

   o Text references to DIME WG should be removed. Once DIME completes
     there is probably no mailing list to post any requests etc.
     Suggested rewrite of

   "                 ...For Designated Expert with Specification
    Required, the request is posted to the DIME WG mailing list (or, if
    it has been disbanded, a successor designated by the Area Director)
    for comment and review, and MUST include a pointer to a public
    specification."

    to

   "                 ...For Designated Expert with Specification
    Required, the request is posted to a mailing list maintaining
    Diameter or one designated by the Area Director) for comment
    and review, and MUST include a pointer to a public specification."

11.6. NAPTR Service Fields

   "transport protocol.  For example - "New Connectionless Transport
    Protocol (NCTP), RFC 5766"."

   o We'll probably reach RFC  5766 in two years or something. Use
     some other fictional number or convention as an example, like
     RFC 0000, RFC xyz or similar truly not existing number

14.1. Normative References

    [IPV4]     Postel, J., "Internet Protocol", RFC 791, September 1981.

    [TCP]      Postel, J., "Transmission Control Protocol", RFC 793,
               January 1981.

   o Inconsistent style compared to other RFC references

Appendix B. NAPTR Example

     ;;          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
     ...

   o The layout in both examples (NAPTR & SRV) is a bit off??

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

---

From: Jouni Korhonen <[email-masked]>
Date: Sat, 22 Dec 2007 10:19:54 +0200

D'oh.. forgot the subject line ;)

Jouni