Subject: [Pana] Allocation policy for mandatory-to-support AVP

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Oct 2006 15:18:45 -0400

I had a discussion with Lionel Morand with regard to AVP Code
allocation policy for a mandatory-to-support AVP (i.e., an AVP with
'M' bit set).

If a new mandatory-to-support AVP is used for a mandatory-to-support
feature, a new version of base specification would be needed to add a
new mandatory-to-support AVP, regardless of whether the feature is
mandatory or optional to use.

On the other hand, if a new mandatory-to-support AVP is used for an
optional-to-support feature, then a new version of base specification
would not be needed for such an AVP.  But a question here is: does it
make sense to define a new mandatory-to-support AVP for realizing an
optional-to-support feature?

Regards,
Yoshihiro Ohba

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 25 Oct 2006 11:00:18 -0400

Hi Lionel,

I agree with your observation.

How about revising the following text in Section 10.3.1:

"
   AVPs may be allocated following Designated Expert with Specification
   Required [IANA].  Release of blocks of AVPs (more than 3 at a time
   for a given purpose) should require IETF Consensus.
"

to:

"
   AVPs may be allocated following Standards Action or Designated
   Expert with Specification Required [IANA].  A mantatory-to-support
   AVP used for realizing a mandatory PANA feature should
   require a new version of this specification.
"

Note: The "Release of blocks of AVPs" exception is removed according
to AD's comment.

Also, I think that a similar consideration is needed for Message Type
allocation policy.  I would suggest changing Section 10.2.1 from:

"
10.2.1.  Message Type

   The Message Type namespace is used to identify PANA messages.  Values
   0-65,533 are for permanent, standard message types, allocated by IETF
   Consensus [IANA].  This document defines the Message Types 1-9.  See
   Section 7.1 through Section 7.17 for the assignment of the namespace
   in this specification.

   The values 65,534 and 65,535 (hexadecimal values 0xfffe - 0xffff) are
   reserved for experimental messages.  As these codes are only for
   experimental and testing purposes, no guarantee is made for
   interoperability between the communicating PaC and PAA using
   experimental commands, as outlined in [IANA-EXP].
"

to:

"
10.2.1.  Message Type

   The Message Type namespace is used to identify PANA messages.
   Values 0-65,519 are for permanent, standard message types,
   allocated by Standards Action or IETF Consensus [IANA].  A Message Type 
   used for realizing a mandatory PANA feature should
   require a new version of this specification.  This
   document defines the Message Types 1-9.  See Section 7.1 through
   Section 7.17 for the assignment of the namespace in this
   specification.

   The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff) are
   reserved for experimental messages.  As these codes are only for
   experimental and testing purposes, no guarantee is made for
   interoperability between the communicating PaC and PAA using
   experimental commands, as outlined in [IANA-EXP].
"

Note: The range for experimental messages is increased to have 16
experimental messages types instead of 2.  This is also according to
AD's comment.

Best regards,
Yoshihiro Ohba

On Wed, Oct 25, 2006 at 09:31:01AM +0200, MORAND Lionel RD-CORE-ISS wrote:
>  Hi Yoshi,
> 
> > -----Message d'origine-----
> > De : Yoshihiro Ohba [mailto:[email-masked]] 
> > Envoyé : mardi 24 octobre 2006 21:19
> > À : [email-masked]
> > Objet : [Pana] Allocation policy for mandatory-to-support AVP
> > 
> > allocation policy for a mandatory-to-support AVP (i.e., an 
> > AVP with 'M' bit set).
> > 
> > If a new mandatory-to-support AVP is used for a 
> > mandatory-to-support feature, a new version of base 
> > specification would be needed to add a new 
> > mandatory-to-support AVP, regardless of whether the feature 
> > is mandatory or optional to use.
> > 
> > On the other hand, if a new mandatory-to-support AVP is used 
> > for an optional-to-support feature, then a new version of 
> > base specification would not be needed for such an AVP.  But 
> > a question here is: does it make sense to define a new 
> > mandatory-to-support AVP for realizing an optional-to-support feature?
> 
> [Lionel] An AVP defined with the M-bit means that it must not be ignored if not supported by the receiver and a diameter error response must be sent back to the sender. An optional feature may be defined as a specific procedure that applies in specific cases only and may need some specific AVPs to support such a feature. Therefore, all PANA implementations will not have to support this feature and the use of the specific AVPs is not required. But if this feature is used in a specific case, the associated AVPs have to be supported by both PANA end-points and therefore defined with the M-bit set.
> 
> A a consequence, the handling of the PANA version number should be:
> - A new version number for introduction of new mantatory-to-support AVP for a new mandatory PANA feature
> - No change of the version number for introduction of new mantatory-to-support AVP used for an new optional PANA feature.
> 
> > 
> > Regards,
> > Yoshihiro Ohba
> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 30 Oct 2006 14:08:13 -0500

Hi Lionel,

On Mon, Oct 30, 2006 at 06:09:42PM +0100, MORAND Lionel RD-CORE-ISS wrote:
> Hi Yoshi,
> 
> I'm not sure that the wording "mandatory-to-support AVP" is self-explicit enough.
> It would propose to use "AVP with the 'M' bit set" instead of "mandatory-to-support AVP".
> 
> Moreover, if new AVPs with M-bit set are allocated after standard actions or designated expert review, and these AVP are needed to support mandatory PANA features, I think that it is mandatory to update the PANA version number. Therefore, a "MUST" is more appropriate than a "SOULD" in that case.
> 
>  According to the above comments, I would propose to revise the existing text as follow:
> 
>  "
>    AVPs may be allocated following Designated Expert with 
>    Specification Required [IANA].  Release of blocks of AVPs
>   (more than 3 at a time for a given purpose) should require
>   IETF Consensus.
>  "
>  
>  to:
>  
>  "
>     Expert with Specification Required [IANA].  In the event of the 
>     allocation of new AVPs used with the 'M' bit set for realizing a
>    mandatory PANA feature, a new version of this specification must be created.
>  "

Agreed.

> 
> I have some additional questions:
> Who is responsible for the update of the protocol version number?
> Should we define a specific namespace in the IANA section, managed by Designated Expert with Specification Required?
> 
> I don't know if something similar exists for another protocol. For instance, the RFC 3588 indicates that the Diameter base protocol version number must be updated if a new AVP format is defined but it is not described how to do it.

This is a good point.  It is definitely better to have an IANA
namespace for PANA version with Standards Action required.  
Here are suggested changes:

[1] Change

"
   As defined in Section 6.2, the PANA header contains two fields that
   requires IANA namespace management; the Message Type and Flags field.
"

to:

"
   As defined in Section 6.2, the PANA header contains three fields
   that requires IANA namespace management; the Version, Message Type
   and Flags fields.
"

[2] Insert the following paragraph:

"
10.2.1.  Version

The Version namespace is used for identifing PANA versions.  Version 0
is not used.  This document defines Version 1.  Versions must be
allocated by Standards Action with new versions of this specification.
"

Yoshihiro Ohba

> BR,
> Lionel
> > Envoyé : mercredi 25 octobre 2006 17:00
> > À : MORAND Lionel RD-CORE-ISS
> > Cc : Yoshihiro Ohba; [email-masked]
> > Objet : Re: [Pana] Allocation policy for mandatory-to-support AVP
> > 
> > Hi Lionel,
> > 
> > Note: The "Release of blocks of AVPs" exception is removed 
> > according to AD's comment.
> > 
> > Also, I think that a similar consideration is needed for 
> > Message Type allocation policy.  I would suggest changing 
> > Section 10.2.1 from:
> > 
> > "
> > 10.2.1.  Message Type
> > 
> > Note: The range for experimental messages is increased to 
> > have 16 experimental messages types instead of 2.  This is 
> > also according to AD's comment.
> > 
> > Best regards,
> > Yoshihiro Ohba
> > 
> > 
> > 
> > > > Envoy？ : mardi 24 octobre 2006 21:19
> > > > ？ : [email-masked]
> > mandatory-to-support 
> > > > feature, a new version of base specification would be 
> > needed to add 
> > > > a new mandatory-to-support AVP, regardless of whether the 
> > feature is 
> > > > optional-to-support feature, then a new version of base 
> > > > specification would not be needed for such an AVP.  But a 
> > question 
> > > > here is: does it make sense to define a new 
> > mandatory-to-support AVP 
> > > > for realizing an optional-to-support feature?
> > > 
> > > [Lionel] An AVP defined with the M-bit means that it must 
> > not be ignored if not supported by the receiver and a 
> > diameter error response must be sent back to the sender. An 
> > optional feature may be defined as a specific procedure that 
> > applies in specific cases only and may need some specific 
> > AVPs to support such a feature. Therefore, all PANA 
> > implementations will not have to support this feature and the 
> > use of the specific AVPs is not required. But if this feature 
> > is used in a specific case, the associated AVPs have to be 
> > supported by both PANA end-points and therefore defined with 
> > the M-bit set.
> > > 
> > > - No change of the version number for introduction of new 
> > mantatory-to-support AVP used for an new optional PANA feature.
> > > 
> > > > 
> > > > Regards,
> > > > Yoshihiro Ohba
> > > >