Subject: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt

From: Benoit Claise <[email-masked]>
Date: Tue, 10 Jul 2012 16:46:55 +0200

Dear all, Glen,

Please find below the AD review of draft-ietf-dime-rfc4005bis-09.txt

The document is in a good enough shape to be sent to IETF LC.
Please consider my comments together with the other IETF LC comments.

Glen, let me know if you plan on submitting a quick revision soon, or if 
I should send THIS version to the IETF LC (which might lead to redundant 
comment)

- Some idnits
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-dime-rfc4005bis-09.txt

   Miscellaneous warnings:
   ----------------------------------------------------------------------------

   == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but
      does not include the phrase in its RFC 2119 key words list.

   Checking references for intended status: Proposed Standard
   ----------------------------------------------------------------------------

   == Missing Reference: 'BASE' is mentioned on line 219, but not defined

I understand that this is a quote from RFC4005. To avoid the source of 
confusion, here is a proposal

OLD:

       However, the presence of an
       instance of the Acct-Application-Id AVP was required in RFC 4005,
       as well:

          The ACR message [BASE] is sent by the NAS to report its session
          information to a target server downstream.

          Either of Acct-Application-Id or Vendor-Specific-Application-Id
          AVPs MUST be present.  If the Vendor-Specific-Application-Id
          grouped AVP is present, it must have an Acct-Application-Id
          inside.

NEW:

       However, the presence of an
       instance of the Acct-Application-Id AVP was required in RFC 4005,
       which quotes:

          "The ACR message [BASE] is sent by the NAS to report its session
          information to a target server downstream.

          Either of Acct-Application-Id or Vendor-Specific-Application-Id
          AVPs MUST be present.  If the Vendor-Specific-Application-Id
          grouped AVP is present, it must have an Acct-Application-Id
          inside."

- One small improvement
OLD:

    o  The accounting model to be used is now specified.

NEW
    o  The accounting model to be used is now specified. See section 1.6

- Expand on the first ASA occurrence

- Add an point after [I-D.ietf-dime-rfc3588bis]

    3.1.  AA-Request (AAR) Command

        The AA-Request (AAR), which is indicated by setting the Command-Code
        field to 265 and the 'R' bit in the Command Flags field, is used to
        request authentication and/or authorization for a given NAS user.
        The type of request is identified through the Auth-Request-Type AVP
        [I-D.ietf-dime-rfc3588bis] The recommended value for most situations
        is AUTHORIZE_AUTHENTICATE.

- I could not find the meaning of * in, for example,

                           [ CHAP-Auth ]
                           [ CHAP-Challenge ]
                         * [ Framed-Compression ]
                           [ Framed-Interface-Id ]
                           [ Framed-IP-Address ]
                         * [ Framed-IPv6-Prefix ]
                           [ Framed-IP-Netmask ]
                           [ Framed-MTU ]
                           [ Framed-Protocol ]
                           [ ARAP-Password ]
                           [ ARAP-Security ]
                         * [ ARAP-Security-Data ]
                         * [ Login-IP-Host ]
                         * [ Login-IPv6-Host ]
                           [ Login-LAT-Group ]
                           [ Login-LAT-Node ]
                           [ Login-LAT-Port ]
                           [ Login-LAT-Service ]
                         * [ Tunneling ]
                         * [ Proxy-Info ]
                         * [ Route-Record ]
                         * [ AVP ]

- 3.7.  Abort-Session-Request (ASR) Command

    The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis]
    may be sent by any server to the NAS providing session service, to
    request that the session identified by the Session-Id be stopped.

By "any Diameter server"?  like in section 3.3 btw.

- IANA Considerations
Do we need to change all the "4005" entries in 
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml into 
"4005bis"?
Or to be more correct, the new RFC id for 4005bis?

- OLD

    [RADIUSTypes]               IANA, "IANA Radius Attribute Values
                                Registry", <http://www.iana.org/
                                assignments/radius-types-3>.

NEW:
    [RADIUSTypes]               IANA, "IANA Radius Attribute Values
                                Registry", <http://www.iana.org/
                                assignments/radius-types>.

ALTERNATE PROPOSAL

    [RADIUSTypes]               IANA, "IANA Radius Attribute Values
                                Registry", <http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1>.

Regards, Benoit.

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 23:18:39 +0000

Hi Benoit,

                          [ CHAP-Auth ]

                          [ CHAP-Challenge ]

                        * [ Framed-Compression ]

                          [ Framed-Interface-Id ]

                          [ Framed-IP-Address ]

                        * [ Framed-IPv6-Prefix ]

                          [ Framed-IP-Netmask ]

                          [ Framed-MTU ]

                          [ Framed-Protocol ]

                          [ ARAP-Password ]

                          [ ARAP-Security ]

                        * [ ARAP-Security-Data ]

                        * [ Login-IP-Host ]

                        * [ Login-IPv6-Host ]

                          [ Login-LAT-Group ]

                          [ Login-LAT-Node ]

                          [ Login-LAT-Port ]

                          [ Login-LAT-Service ]

                        * [ Tunneling ]

                        * [ Proxy-Info ]

                        * [ Route-Record ]

                        * [ AVP ]

[[LM]] the < * > in front the AVP means that 0, 1 or more AVP scan be present in the request (or in a Grouped AVP). It follows rules used in RFC3588 and defined in RFC 5234 (http://tools.ietf.org/html/rfc5234#section-3.6).

Regards,

Lionel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Jul 2012 09:09:08 +0200

Hi Lionel,
> */[[LM]]/*the « * » in front the AVP means that 0, 1 or more AVP scan be present in the request (or in a Grouped AVP). It follows rules used in RFC3588 and defined in RFC 5234 (http://tools.ietf.org/html/rfc5234#section-3.6).
>   
BC> Thanks for the education.
Is this so obvious to the Diameter readers, including the newcomers, 
that we don't need to mention it?
In other words, am I the only one NOT knowing this? ;-)

Regards, Benoit.

---

From: <[email-masked]>
Date: Wed, 11 Jul 2012 09:29:20 +0200

Hello Benoit and Lionel
as a reader of the Diameter specifications I would support a proposal to define the notification within the document. Clearly "somewhere" it is stated but for a simple reader it would be very helpful to have such an description of the notification in the same document as it is used.

Best regards

Dieter Jacobsohn

Deutsche Telekom AG
Group Technology
Dieter Jacobsohn
Landgrabenweg 151, 53227 Bonn
+49 228 936-18445 (Tel.)
+49 391 5801 46624 (Fax)
+49 171 2088 710 (Mobil)
E-Mail: [email-masked]<mailto:[email-masked]>
www.telekom.com<http://www.telekom.com/>

Erleben, was verbindet.

Deutsche Telekom AG
Aufsichtsrat: Prof. Dr. Ulrich Lehner (Vorsitzender)
Vorstand: René Obermann (Vorsitzender),
Dr. Manfred Balz, Reinhard Clemens, Niek Jan van Damme,
Timotheus Höttges, Claudia Nemat,  Prof. Dr. Marion Schick
Handelsregister: Amtsgericht Bonn HRB 6794
Sitz der Gesellschaft Bonn
USt-IdNr. DE 123475223

Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

________________________________
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Benoit Claise
Gesendet: Mittwoch, 11. Juli 2012 09:09
An: [email-masked]
Cc: dime mailing list
Betreff: Re: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt

Hi Lionel,

Hi Benoit,

                          [ CHAP-Auth ]

                          [ CHAP-Challenge ]

                        * [ Framed-Compression ]

                          [ Framed-Interface-Id ]

                          [ Framed-IP-Address ]

                        * [ Framed-IPv6-Prefix ]

                          [ Framed-IP-Netmask ]

                          [ Framed-MTU ]

                          [ Framed-Protocol ]

                          [ ARAP-Password ]

                          [ ARAP-Security ]

                        * [ ARAP-Security-Data ]

                        * [ Login-IP-Host ]

                        * [ Login-IPv6-Host ]

                          [ Login-LAT-Group ]

                          [ Login-LAT-Node ]

                          [ Login-LAT-Port ]

                          [ Login-LAT-Service ]

                        * [ Tunneling ]

                        * [ Proxy-Info ]

                        * [ Route-Record ]

                        * [ AVP ]

[[LM]] the « * » in front the AVP means that 0, 1 or more AVP scan be present in the request (or in a Grouped AVP). It follows rules used in RFC3588 and defined in RFC 5234 (http://tools.ietf.org/html/rfc5234#section-3.6).

BC> Thanks for the education.
Is this so obvious to the Diameter readers, including the newcomers, that we don't need to mention it?
In other words, am I the only one NOT knowing this? ;-)

Regards, Benoit.

Regards,

Lionel

---

From: <[email-masked]>
Date: Wed, 11 Jul 2012 07:40:36 +0000

Hi,

Benoit, it is true that there is in the RFC4005 an implicit reference to the RFC3588 when describing the new command (AAR/AAA). It could be useful to explicitly state that the definition of the new command follows the rules described in RFC3588(bis).

About Dieter's comment, the CCF specification of a command is clearly defined in RFC3588(bis) with an explicit reference to RFC5234 for further details, so I don't think that it is needed to provide again the description in this specification and in any other diameter specification referencing the RFC3588(bis).

Regards,

Lionel

De : [email-masked] [mailto:[email-masked]]
Envoyé : mercredi 11 juillet 2012 09:29
À : [email-masked]; MORAND Lionel RD-CORE
Cc : [email-masked]
Objet : AW: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt

Hello Benoit and Lionel

Best regards

Dieter Jacobsohn

Deutsche Telekom AG
Group Technology
Dieter Jacobsohn

Erleben, was verbindet.

Deutsche Telekom AG

Hi Benoit,

                          [ CHAP-Auth ]

                          [ CHAP-Challenge ]

                        * [ Framed-Compression ]

                          [ Framed-Interface-Id ]

                          [ Framed-IP-Address ]

                        * [ Framed-IPv6-Prefix ]

                          [ Framed-IP-Netmask ]

                          [ Framed-MTU ]

                          [ Framed-Protocol ]

                          [ ARAP-Password ]

                          [ ARAP-Security ]

                        * [ ARAP-Security-Data ]

                        * [ Login-IP-Host ]

                        * [ Login-IPv6-Host ]

                          [ Login-LAT-Group ]

                          [ Login-LAT-Node ]

                          [ Login-LAT-Port ]

                          [ Login-LAT-Service ]

                        * [ Tunneling ]

                        * [ Proxy-Info ]

                        * [ Route-Record ]

                        * [ AVP ]

Regards, Benoit.

Regards,

Lionel

Thank you.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Jul 2012 09:48:38 +0200

Hi Lionel,
>
> Hi,
>
> Benoit, it is true that there is in the RFC4005 an implicit reference 
> to the RFC3588 when describing the new command (AAR/AAA). It could be 
> useful to explicitly state that the definition of the new command 
> follows the rules described in RFC3588(bis).
>
That would work for me

Regards, Benoit.
>
> About Dieter's comment, the CCF specification of a command is clearly 
> defined in RFC3588(bis) with an explicit reference to RFC5234 for 
> further details, so I don't think that it is needed to provide again 
> the description in this specification and in any other diameter 
> specification referencing the RFC3588(bis).
>
> Regards,
>
> Lionel
>
> *De :[email-masked] [mailto:[email-masked]]
> *Envoyé :* mercredi 11 juillet 2012 09:29
> *À :* [email-masked]; MORAND Lionel RD-CORE
> *Cc :* [email-masked]
> *Objet :* AW: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt
>
> Hello Benoit and Lionel
>
> as a reader of the Diameter specifications I would support a proposal 
> to define the notification within the document. Clearly "somewhere" it 
> is stated but for a simple reader it would be very helpful to have 
> such an description of the notification in the same document as it is 
> used.
>
> Best regards
>
> Dieter Jacobsohn
>
> Deutsche Telekom AG
> Group Technology
> Dieter Jacobsohn
> E-Mail: [email-masked] <mailto:[email-masked]>
> www.telekom.com <http://www.telekom.com/>
>
> Erleben, was verbindet.
>
> Deutsche Telekom AG
> *Große Veränderungen fangen klein an****--**Ressourcen schonen und 
> nicht jede E-Mail drucken.*
>
> ------------------------------------------------------------------------
>
> *Von:[email-masked] [mailto:[email-masked]] *Im Auftrag 
> von *Benoit Claise
> *Gesendet:* Mittwoch, 11. Juli 2012 09:09
> *An:* [email-masked]
> *Cc:* dime mailing list
> *Betreff:* Re: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt
>
> Hi Lionel,
>
>     Hi Benoit,
>
>       
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 11 Jul 2012 11:05:43 +0200

Dear all, Glen,

Two more points, part of the AD review (I needed a little bit of 
education before making those points, hence the part 2 in my review)

1. the NASREQ application is specified in RFC4005bis, but IANA points to 
RFC3588bis
See 
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45 

with an entry for Application id= 1, for NASREQ, with the reference 
[RFC-ietf-dime-rfc3588bis-33]

I understand the history: RFC3588 introduced this application id value 1 
in the IANA Considerations section.
However, RFC3588bis, which will obsolete RFC3588, doesn't mention this 
application id (obviously, because it was assigned already).
So don't you believe that we should correct this and have, in the IANA 
Considerations section of 
http://tools.ietf.org/id/draft-ietf-dime-rfc4005bis-09.txt , a message 
basically expressing:
http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45 
should contain
              Application id= 1, for NASREQ, with the reference 
[RFC4005bis]

2.  In section 3.10Accounting-Answer (ACA) Command

    The same level of security MUST
    be applied to both the Accounting-Request and the corresponding
    Accounting-Answer message.  For example, if the ACR was protected
    using end-to-end security techniques then the corresponding ACA
    message MUST be protected in the same way; note, however, that the
    definition of such techniques is outside the scope of this document.

Note: this message about "The same level of security ..." is only 
available in that section
Why does this apply only to Accounting-Request and Accounting-Answer?
Or does it apply to all Request/Answer?

Regards, Benoit.

> Glen, let me know if you plan on submitting a quick revision soon, or 
> if I should send THIS version to the IETF LC (which might lead to 
> redundant comment)
>
>
> - Some idnits
>                                 Registry",<http://www.iana.org/
>                                 Registry",<http://www.iana.org/
>                                 Registry",<http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1>.
>
> Regards, Benoit.
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Glen Zorn <[email-masked]>
Date: Wed, 11 Jul 2012 17:24:46 +0700

> In other words, am I the only one NOT knowing this? ;-)

Hmm.  draft-ietf-dime-rfc3588bis is listed as  a normative reference in
4005bis and RFC 5238 is listed as a normative reference in
draft-ietf-dime-rfc3588bis.  My understanding is that one cannot expect
to read and understand an RFC without having read and understood the
normative references thereof.  Is my understanding correct?  If so, then
there is in fact no need to mention it since any reader cognizant of
that requirement will already know (or could easily refresh the memory
of) what the notation means.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 11 Jul 2012 17:27:23 +0700

> follows the rules described in RFC3588(bis). 

Actually, the references to 3588bis are abundant, explicit and
normative...

> 
>  
> 
> About Dieter’s comment, the CCF specification of a command is clearly
> further details, so I don’t think that it is needed to provide again

Indeed.

...

---

From: Glen Zorn <[email-masked]>
Date: Wed, 11 Jul 2012 17:45:58 +0700

On Wed, 2012-07-11 at 11:05 +0200, Benoit Claise wrote:
> 1. the NASREQ application is specified in RFC4005bis, but IANA points
> to RFC3588bis
> See
> I understand the history: RFC3588 introduced this application id value
> 1 in the IANA Considerations section. 
> http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45  should contain

Obviously, I don't agree.  The value was registered in RFC 3588, and
there is nothing to "correct" unless of course you insist, as does at
least one IESG member, that the IANA references always point to the
technical definition of the registered item (a position so untenable as
to be absurd).

> 
> 
> 2.  In section 3.10 Accounting-Answer (ACA) Command 
> 

Sorry, I don't understand.

> Why does this apply only to Accounting-Request and Accounting-Answer?

The answer to that question is likely lost in the mists of time ;-).  I
surely don't remember why...

...

---

From: <[email-masked]>
Date: Wed, 11 Jul 2012 15:56:11 +0000

Indeed, it is old stuff!
Can we consider that this part of text is not relevant to RFC4005 (but to any Diameter application) and could be removed from this spec without impact? I think that this point will be anyway covered by the dedicated draft on E2E security.

Regards,

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Glen Zorn
Envoyé : mercredi 11 juillet 2012 12:46
À : [email-masked]
Objet : Re: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt - part 2

Two more points, part of the AD review (I needed a little bit of education before making those points, hence the part 2 in my review)

1. the NASREQ application is specified in RFC4005bis, but IANA points to RFC3588bis
See http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45
with an entry for Application id= 1, for NASREQ, with the reference [RFC-ietf-dime-rfc3588bis-33]

I understand the history: RFC3588 introduced this application id value 1 in the IANA Considerations section.
However, RFC3588bis, which will obsolete RFC3588, doesn't mention this application id (obviously, because it was assigned already).
So don't you believe that we should correct this and have, in the IANA Considerations section of http://tools.ietf.org/id/draft-ietf-dime-rfc4005bis-09.txt , a message basically expressing:
    http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-parameters-45  should contain
             Application id= 1, for NASREQ, with the reference [RFC4005bis]

Obviously, I don't agree.  The value was registered in RFC 3588, and there is nothing to "correct" unless of course you insist, as does at least one IESG member, that the IANA references always point to the technical definition of the registered item (a position so untenable as to be absurd).

   definition of such techniques is outside the scope of this document.
Note: this message about "The same level of security ..." is only available in that section

The answer to that question is likely lost in the mists of time [;-)] .  I surely don't remember why...

...

---

From: Glen Zorn <[email-masked]>
Date: Thu, 12 Jul 2012 11:39:13 +0700

On Wed, 2012-07-11 at 15:56 +0000, [email-masked] wrote:
> Indeed, it is old stuff!
> 
> Can we consider that this part of text is not relevant to RFC4005 (but
> to any Diameter application) and could be removed from this spec
> without impact? I think that this point will be anyway covered by the
> dedicated draft on E2E security.

I'm not at sure of that; I am pretty sure that there was a good reason
why the same security in both directions was specified for accounting
messages but I wasn't really part of those discussions.  Maybe Bernard
remembers?

...

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Jul 2012 23:03:25 +0200

On 11/07/2012 12:24, Glen Zorn wrote:
> Hmm.  draft-ietf-dime-rfc3588bis is listed as  a normative reference 
> in 4005bis and RFC 5238 is listed as a normative reference in 
> draft-ietf-dime-rfc3588bis.  My understanding is that one cannot 
> expect to read and understand an RFC without having read and 
> understood the normative references thereof.
Agreed on the principle, except that, in this case, we speak about an 
"*", which could mean something specific for this document: optional, a 
reference to something else, etc...

Regards, Benoit.

> Is my understanding correct?  If so, then there is in fact no need to 
> mention it since any reader cognizant of that requirement will already 
> know (or could easily refresh the memory of) what the notation means.
>
>>
>> Regards, Benoit.
>>
>>> Regards,
>>>   
>>> Lionel
>> [email-masked]  <mailto:[email-masked]>

---

From: Benoit Claise <[email-masked]>
Date: Thu, 12 Jul 2012 23:09:57 +0200

Glen,
>> I understand the history: RFC3588 introduced this application id 
>> value 1 in the IANA Considerations section.
>> However, RFC3588bis, which will obsolete RFC3588, doesn't mention 
>> this application id (obviously, because it was assigned already).
>> So don't you believe that we should correct this and have, in the 
>> IANA Considerations section of 
>> http://tools.ietf.org/id/draft-ietf-dime-rfc4005bis-09.txt , a 
>> message basically expressing:
> technical definition of the registered item (a position so untenable 
> as to be absurd).
So right now, "application id = 1" points to RFC 3588bis, which is 
neither the RFC that registered the value (RFC3588), nor the NASREQ 
specification (RFC4005bis), so the pointer to RFC 3588bis seems pretty 
useless to me.
Anyway, I sent a private email to Michelle Cotton a few days ago (and I 
copied her again on this email thread).
My advice is to simply follow the IANA guidance.

Regards, Benoit.
> The answer to that question is likely lost in the mists of time ;-).  
> I surely don't remember why...
>

---

From: Glen Zorn <[email-masked]>
Date: Fri, 13 Jul 2012 11:17:00 +0700

On Thu, 2012-07-12 at 23:09 +0200, Benoit Claise wrote:
> > there is nothing to "correct" unless of course you insist, as does
> > at least one IESG member, that the IANA references always point to
> > the technical definition of the registered item (a position so
> > untenable as to be absurd).
> 

I couldn't agree more.

> Anyway, I sent a private email to Michelle Cotton a few days ago (and
> I copied her again on this email thread).

Actually, I'd like to see some guidance from the IESG; something that is
both consistent and completethat states the semantics of the IANA
reference field or, lacking that, a little less anal-retention WRT
positions which are clearly neither consistent nor complete on those
semantics.

...

---

From: Glen Zorn <[email-masked]>
Date: Fri, 13 Jul 2012 11:27:55 +0700

On Thu, 2012-07-12 at 23:03 +0200, Benoit Claise wrote:
> > > Is this so obvious to the Diameter readers, including the
> > > newcomers, that we don't need to mention it?
> "*", which could mean something specific for this document: optional,
> a reference to something else, etc...

How about this?

OLD:
3.  Diameter NAS Application Messages

   This section defines the Diameter message Command-Code
   [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all
   Diameter implementations conforming to this specification.  The
   Command Codes are as follows:

   +-----------------------------------+---------+------+--------------+
   | Command Name                      | Abbrev. | Code | Reference    |
   +-----------------------------------+---------+------+--------------+
   | AA-Request                        |   AAR   |  265 | Section 3.1  |
   | AA-Answer                         |   AAA   |  265 | Section 3.2  |
   | Re-Auth-Request                   |   RAR   |  258 | Section 3.3  |
   | Re-Auth-Answer                    |   RAA   |  258 | Section 3.4  |
   | Session-Termination-Request       |   STR   |  275 | Section 3.5  |
   | Session-Termination-Answer        |   STA   |  275 | Section 3.6  |
   | Abort-Session-Request             |   ASR   |  274 | Section 3.7  |
   | Abort-Session-Answer              |   ASA   |  274 | Section 3.8  |
   | Accounting-Request                |   ACR   |  271 | Section 3.9  |
   | Accounting-Answer                 |   ACA   |  271 | Section 3.10 |
   +-----------------------------------+---------+------+--------------+

NEW:
3.  Diameter NAS Application Messages

   This section defines the Diameter message Command-Code
   [I-D.ietf-dime-rfc3588bis] values that MUST be supported by all
   Diameter implementations conforming to this specification.  The
   Command Codes are as follows:

   +-----------------------------------+---------+------+--------------+
   | Command Name                      | Abbrev. | Code | Reference    |
   +-----------------------------------+---------+------+--------------+
   | AA-Request                        |   AAR   |  265 | Section 3.1  |
   | AA-Answer                         |   AAA   |  265 | Section 3.2  |
   | Re-Auth-Request                   |   RAR   |  258 | Section 3.3  |
   | Re-Auth-Answer                    |   RAA   |  258 | Section 3.4  |
   | Session-Termination-Request       |   STR   |  275 | Section 3.5  |
   | Session-Termination-Answer        |   STA   |  275 | Section 3.6  |
   | Abort-Session-Request             |   ASR   |  274 | Section 3.7  |
   | Abort-Session-Answer              |   ASA   |  274 | Section 3.8  |
   | Accounting-Request                |   ACR   |  271 | Section 3.9  |
   | Accounting-Answer                 |   ACA   |  271 | Section 3.10 |
   +-----------------------------------+---------+------+--------------+

Note that the message formats in the following sub-sections use the
standard Diameter Command Code Format ([I-D.ietf-dime-rfc3588bis],
Section 3.2).

> 
> Regards, Benoit.
> 
> 
> 
> > Is my understanding correct?  If so, then there is in fact no need
> > to mention it since any reader cognizant of that requirement will
> > already know (or could easily refresh the memory of) what the
> > notation means.
> > 
> > 
> > > 
> > > Regards, Benoit.
> > > 
> > > 
> > > > Regards,
> > > >  
> > > > Lionel

---

From: Glen Zorn <[email-masked]>
Date: Fri, 13 Jul 2012 12:36:44 +0700

On Wed, 2012-07-11 at 15:56 +0000, [email-masked] wrote:
> without impact? 

In that case, shouldn't it be added to 3588bis?

> I think that this point will be anyway covered by the dedicated draft
> on E2E security.

I'm not sure that it is necessarily specific to e2e security because I
can imagine cases in which requests and answers could reasonably have
asymmetrical security properties.  Also, could it happen with SCTP/DTLS?

...

---

From: <[email-masked]>
Date: Fri, 13 Jul 2012 06:41:41 +0000

Fine for me.

Lionel

De : [email-masked] [mailto:[email-masked]] De la part de Glen Zorn
Envoyé : vendredi 13 juillet 2012 06:28
À : Benoit Claise
Cc : [email-masked]
Objet : Re: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt

Hi Lionel,

Hi Benoit,

                          [ CHAP-Auth ]

                          [ CHAP-Challenge ]

                        * [ Framed-Compression ]

                          [ Framed-Interface-Id ]

                          [ Framed-IP-Address ]

                        * [ Framed-IPv6-Prefix ]

                          [ Framed-IP-Netmask ]

                          [ Framed-MTU ]

                          [ Framed-Protocol ]

                          [ ARAP-Password ]

                          [ ARAP-Security ]

                        * [ ARAP-Security-Data ]

                        * [ Login-IP-Host ]

                        * [ Login-IPv6-Host ]

                          [ Login-LAT-Group ]

                          [ Login-LAT-Node ]

                          [ Login-LAT-Port ]

                          [ Login-LAT-Service ]

                        * [ Tunneling ]

                        * [ Proxy-Info ]

                        * [ Route-Record ]

                        * [ AVP ]

Hmm.  draft-ietf-dime-rfc3588bis is listed as  a normative reference in 4005bis and RFC 5238 is listed as a normative reference in draft-ietf-dime-rfc3588bis.  My understanding is that one cannot expect to read and understand an RFC without having read and understood the normative references thereof.
Agreed on the principle, except that, in this case, we speak about an "*", which could mean something specific for this document: optional, a reference to something else, etc...

How about this?

OLD:

NEW:

Note that the message formats in the following sub-sections use the standard Diameter Command Code Format ([I-D.ietf-dime-rfc3588bis], Section 3.2).

Regards, Benoit.

Is my understanding correct?  If so, then there is in fact no need to mention it since any reader cognizant of that requirement will already know (or could easily refresh the memory of) what the notation means.

Regards, Benoit.

Regards,

Lionel

Thank you.

DiME mailing list

[email-masked]<mailto:[email-masked]>

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 13 Jul 2012 07:32:45 +0000

Hi Glen,

I don’t think that asymmetrical security may be set up when considering diameter connections over TLS/DTLS or IPsec.  But I may be wrong.

However, as you highlight it, this should be covered in the security considerations of the 3588bis. I would then recommend removing the text from the RFC4005bis and seeing if something is missing in the section 13 of RFC3588bis. I think that the current text is ok but someone could find something missing.

Would it be OK?

Regards,

Lionel

De : Glen Zorn [mailto:[email-masked]]
Envoyé : vendredi 13 juillet 2012 07:37
À : MORAND Lionel RD-CORE
Cc : [email-masked]; [email-masked]
Objet : RE: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt - part 2

Can we consider that this part of text is not relevant to RFC4005 (but to any Diameter application) and could be removed from this spec without impact?

I think that this point will be anyway covered by the dedicated draft on E2E security.

I'm not sure that it is necessarily specific to e2e security because I can imagine cases in which requests and answers could reasonably have asymmetrical security properties.  Also, could it happen with SCTP/DTLS?

...

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 Jul 2012 15:13:20 +0200

Glen,

That works for me.

Regards, Benoit.
>
> Fine for me.
>
> Lionel
>
> *De :[email-masked] [mailto:[email-masked]] *De la part 
> de* Glen Zorn
> *Envoyé :* vendredi 13 juillet 2012 06:28
> *À :* Benoit Claise
> *Cc :* [email-masked]
> *Objet :* Re: [Dime] AD review of draft-ietf-dime-rfc4005bis-09.txt
>
>         Hmm.  draft-ietf-dime-rfc3588bis is listed as  a normative
>         reference in 4005bis and RFC 5238 is listed as a normative
>         reference in draft-ietf-dime-rfc3588bis.  My understanding is
>         that one cannot expect to read and understand an RFC without
>         having read and understood the normative references thereof.
>
>     Agreed on the principle, except that, in this case, we speak about
>     an "*", which could mean something specific for this document:
>     optional, a reference to something else, etc...
>
>
> How about this?
>
> OLD:

---

From: Benoit Claise <[email-masked]>
Date: Fri, 13 Jul 2012 15:14:39 +0200

On 13/07/2012 06:17, Glen Zorn wrote:
>> specification (RFC4005bis), so the pointer to RFC 3588bis seems 
>> pretty useless to me.
>
> I couldn't agree more.
>
> Actually, I'd like to see some guidance from the IESG; something that 
> is both consistent and completethat states the semantics of the IANA 
Let me follow up and get back to you.
IMHO, this is a blocking factor for the draft next step, i.e. IETF 
last-call: this could be solved in parallel.
So if you want to produce a new draft version, the IETF last-call could 
start.

Regards, Benoit.
>
> ... <mailto:[email-masked]>

---

From: Glen Zorn <[email-masked]>
Date: Sat, 14 Jul 2012 13:08:31 +0700

On Fri, 2012-07-13 at 15:14 +0200, Benoit Claise wrote:
> > > > > Two more points, part of the AD review (I needed a little bit
> > > > > of education before making those points, hence the part 2 in
> > > > > my review)
> > > > > 
> > > > > I understand the history: RFC3588 introduced this application
> > > > > id value 1 in the IANA Considerations section. 
> > > > > However, RFC3588bis, which will obsolete RFC3588, doesn't
> > > > > mention this application id (obviously, because it was
> > > > > assigned already). 
> > > > > So don't you believe that we should correct this and have, in
> > > > > the IANA Considerations section of
> > > > Obviously, I don't agree.  The value was registered in RFC 3588,
> > > > and there is nothing to "correct" unless of course you insist,
> > > > as does at least one IESG member, that the IANA references
> > > > always point to the technical definition of the registered item
> > > > (a position so untenable as to be absurd).
> > > 
> > > neither the RFC that registered the value (RFC3588), nor the
> > > NASREQ specification (RFC4005bis), so the pointer to RFC 3588bis
> > > seems pretty useless to me.
> > 
> > 
> > I couldn't agree more.
> > 
> > 
> > > Anyway, I sent a private email to Michelle Cotton a few days ago
> > > (and I copied her again on this email thread).
> > Actually, I'd like to see some guidance from the IESG; something
> > that is both consistent and completethat states the semantics of the
> > IANA reference field or, lacking that, a little less anal-retention
> > WRT positions which are clearly neither consistent nor complete on
> > those semantics.
> 
> So if you want to produce a new draft version, the IETF last-call
> could start.

OK.

---

From: Benoit Claise <[email-masked]>
Date: Sat, 14 Jul 2012 10:06:52 +0200

Glen,
>> IMHO, this is a blocking factor for the draft next step,
Oups. One typo. You should read : "IMHO, this is NOT a blocking factor 
for the draft next step,"
 From your reply below, you understood it was a mistake.
>> i.e. IETF last-call: this could be solved in parallel.
Regards, Benoit.

---

From: Glen Zorn <[email-masked]>
Date: Sun, 15 Jul 2012 11:51:05 +0700

> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-dime-rfc4005bis-09.txt

Rereading this, I don't know what confusion you mean.  It seems to be
fine English, pretty clear, and it doesn't seem like the change you
suggest is likely to unconfuse ID-nits.  What am I missing?

---

From: Glen Zorn <[email-masked]>
Date: Sun, 15 Jul 2012 12:05:57 +0700

...

>                                Registry", <http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1>.

Neither of these actually works, since the registry cited is not the
RADIUS Attribute Type registry but the RADIUS Attribute Value registry;
changed to
http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-3.

---

From: Glen Zorn <[email-masked]>
Date: Sun, 15 Jul 2012 12:15:44 +0700

On Fri, 2012-07-13 at 07:32 +0000, [email-masked] wrote:
> Hi Glen,
> 
>  
> 
> I don’t think that asymmetrical security may be set up when
> considering diameter connections over TLS/DTLS or IPsec.  But I may be
> wrong.
> 
>  
> 
> However, as you highlight it, this should be covered in the security
> considerations of the 3588bis. I would then recommend removing the
> text from the RFC4005bis and seeing if something is missing in the
> section 13 of RFC3588bis. I think that the current text is ok but
> someone could find something missing.
> 
>  
> 
> Would it be OK?

OK w/me.

...

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Jul 2012 02:08:09 +0200

On 15/07/2012 07:05, Glen Zorn wrote:
>>                                 Registry",<http://www.iana.org/  <http://www.iana.org/assignments/radius-types-3>
>>                                 assignments/radius-types-3>  <http://www.iana.org/assignments/radius-types-3>.
>>
>> NEW:
>>                                 Registry",<http://www.iana.org/  <http://www.iana.org/assignments/radius-types>
>>                                 assignments/radius-types>  <http://www.iana.org/assignments/radius-types>.
>>
>> ALTERNATE PROPOSAL
>>                                 Registry",<http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1>  <http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-1>.
>>
>
> RADIUS Attribute Type registry but the RADIUS Attribute Value 
> registry; changed to 
Ok. fine.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 17 Jul 2012 02:12:06 +0200

Hi Glen,
>> I understand that this is a quote from RFC4005. To avoid the source 
>> of confusion, here is a proposal
>
This proposal will not unconfuse ID-nits, but would make clear to the 
reader that this is a quote, and nobody would look for the [BASE] 
reference ... as this is quote from a different document.
Anyway, minor point. Change it in a next version if you believe that's 
an improvement.
>> - I could not find the meaning of * in, for example,
I believe that you have forgotten to include your proposed text:

Regards, Benoit.