Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft

From: Gerhard Muenz <[email-masked]>
Date: Tue, 17 Jun 2008 15:16:23 +0200

Dear all,

Nevil Brownlee wrote:
> draft-ietf-ipfix-exporting-type-01.txt was published back in February;
> this version resolved all issues raised in earlier versions, and there's
> been no discussion on the IPFIX list since.
>
> Its Working Group Last Call starts now (5 June 08), and will finish
> on Friday 20 June 08.
>
> Please read it one more time - I need some reviews so that I can prepare
> the Shepherd Document for it.  And of course, please send any or all
> your comments/feedback to the IPFIX list.

Please find my review comments below.

Regards,
Gerhard

> 1.1. IPFIX Documents Overview

Maybe stress relevant relationships to this document:
RFC 5102: specifies abstract data types and additional data type semantics
RFC 5101: specifies the encoding of the data types

> 3.1.  informationElementDataType

Maybe change to informationElementAbstractDataType to be more precise.

>    Description:   A description of the storage type of an IPFIX
>       information element.  These correspond to the abstract data types

You introduce a new term "storage type". What is it? Is it necessary to
use this term instead of "abstract data type"?

>       defined in section 3.1 of the IPFIX Information Model [RFC5102];
>       see that section for more information on the types described
>       below.  This field may take the following values:

> 3.6.  informationElementSemantics

Maybe call this informationElementDataTypeSemantic?

> 
>    Description:   A description of the semantics of an IPFIX information
>       element.  These correspond to the data type semantics defined in

Why do these semantics "correspond" to the data type semantics in RFC
5102? They "are" the data type semantics.
=> A description of the data type semantics of an IPFIX information
element.

>       section 3.2 of the IPFIX Information Model [RFC5102]; see that
>       section for more information on the types described below.  This
>       field may take the following values; the special value 0x00 (none)
>       is used to note that no semantics apply to the field; it cannot be
>       manipulated by a Collecting Process or File Reader that does not
>       understand it a priori.

> 3.8.  privateEnterpriseNumber
> 
>    Description:   A private enterprise number used to scope an
>       informationElementID, as would appear in an IPFIX Template Record.
>       This element can be used to scope properties to a specific
>       Information Element.  If the Enterprise ID bit of the

What is "Enterprise ID bit"?
Do you mean "Enterprise bit" as in RFC 5101?

>       corresponding Information Element is cleared (has the value 0),
>       this IE should be set to 0.  The presence of a non-zero value in
>       this IE implies that the Enterprise ID bit of the corresponding
>       Information Element is set (has the value 1).

How does this map to the example in the appendix?

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Set ID = 257         |          Length =  50         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            PEN 6871                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           IE 14               |0x01 unsigned8 |0x05 flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here, the Enterprise bit is not set (14=0x000E), but the PEN is not zero.

> 3.9.  Information Element Type Options Template

>    Similarly, for security reasons, type information for a given
>    Information Element MUST NOT be re-defined by Information Element
>    type records, and a Collecting Process MUST NOT allow an Information
>    Element type record to replace its own internal definition of an
>    Information Element.  Information Element type records SHOULD NOT be
>    duplicated within a Transport Session, but once an Information
>    Element type record has been exported for a given Information Element
>    within a given Transport Session, all subsequent type records for
>    that Information Element MUST be identical.  Conflicting semantic or
>    type information MUST be ignored by a Collecting Process.

Maybe repeat the scope of these restrictions: Transport Session + OD.

>    +-------------------------------+-----------------------------------+
>    | IE                            | Description                       |
>    +-------------------------------+-----------------------------------+
>    | informationElementID          | The Information Element           |
>    |                               | identifier of the Information     |
>    |                               | Element within the specified      |
>    |                               | Template this record describes.   |

Does the record describe the IE or the record? Rephrasing suggested.

>    |                               | This Information Element MUST be  |
>    |                               | defined as a Scope Field.  See    |
>    |                               | the PSAMP Information Model       |
>    |                               | [I-D.ietf-psamp-info] for a       |
>    |                               | definition of this field.         |
>    | privateEnterpriseNumber       | The Private Enterprise number of  |
>    |                               | the Information Element within    |
>    |                               | the specified Template this       |
>    |                               | record describes.  This           |

same as before

>    |                               | Information Element MUST be       |
>    |                               | defined as a Scope Field.         |

> 3.10.  Data Type and Semantics Restrictions
> 
>    Note that the informationElementSemantics values are primarily
>    intended to differentiate semantic interpretation of numeric values,
>    and that not all combinations of the informationElementDataType and
>    informationElementSemantics Information Elements are valid; e.g., a
>    counter cannot be encoded as an IPv4 address.  Any
>    informationElementSemantics value is valid for unsigned
>    informationElementDataType values ("unsigned8", "unsigned16",
>    "unsigned32", or "unsigned64").  Any informationElementSemantics
>    value except flags is valid for signed informationElementDataType
>    values ("signed8", "signed16", "signed32", or "signed64").  Any
>    informationElementSemantics value except "identifier" or "flags" is
>    valid for floating-point informationElementDataType values ("float32"
>    or "float64").  Only the informationElementSemantics value "none" is
>    valid for all other other informationElementDataType values
>    ("octetArray", "boolean", "macAddress", "string", "dateTimeSeconds",
>    "dateTimeMilliseconds", "dateTimeMicroseconds",
>    "dateTimeNanoseconds", "ipv4Address", or "ipv6Address").

Add reference to RFC 5102 section 3.2 where these limitations are
already specified.

> Appendix A.  Examples

See comment to section 3.8.

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 17 Jun 2008 15:16:23 +0200

Dear all,

Regards,
Gerhard

                        1                   2                   3

same as before

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 18 Jun 2008 10:18:37 +0200

Dear all,

I forgot two more things in my review:

In RFC 5102, abstract data types and data type semantics are explained
in subsequent sections. Therefore, I would also move the definition of
informationElementSemantics IE right after the definition of
informationElementDataType IE:
3.1.  informationElementDataType
3.6. => 3.2  informationElementSemantics

Secondly, the definition of the privateEnterpriseNumber IE allows zero
values although type information must not be exported for non-enterprise
IEs.
Is this because the definition of privateEnterpriseNumber is to be
generic and not restricted to the usage of type information export?
If so, I would add a note that in the context of this draft,
privateEnterpriseNumber must From [email-masked]  Wed Jun 18 01:18:02 2008
Date: Wed, 18 Jun 2008 10:18:37 +0200
From: Gerhard Muenz <[email-masked]>
To: IETF IPFIX Working Group <[email-masked]>
Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

This is a cryptographically signed message in MIME format.

Dear all,

I forgot two more things in my review:

In RFC 5102, abstract data types and data type semantics are explained
in subsequent sections. Therefore, I would also move the definition of
informationElementSemantics IE right after the definition of
informationElementDataType IE:
3.1.  informationElementDataType
3.6. => 3.2  informationElementSemantics

Secondly, the definition of the privateEnterpriseNumber IE allows zero
values although type information must not be exported for non-enterprise
IEs.
Is this because the definition of privateEnterpriseNumber is to be
generic and not restricted to the usage of type information export?
If so, I would add a note that in the context of this draft,
privateEnterpriseNumber musnot be zero.

Regards,
Gerhard

Gerhard Muenz wrote:
>>    type records, and a Collectingt not be zero.

Regards,
Gerhard

Gerhard Muenz wrote:
>>    type records, and a Collecti Process MUST NOT allow an Information
> ------------------------------------------------------------------------
> 

WWW:    http://net.informatik.uning Process MUST NOT allow an Information
> ------------------------------------------------------------------------
>

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jun 2008 14:35:39 +0200

Gerhard,

Thank you for the review! Comments inline; additional comments follow  
in a subsequent message.

Regards,

Brian

On Jun 17, 2008, at 3:16 PM, Gerhard Muenz wrote:

>> your comments/feedback to the IPFIX liFrom [email-masked]  Thu Jun 19 05:34:58 2008
From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jun 2008 14:35:39 +0200
To: Gerhard Muenz <[email-masked]>
Cc: IETF IPFIX Working Group <[email-masked]>
Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

Gerhard,

Thank you for the review! Comments inline; additional comments follow  
in a subsequent message.

Regards,

Brian

On Jun 17, 2008, at 3:16 PM, Gerhard Muenz wrote:

>> your comments/feedback to the IPFIX st.
>

Agree. I've made this change in a working -02.

> use this term instead of "abstract data type"?

Nope. Sorry. I wrote this paragraph, and "storage type" is a bit of  
terminology from an somewhat related system I used to work on, which  
must have crept over to IPFIX in my brain. Fixed.

> Maybe call this informationElementDataTypeSemantic?

This was considered, as I recall, and we shortened explicitly because  
as an information element name, informationElementDataTypeSemantics  
is simply too long, and shares a large initial substring with  
informationElementDataType, with which it should not be confused.

> => A description of the data type semantics of an IPFIX information

Hm. Right. This makes sense. I've made a parallel change for  
informationElementDataType.
> Do you mean "Enterprise bit" as in RFC 5101?

Yes. Fixed.

> How does this map to the example in the appendix?

Hm. The intention here is that the informationElementId be the _base_  
information element ID, without the enterprise bit; in other words,  
((the IE number from the template) & ~0x8000). However, reading  
section 8.2.3. of the PSAMP Info doculist.
> RFC 5101: specifies the encoding of the data types

Agree. I've made this change in a working -02.

> use this term instead of "abstract data type"?

Nope. Sorry. I wrote this paragraph, and "storage type" is a bit of  
terminology from an somewhat related system I used to work on, which  
must have crept over to IPFIX in my brain. Fixed.

> Maybe call this informationElementDataTypeSemantic?

This was considered, as I recall, and we shortened explicitly because  
as an information element name, informationElementDataTypeSemantics  
is simply too long, and shares a large initial substring with  
informationElementDataType, with which it should not be confused.

> => A description of the data type semantics of an IPFIX information

Hm. Right. This makes sense. I've made a parallel change for  
informationElementDataType.
> Do you mean "Enterprise bit" as in RFC 5101?

Yes. Fixed.

> How does this map to the example in the appendix?

Hm. The intention here is that the informationElementId be the _base_  
information element ID, without the enterprise bit; in other words,  
((the IE number from the template) & ~0x8000). However, reading  
section 8.2.3. of the PSAMP Info doment (which is now in  
Publication Requested state), such is not stated, because the  
definition was written, I think, without considering enteprise- 
specific IEs.

So, the privateEnterpriseNumber IE could be defined so as to fix  
this. If the PEN IE is present, then the high bit in  
informationElementID is ignored. This would seem to be be the most  
"be liberal in what you accept" way to address this...

> Maybe repeat the scope of these restrictions: Transport Session + OD.

Hm. Isn't this implied by 5101?

>>    | IE                            |  
>> Description                       |

hmm. the mention of a template here is spurious, too. Will rephrase.

>>    |                               | the specified Template  

likewise.

>>   cument (which is now in  
Publication Requested state), such is not stated, because the  
definition was written, I think, without considering enteprise- 
specific IEs.

So, the privateEnterpriseNumber IE could be defined so as to fix  
this. If the PEN IE is present, then the high bit in  
informationElementID is ignored. This would seem to be be the most  
"be liberal in what you accept" way to address this...

> Maybe repeat the scope of these restrictions: Transport Session + OD.

Hm. Isn't this implied by 5101?

>>    | IE                            |  
>> Description                       |

hmm. the mention of a template here is spurious, too. Will rephrase.

>>    |                               | the specified Template  

likewise.

> Add reference to RFC 5102 section 3.2 where these limitations are

Hm. These limitations are implied, I think, by the language in 3.2,  
but not at all explicitly specified... but yes, we could add a  
reminder ref to the first sentence for readability.

Thanks again, and regards,

Brian

> Add reference to RFC 5102 section 3.2 where these limitations are

Hm. These limitations are implied, I think, by the language in 3.2,  
but not at all explicitly specified... but yes, we could add a  
reminder ref to the first sentence for readability.

Thanks again, and regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jun 2008 14:36:24 +0200

Begin forwarded message:

> Date: June 19, 2008 2:35:55 PM GMT+02:00
> On Jun 18, 2008, at 10:18 AM, Gerhard Muenz wrote:
>
>>
>> Dear all,
>>
> The sections are arranged in alphabetical order so as to allow the  
> IEs to be found by name quickly; the proposed rearrangement would  
> break tFrom [email-masked]  Thu Jun 19 05:35:40 2008
To: IETF IPFIX Working Group <[email-masked]>
From: Brian Trammell <[email-masked]>
Date: Thu, 19 Jun 2008 14:36:24 +0200
Subject: [IPFIX] Fwd:  WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

Begin forwarded message:

> Date: June 19, 2008 2:35:55 PM GMT+02:00
> On Jun 18, 2008, at 10:18 AM, Gerhard Muenz wrote:
>
>>
>> Dear all,
>>
> The sections are arranged in alphabetical order so as to allow the  
> IEs to be found by name quickly; the proposed rearrangement would  
> breakhat.
>
>> privateEnterpriseNumber must not be zero.
>
> This is not a constraint imposed by this document. Within the  
> context of type information export, the PEN may be zero.
>
> The only constraint here is in Paragraph 4 of section 2.9  
> (Information Element Type OT MUST NOT redefine an IE; CP MUST  
> ignore redefinitions). This allows the potential to use this  
> mechanism to improve interoperability between IPFIX implementations  
> including different versions of the IANA registry.
>
> Regards,
>
> Brian
>
>>
>>
>> Gerhard Muenz wrote:
>>> Dear all,
>>>
>>> Nevil Brownlee wrote:
>>>>       this IE im that.
>> privateEnterpriseNumber must not be zero.
>
> This is not a constraint imposed by this document. Within the  
> context of type information export, the PEN may be zero.
>
> The only constraint here is in Paragraph 4 of section 2.9  
> (Information Element Type OT MUST NOT redefine an IE; CP MUST  
> ignore redefinitions). This allows the potential to use this  
> mechanism to improve interoperability between IPFIX implementations  
> including different versions of the IANA registry.
>
> Regards,
>
> Brian
>
>>
>>
>> Gerhard Muenz wrote:
>>> Dear all,
>>>
>>> Nevil Brownlee wrote:
>>>>       this IE plies that the Enterprise ID bit of the  
>>>> corresponding
>>>>    informationElementDatimplies that the Enterprise ID bit of the  
>>>> corresponding
>>>>    informationElementDaType values ("unsigned8", "unsigned16",

0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; =
">------------------------------------------------------------------------=
</div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: =
0px; margin-left: 0px; min-height: 14px; "><br></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; =
">_______________________________________________</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IPFIX mailing list</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"mailto:[email-masked]">[email-masked]</a></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"https://www.ietf.org/mailman/listinfo/ipfix">https://www.ietf.org/=
mailman/listinfo/ipfix</a></div> </blockquote><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">--<span =
class=3D"Apple-converted-space">=A0</span></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
">Dipl.-Ing. Gerhard M=FCnz</div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Computer =
Networks and Internet</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">Wilhelm Schickard Institute =
for Computer Science</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">University of =
Tuebingen</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">Sand 13 (Room B309), D-72076 =
Tuebingen, Germany</div><div style=3D"margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; ">Phone:<span =
class=3D"Apple-converted-space">=A0 </span>+49 7071 29-70534 <span =
class=3D"Apple-converted-space">=A0 =A0 =A0 </span>Fax: +49 7071 =
29-5220</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">E-mail: <a =
href=3D"mailto:[email-masked]">[email-masked]=
bingen.de</a></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; ">WWW:<span =
class=3D"Apple-converted-space">=A0 =A0 </span><a =
href=3D"http://net.informatik.uni-tuebingen.de/~muenz">http://net.informat=
ik.uni-tuebingen.de/~muenz</a></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: =
14px; "><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; =
">_______________________________________________</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; ">IPFIX mailing list</div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><a =
href=3D"mailto:[email-masked]">[email-masked]</a></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><a =
href=3D"https://www.ietf.org/mailman/listinfo/ipfix">https://www.ietf.org/=
mailman/listinfo/ipfix</a></div> </blockquote><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; =
min-height: 14px; "><br></div> </blockquote></div><br></body></html>=

--Apple-Mail-1--651416985--
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 19 Jun 2008 15:15:00 +0200

Hi Brian,

Brian Trammell wrote:
> This is not a constraint imposed by this document. Within the context of
> type information export, the PEN may be zero.
> 
> The only constraint here is in Paragraph 4 of section 2.9 (Information
> Element Type OT MUST NOT redefine an IE; CP MUST ignore redefinitions).
> This allows the potential to use this mechanism to improve
> interoperability between IPFIX implementations including different
> versions of the IANA registry.

The introduction says:

   Note that the solution described in this draft is only for providing
   interoperability for enterprise specific information elements that
   are not yet standardized.

Hence the document is only about enterprise-specific IEs.
According to my understanding, an enterprise-specific IE always requires
a PEN because RFC 5101 says:

   The Information Elements are identified by the Information Element
   identifier.  When the Enterprise bit is set to 0, the corresponding
   Information Element identifier will report an IETF-specified
   Information Element, and the Enterprise Number MUST NOT be present.
   When the Enterprise bit is set to 1, the corresponding Information
   Element identifier will report an enterprise-specific Information
   Element; the Enterprise Number MUST be present.  An example of this
   is shown in Section A.4.2.

PENs assigned by IANA start with 1 (0 is reserved).
http://www.iana.org/assignments/enterprise-numbers

In the definition of privateEnterpriseNumber, you assume implicitly that
the PEN is never 0 for a registered enterprise (which is ok in my opinion):

However, as the draft is about enterprise-specific IEs only, the PEN
will never be zero, and the enterprise bit will never be cleared in the
IE type information record.
Therefore, I would add a corresponding remark.

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 19 Jun 2008 15:15:00 +0200

Hi Brian,

The introduction says:

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Thu, 19 Jun 2008 15:23:51 +0200

Brian,

Brian Trammell wrote:
>>>    within a given Transport Session, all subsequent tyFrom [email-masked]  Thu Jun 19 06:23:01 2008
Date: Thu, 19 Jun 2008 15:23:51 +0200
From: Gerhard Muenz <[email-masked]>
To: Brian Trammell <[email-masked]>
Cc: IETF IPFIX Working Group <[email-masked]>
Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

Brian,

Brian Trammell wrote:
>>>    within a given Transport Session, all subsequent typepe records for

Section 3.9 starts with:

   The Information Element Type Options Template attaches type
   information to Information Elements used within Template Records, as
   scoped to an Observation Domain within a Transport Session.

When I was reading the draft, I thought that this should also be the
scope of for the restrictions mentioned in the paragraph above.
Instead, you mention Transport Session as scope:

   Information Element type records SHOULD NOT be
   duplicated within a Transport Session, but once an Information
   Element type record has been exported for a given Information Element
   within a given Transport Session, all subsequent type records for
   that Information Element MUST be identical.

That's confusing.

Regards,
Gerhard

---

From: Christoph Sommer <[email-masked]>
Date: Thu, 19 Jun 2008 17:01:51 +0200

> your comments/feedback to the IPFIX list.

Some thoughts I had when reading draft-ietf-ipfix-exporting-type-01:

Section 1.1 talks about the Protocol document covering transport "via a
congestion-aware transport protocol". IIRC RFC5101 also allows UDP. But,
besides that, how is this important for type export?

Section 1.1 starts a bit odd. One introductory sentence would make it
look a bit nicer.

Section 1.1 states "The IPFIX Protocol document [RFC5101] then covers
the details": Why "then"? Why is this mentioned here? Wouldn't this
sentence fit better into the "IPFIX Protocol documentFrom [email-masked]  Thu Jun 19 08:01:02 2008
Date: Thu, 19 Jun 2008 17:01:51 +0200
From: Christoph Sommer <[email-masked]>
To: Gerhard Muenz <[email-masked]>
Cc: IETF IPFIX Working Group <[email-masked]>
Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

> your comments/feedback to the IPFIX list.

Some thoughts I had when reading draft-ietf-ipfix-exporting-type-01:

Section 1.1 talks about the Protocol document covering transport "via a
congestion-aware transport protocol". IIRC RFC5101 also allows UDP. But,
besides that, how is this important for type export?

Section 1.1 starts a bit odd. One introductory sentence would make it
look a bit nicer.

Section 1.1 states "The IPFIX Protocol document [RFC5101] then covers
the details": Why "then"? Why is this mentioned here? Wouldn't this
sentence fit better into the "IPFIX Protocol docume" paragraph?

Section 3 says ... "followed by the Information Element Type Options
Template itself", although the term only just appeared there for the
first time.

Section 3.6 lists a special value to indicate that an IE has "no
semantics" (semantics: "none"). Wouldn't it be better to name this value
something along the lines of "opaque"?

Section 3.8 defines "privateEnterpriseNumber". All the other new IEs
begin with informationElement - why not this one? Also, the other
documents seem to favour "Enterprise Identifier" or "Enterprise ID" over
"Enterprise Number".

Section 3.9 mandates that conflicting semantics "MUST be ignored" by
collectors. This seems a bit lax, given that it indicates that the
sender might have a completely different idea of what an IE means.

Section 3.9 specifies the semantics of the IEs introduced in Section
3.4. Section 3.4 defines a new IE, informationElementRangeBegin and
additionally very strict semantics. In particular, it declares use of
the IE as invalid if no Range End is given. Section 3.9, on the other
hand, allows one or the other to be omitted. I'm generally much more in
favour of at least allowing via MAY as many IEs as possible to be
omitted from an Options Data Record without breaking the protocol. The
restriction of invalidating sets when fields are missing seems a bit harsh.

Section 3.10 restricts what data types can be used with what semantics.
Apart from the list being very hard to parse (why not make it a table?),
this also seems like it might be too harsh a restriction. If I really
want to treat an octet array as a series of flags (or an IP Address as
an identifier) -- why keep me from doing it?

Section 7.1 lists "I-D.ietf-psamp-info" as a normative reference. Is
this on purpose?

Cheers,

  Christoph

nt" paragraph?

Section 3 says ... "followed by the Information Element Type Options
Template itself", although the term only just appeared there for the
first time.

Section 3.6 lists a special value to indicate that an IE has "no
semantics" (semantics: "none"). Wouldn't it be better to name this value
something along the lines of "opaque"?

Section 3.8 defines "privateEnterpriseNumber". All the other new IEs
begin with informationElement - why not this one? Also, the other
documents seem to favour "Enterprise Identifier" or "Enterprise ID" over
"Enterprise Number".

Section 3.9 mandates that conflicting semantics "MUST be ignored" by
collectors. This seems a bit lax, given that it indicates that the
sender might have a completely different idea of what an IE means.

Section 3.9 specifies the semantics of the IEs introduced in Section
3.4. Section 3.4 defines a new IE, informationElementRangeBegin and
additionally very strict semantics. In particular, it declares use of
the IE as invalid if no Range End is given. Section 3.9, on the other
hand, allows one or the other to be omitted. I'm generally much more in
favour of at least allowing via MAY as many IEs as possible to be
omitted from an Options Data Record without breaking the protocol. The
restriction of invalidating sets when fields are missing seems a bit harsh.

Section 3.10 restricts what data types can be used with what semantics.
Apart from the list being very hard to parse (why not make it a table?),
this also seems like it might be too harsh a restriction. If I really
want to treat an octet array as a series of flags (or an IP Address as
an identifier) -- why keep me from doing it?

Section 7.1 lists "I-D.ietf-psamp-info" as a normative reference. Is
this on purpose?

Cheers,

  Christoph

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 09:49:45 +0200

Gerhard,

Ah, I see now. Agreed and fixed, thanks.

Regards,

Brian

On Jun 19, 2008, at 3:23 PM, Gerhard Muenz wrote:

>>>>    Information Element.  Information Element type records SHOULD  From [email-masked]  Fri Jun 20 00:49:54 2008
Date: Fri, 20 Jun 2008 09:49:45 +0200

Gerhard,

Ah, I see now. Agreed and fixed, thanks.

Regards,

Brian

  
>>>> NOT be

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 12:02:29 +0200

Christoph,

Thanks for the review! Comments inline.

Regards,

Brian

> Template itself", although the term only just appeared there for the

Hm, a minor point, perhaps, but yes... Edited.

> something along the lines of "opaque"?

Possibly, although that's not quite accurate, given that what "none"  
really means is "the default for this data type", hence I'd suggest  
"default". (Does anyone else have an opinion on this point?)

> documents seem to favour "Enterprise Identifier" or "Enterprise ID"  

The information element could be used to specify a Private Enterprise  
Number in any context (though this is not particularly clear from the  
Description; I've fixed this.); hence  
informationElementPrivateEnterpriseNumber is too specific, in  
addition to being overly verbose.

The proper terminology as taken from the IANA registry, is "Private  
Enterprise Number".

> sender might have a completely different idea of what an IE means.

Hmm. This is a good point. It seems the correct thing to do here is  
to mandate not that conflicting semantics must be ignored, but that  
information elements for which conflicting semantics are received  
must be ignored... fixed for -02.

> restriction of invalidating sets when fields are missing seems a  

er... I'm not sure I understand the issue here. Range Begin and Range  
End are a pair. Either both are present, or neither are present, or  
one is present and it is treated as invalid (meaning, an IE described  
by a type record containing only a Range End would be treated as if  
it had no range information at all). How does this invalidate the set?

> an identifier) -- why keep me from doing it?

This is a descriptive list, not a proscriptive list. It doesn't  
really keep you from doing anything that the properties of the data  
types and semantics don't already. The data types for which "none" is  
the only acceptable semantics value have their own semantics as part  
of the data type (hence "default" may be a better name; see above).  
As for your examples: An octet array with flags semantics is an  
integer; as per 5102 section 3.2 you need to be able to do bitwise  
math on an IE in order for it to have flags semantics. An IP address  
has its own semantics (and its own operations, such as masking,  
implied by these).

I agree that a table might clarify this. We'll see what we can come  
up with; for now I've edited them into a list, which at least makes  
it scan a bit more easily.

> Section 7.1 lists "I-D.ietf-psamp-info" as a normative reference. Is

The IE type options template requires the informationElementId IE,  
which is defined in psamp-info, and as such is not yet available in  
the IANA registry.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 12:02:29 +0200

Christoph,

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 12:22:52 +0200

Gerhard,

Ah, I see. The point of the paragraph in the introduction in question  
is not to restrict the usefulness of this (generic) type export  
mechanism to enterprise-specific IEs only, but to discourage the use  
of this mechanism as a substitute for the IANA registration process.  
(indeed, see point (b) in the following paragraph). However, the  
intro paragraph was worded poorly: we'll fix it. Thanks!

Cheers,

Brian

On Jun 19, 2008, at 3:15 PM, Gerhard Muenz wrote:

>
> Hi Brian,
>
> Brian Trammell wrote:
>> On Jun 18, From [email-masked]  Fri Jun 20 03:22:56 2008
From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 12:22:52 +0200
To: Gerhard Muenz <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

Gerhard,

Ah, I see. The point of the paragraph in the introduction in question  
is not to restrict the usefulness of this (generic) type export  
mechanism to enterprise-specific IEs only, but to discourage the use  
of this mechanism as a substitute for the IANA registration process.  
(indeed, see point (b) in the following paragraph). However, the  
intro paragraph was worded poorly: we'll fix it. Thanks!

Cheers,

Brian

On Jun 19, 2008, at 3:15 PM, Gerhard Muenz wrote:

>> context of
>> (Information

2008, at 10:18 AM, Gerhard Muenz wrote:
>> context of
>> (Information

---

From: Paul Aitken <[email-masked]>
Date: Fri, 20 Jun 2008 11:26:58 +0100

Brian,

> section 8.2.3. of the PSAMP Info document (which is now in  

You could explicitly state this by defining the high bit as a "don't 
care" field, eg

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |X|         IE 14               |0x01 unsigned8 |0x05 flags     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Fri, 20 Jun 2008 11:26:58 +0100

Brian,

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 12:30:27 +0200

Paul,

Ah. An excellent idea; will do...

Thanks,

Brian

On Jun 20, 2008, at 12:26 PM, Paul Aitken wrote:

>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+From [email-masked]  Fri Jun 20 03:30:35 2008
From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 12:30:27 +0200
To: Paul Aitken <[email-masked]>
Cc: IETF IPFIX Working Group <[email-masked]>
Subject: Re: [IPFIX] [Sender: [email-masked]] Re: WG Last Call for
	'Exporting Types' draft
Sender: [email-masked]

Paul,

Ah. An excellent idea; will do...

Thanks,

Brian

On Jun 20, 2008, at 12:26 PM, Paul Aitken wrote:

>>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> Hm. The intention here is that the informationElementId be the  
>> _base_  information element ID, without the enterprise bit; in  
>> other words,  ((the IE number from the template) & ~0x8000).  
>> However, reading  section 8.2.3. of the PSAMP Info document (which  
>> is now in  Publication Requested state), such is not stated,  
>> because the  definition was written, I think, without considering  
>> enteprise- specific IEs.
>> informationElementID is ignored. This would seem to be be the  
>> most  "be liberal in what you accept" way to address this...
>
> You could explicitly state this by defining the high bit as a  
> "don't care" field, eg
>

-+-+-+
>> Hm. The intention here is that the informationElementId be the  
>> _base_  information element ID, without the enterprise bit; in  
>> other words,  ((the IE number from the template) & ~0x8000).  
>> However, reading  section 8.2.3. of the PSAMP Info document (which  
>> is now in  Publication Requested state), such is not stated,  
>> because the  definition was written, I think, without considering  
>> enteprise- specific IEs.
>> informationElementID is ignored. This would seem to be be the  
>> most  "be liberal in what you accept" way to address this...
>
> You could explicitly state this by defining the high bit as a  
> "don't care" field, eg
>

---

From: Paul Aitken <[email-masked]>
Date: Fri, 20 Jun 2008 11:40:22 +0100

Brian,

>> semantics" (semantics: "none"). Wouldn't it be better to name this
>> value something along the lines of "opaque"?
> 

"default" is good. "none" might suggest something... less.

>> Section 3.9 specifies the semantics of the IEs introduced in
>> Section 3.4. Section 3.4 defines a new IE,
>> informationElementRangeBegin and additionally very strict
>> semantics. In particular, it declares use of the IE as invalid if
>> no Range End is given. Section 3.9, on the other hand, allows one
>> or the other to be omitted. I'm generally much more in favour of at
>> least allowing via MAY as many IEs as possible to be omitted from
>> an Options Data Record without breaking the protocol. The 
> it had no range information at all).

Why should that be? A range end without a start could be assumed to
start from the lowest possible value for the type, or from 0.

Similarly, a range start without an end could be assumed to end at the
highest possible value for the type, or 0xFF...FF.

Consider: in real life we often only give one end of a range, leaving
the other end implied: "starting tomorrow..." or "until Saturday".

>> Section 3.10 restricts what data types can be used with what
>> semantics. Apart from the list being very hard to parse (why not
>> make it a table?), this also seems like it might be too harsh a
>> restriction. If I really want to treat an octet array as a series
>> of flags (or an IP Address as an identifier) -- why keep me from
>> doing it?
> 
> integer;

Sounds like a bitfield to me.

> as per 5102 section 3.2 you need to be able to do bitwise math on an
> IE in order for it to have flags semantics.

Not so: you might check the top bit of the IE number to see whether it's
enterprise specific, though nobody would describe an IE as having flags
semantics!

> which is defined in psamp-info, and as such is not yet available in

I hope Nevil and IANA will have this cleared up before the next meeting?

stinfo/ipfix>,
	<mailto:[email-masked]?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: [email-masked]
Errors-To: [email-masked]

Brian,

>> semantics" (semantics: "none"). Wouldn't it be better to name this
>> value something along the lines of "opaque"?
> 

"default" is good. "none" might suggest something... less.

>> Section 3.9 specifies the semantics of the IEs introduced in
>> Section 3.4. Section 3.4 defines a new IE,
>> informationElementRangeBegin and additionally very strict
>> semantics. In particular, it declares use of the IE as invalid if
>> no Range End is given. Section 3.9, on the other hand, allows one
>> or the other to be omitted. I'm generally much more in favour of at
>> least allowing via MAY as many IEs as possible to be omitted from
>> an Options Data Record without breaking the protocol. The 
> it had no range information at all).

Why should that be? A range end without a start could be assumed to
start from the lowest possible value for the type, or from 0.

Similarly, a range start without an end could be assumed to end at the
highest possible value for the type, or 0xFF...FF.

Consider: in real life we often only give one end of a range, leaving
the other end implied: "starting tomorrow..." or "until Saturday".

>> Section 3.10 restricts what data types can be used with what
>> semantics. Apart from the list being very hard to parse (why not
>> make it a table?), this also seems like it might be too harsh a
>> restriction. If I really want to treat an octet array as a series
>> of flags (or an IP Address as an identifier) -- why keep me from
>> doing it?
> 
> integer;

Sounds like a bitfield to me.

> as per 5102 section 3.2 you need to be able to do bitwise math on an
> IE in order for it to have flags semantics.

Not so: you might check the top bit of the IE number to see whether it's
enterprise specific, though nobody would describe an IE as having flags
semantics!

> which is defined in psamp-info, and as such is not yet available in

I hope Nevil and IANA will have this cleared up before the next meeting?

---

From: Christoph Sommer <[email-masked]>
Date: Fri, 20 Jun 2008 13:54:18 +0200

Brian,

Brian Trammell wrote:
> Christoph Sommer wrote:
> 
>> In particular, [Section 3.4] declares use of
>> hand, allows one or the other to be omitted.
> 
> [...] an IE described by a type record containing only a Range End would be treated as if it had no
> range information at all

Ah, okay. I misunderstood "invalid" as meaning "MUST NOT be done in
protocol-conformant implementations".

If you need this restriction, I'd suggest moving it to Section 3.9. No
need to restrict the semantics of any implementation besides 'Exporting
Types' that uses this IE, but I fully agree with From [email-masked]  Fri Jun 20 04:54:23 2008
Date: Fri, 20 Jun 2008 13:54:18 +0200
From: Christoph Sommer <[email-masked]>
To: Brian Trammell <[email-masked]>
Cc: IETF IPFIX Working Group <[email-masked]>
Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

Brian,

Brian Trammell wrote:
> Christoph Sommer wrote:
> 
>> In particular, [Section 3.4] declares use of
>> hand, allows one or the other to be omitted.
> 
> [...] an IE described by a type record containing only a Range End would be treated as if it had no
> range information at all

Ah, okay. I misunderstood "invalid" as meaning "MUST NOT be done in
protocol-conformant implementations".

If you need this restriction, I'd suggest moving it to Section 3.9. No
need to restrict the semantics of any implementation besides 'Exporting
Types' that uses this IE, but I fully agree with PaPaul that it's probably
better to just allow it.

> This is a descriptive list, not a proscriptive list. It doesn't really
> keep you from doing anything that the properties of the data types and
> semantics don't already.

I fully agree that it's nice to hint at sensible combinations of both,
but currently it sure reads like a proscriptive list, stating
"Information Element type records containing invalid combinations [...]
MUST NOT be sent by Exporting Processes".

> An IP address has its own semantics (and its own operations, such as masking, implied by these).

I've probably not understood the meaning of the "semantics" field. I
thought it allowed a sender to communicate something like "In Field #42
I'm storing an IP Address, which I use as an identifier", so it struck
me as odd that Section 3.10 reads as if this is not allowed.

Regards,

  Christoph

ul that it's probably
better to just allow it.

> This is a descriptive list, not a proscriptive list. It doesn't really
> keep you from doing anything that the properties of the data types and
> semantics don't already.

I fully agree that it's nice to hint at sensible combinations of both,
but currently it sure reads like a proscriptive list, stating
"Information Element type records containing invalid combinations [...]
MUST NOT be sent by Exporting Processes".

> An IP address has its own semantics (and its own operations, such as masking, implied by these).

I've probably not understood the meaning of the "semantics" field. I
thought it allowed a sender to communicate something like "In Field #42
I'm storing an IP Address, which I use as an identifier", so it struck
me as odd that Section 3.10 reads as if this is not allowed.

Regards,

  Christoph

---

From: Christoph Sommer <[email-masked]>
Date: Fri, 20 Jun 2008 14:13:35 +0200

Brian,

> An IP address has its own semantics (and its own operations, such as masking, implied by these).

I was trying to imagine what the possible values of a "semantics" IE
would allow a collector (in particular an aggregator) to do with data it
received. I came up with this list:

none: No additional benefit

quantity: Can freely add, substract, calculate median etc.

deltaCounter: Same as quantity, but has to be aware of wraparound to 0

totalCounter: Same as deltaCounter, but might need to look at history

identifier: No additional benefit

flags: Can freely apply boolean operations

So, at least as far as aggregation is concerned, what a collector can
learn from the field is:

"none" and "identifier" don't help much. Is there a difference?

"quantity", "deltaCounter" and "totalCounter" tell the receiver to add
up (and how to add up) the values received.

"flags" tell the receiver that it can do bitwise operations on the
received fields.

It's sad that there's no value of the "semantics" field that tells a
receiver which operations the collector performed to derive a field's
value during flow creation (and, thus, which might be appropriate during
aggregation). This would be helped by additional values like these:

"start-of-interval" (take/took the *minimum* of all received values)
"end-of-interval" (take/took the *maximum*)
"and-bitfield" (take/took bitwise *and*)
"or-bitfield" (take/took bitwise *or*)

What do you think?

  Christoph

---

From: Christoph Sommer <[email-masked]>
Date: Fri, 20 Jun 2008 14:13:35 +0200

Brian,

What do you think?

  Christoph

---

From: Paul Aitken <[email-masked]>
Date: Fri, 20 Jun 2008 13:25:51 +0100

Christoph,

> "none" and "identifier" don't help much. Is there a difference?

"none" implies the IE is opaque, ie the collector has no idea what it 
is, what it means or how to deal with it. I can't think of a good use 
for this.

Whereas "identifier" implies a number which is related to something else 
on the exporting system (ie, the identified thing). Identifiers can be 
compared (at least with another identifier of the same type) and can 
probably be displayed as integers.

> "or-bitfield" (take/took bitwise *or*)

I slightly agree, though it's not clear to me how this information would 
make a difference to flow treatment on the collector.

bject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipfix>,

Christoph,

> "none" and "identifier" don't help much. Is there a difference?

"none" implies the IE is opaque, ie the collector has no idea what it 
is, what it means or how to deal with it. I can't think of a good use 
for this.

Whereas "identifier" implies a number which is related to something else 
on the exporting system (ie, the identified thing). Identifiers can be 
compared (at least with another identifier of the same type) and can 
probably be displayed as integers.

> "or-bitfield" (take/took bitwise *or*)

I slightly agree, though it's not clear to me how this information would 
make a difference to flow treatment on the collector.

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 15:15:24 +0200

Paul, Christoph, all,

One point inline below.

On Jun 20, 2008, at 2:25 PM, Paul Aitken wrote:

>> "and-bitfFrom [email-masked]  Fri Jun 20 06:15:30 2008
Date: Fri, 20 Jun 2008 15:15:24 +0200

Paul, Christoph, all,

One point inline below.

On Jun 20, 2008, at 2:25 PM, Paul Aitken wrote:

> I slightly agree, though it's not clear to me how this information  
> would make a difference to flow treatment on the collector.

It's also out of scope for this draft. The semantics we describe here  
come from 5102 section 3.2, nothing more, nothing less.

- Brian

ield" (take/took bitwise *and*)
> I slightly agree, though it's not clear to me how this information  
> would make a difference to flow treatment on the collector.

It's also out of scope for this draft. The semantics we describe here  
come from 5102 section 3.2, nothing more, nothing less.

- Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 15:25:28 +0200

> "default" is good. "none" might suggest something... less.

I've managed to convince myself of this too. Default it is. (None  
still makes sense as the nothing-to-see-here value for  
informationElementUnits, though...)

> the other end implied: "starting tomorrow..." or "until Saturday".

The time example I think is a but spurious, because the only sensible  
interpretation of (say) "until Saturday" in an IE range limitation is  
"from 0 UTC, 1 January 1970... until Saturday," but yes, the point is  
well made. I've removed these restrictions from the IE sections, and  
for each field in the options templates: "This element SHOULD be  
omitted if the (beginning|end) of the Information Element's  
acceptable range is defined by its data type."

> Sounds like a bitfield to me.

Well, yes. But we decided at some point not to have a completely  
variable-width bitfield type. 5102 section 3.2.5 clearly states flags  
must be integral (which makes sense, because computers generally do  
bitwise ops on integral types...)

> enterprise specific, though nobody would describe an IE as having  

Ah, okay, right. But an IE number is still integral (unsigned16)...

> I hope Nevil and IANA will have this cleared up before the next  

psamp-info is still in the rfc editor queue, waiting for the protocol  
and sampling techniques edits, I think...

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 15:25:28 +0200

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 15:25:30 +0200

On Jun 20, 2008, at 1:54 PM, Christoph Sommer wrote:

> protocol-conformant implementatioFrom [email-masked]  Fri Jun 20 06:34:06 2008
From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 15:25:30 +0200
To: Christoph Sommer <[email-masked]>
Cc: IETF IPFIX Working Group <[email-masked]>
Subject: Re: [IPFIX] WG Last Call for 'Exporting Types' draft
Sender: [email-masked]

On Jun 20, 2008, at 1:54 PM, Christoph Sommer wrote:

> Types' that uses this IE, but I fully agree with Paul that it's  
> probably
> better to just allow it.

See other message.

>>> semantics.
>> really

...because they do not make any sense, not because we are arbitrarily  
restricting them.

> me as odd that Section 3.10 reads as if this is not allowed.

Have a look at section 3.2 of RFC 5102, where the various semantics  
are defined in detail.

Regards,

Brian

ns".
> Types' that uses this IE, but I fully agree with Paul that it's  
> probably
> better to just allow it.

See other message.

>>> semantics.
>> really

...because they do not make any sense, not because we are arbitrarily  
restricting them.

> me as odd that Section 3.10 reads as if this is not allowed.

Have a look at section 3.2 of RFC 5102, where the various semantics  
are defined in detail.

Regards,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Fri, 20 Jun 2008 14:53:12 +0100

Brian

> and sampling techniques edits, I think...

Even so, the IEs can and should be added to the IANA registry immediately.

Is there any reason to stall their addition pending official publication 
of the RFC?

---

From: Paul Aitken <[email-masked]>
Date: Fri, 20 Jun 2008 14:53:12 +0100

Brian

---

From: Brian Trammell <[email-masked]>
Date: Fri, 20 Jun 2008 16:18:16 +0200

Paul,

Hmm. Come to think of it, no. This would also remove the normative  
reference to -info.

- Brian

On Jun 20, 2008, at 3:53 PM, Paul Aitken wrote:

>> psamp-info is still in the rfc editor queue, waiting for the  
>From [email-masked]  Fri Jun 20 07:18:26 2008
Date: Fri, 20 Jun 2008 16:18:16 +0200

Paul,

Hmm. Come to think of it, no. This would also remove the normative  
reference to -info.

- Brian

On Jun 20, 2008, at 3:53 PM, Paul Aitken wrote:

>> psamp-info is still in the rfc editor queue, waiting for the  > protocol and sampling techniques edits, I think...
>
> Is there any reason to stall their addition pending official  
> publication of the RFC?
>
> -- 
> Paul Aitken

>> protocol and sampling techniques edits, I think...
>
> Is there any reason to stall their addition pending official  
> publication of the RFC?
>
> -- 
> Paul Aitken