Re: [IPFIX] AD review: draft-trammell-ipfix-text-adt

Brian Trammell <[email protected]> Thu, 15 May 2014 11:42:05 +0200
Newsgroups	gmane.ietf.ipfix
Message-ID	<[email protected]>
hi Benoit,

On 14 May 2014, at 19:03, Benoit Claise <[email protected]> wrote:

> Hi Brian,
> 
> Thanks for the new version 5 of the draft.
> 
> One small editorial point.
> You correctly mention the references "XML [W3C-XML], JSON [RFC4627])" later in the text, but forgot the XML reference in the intro. See "JSON [RFC4627] or XML".

Oops, thanks for the catch.

> Please correct that in your temp version.

Already done.

> The draft is now sent to the IETF LC.

Thanks, cheers,

Brian


> Regards, Benoit
>> Brian,
>> 
>> Below is my AD review
>> -
>>   However, present and future operations and management protocols and
>>    applications may use textual encodings, and generic framing and
>>    structure as in JSON or XML. 
>> 
>> Please add references
>> 
>> -
>>  A definition of canonical textual
>>    encodings for the IPFIX abstract data types would allow this set of
>>    Information Elements to be used for such applications, and for these
>>    applications to interoperate with IPFIX applications at the
>>    Information Element definition level.
>> 
>>    Note that templating or other mechanisms for data description for
>>    such applications and protocols are application specific, and
>>    therefore out of scope for this document: only Information Element
>>    identification and data value representation are defined here.
>> 
>> "such applications" don't refer to IPFIX applications from the previous paragraph
>> 
>> - 
>> 
>> Note that templating or other mechanisms for data description for
>>    such applications and protocols are application specific, and
>>    therefore out of scope for this document: only Information Element
>>    identification and data value representation are defined here.
>> 
>> 
>> and 
>> 
>> 
>>  Enclosing Context
>>       Textual representation of IPFIX data values is applied to use the
>>       IPFIX Information Model within some existing textual format (e.g.
>>       XML, JSON).  This outer format is referred to as the Enclosing
>>       Context within this document.  Enclosing Contexts define escaping
>>       and quoting rules for represented data values.
>> 
>> what is "data value"? It should be Information Element value
>> 
>> -  Leading zeroes are allowed in any either encoding, and do not signify
>>    base-8 (octal) encoding.  Binary encoding is intended for use with
>>    Information Elements with flag semantics, but can be used in any
>>    case.
>> 
>> I guess you mean the "binary representation of unsigned"
>> 
>> 
>>  - Why should and not must?
>>    Instead, applications using textual representations of Information
>>    Elements should use Information Element names to identify them; see
>>    Appendix A for examples illustrating this principle.
>> 
>> - btw, I found the RFC 2119 keywords in http://tools.ietf.org/id/draft-trammell-ipfix-text-adt-03.txt more appropriate, so that implementations could be compliant with this future RFC.
>> However, I could live with that. Let's see what the other ADs will say.
>> 
>> - 
>> Otherwise, the values of Information Elements of signed integer types
>>    should be represented as optionally-prefixed base-10 (decimal)
>>    strings.
>> 
>> should be -> must? 
>> You are not consistent in the 4.X sections. For example, in 4.4: 
>>    Otherwise, the values of Information Elements of float32 or float64
>>    types are represented as an optionally sign-prefixed, optionally
>>    base-10 exponent-suffixed, floating point decimal number.
>> 
>> - 
>>    If the Enclosing Context defines a representation for binary objects,
>>    that representation should be used.
>> 
>> The should is weird. If it's a should, you should specify the exception(s).
>> Otherwise, it's a must. 
>> Anyway, you had to make it clear when someone is compliant with this spec.
>> Btw, why do you always need this sentence in 4.x?
>> 
>> 
>> - 
>> I don't think it's appropriate to have [iana-ipfix-assignments] as a normative reference.
>> In RFC7011 and RFC7012, it is informative
>> 
>> 
>> - If figure 2 is the IPFIX Message, it should follow the same format as the RFC 7011 appendix examples.
>> Then people will be able to compare. 
>>  
>> - change "Figure 2: IPFIX message containing sample flow" to "Figure 2: IPFIX Message containing sample Flow Records
>> change 
>>    "A Message containing this Template and a Data Record
>>    is shown in Figure 2"
>> to 
>>    "An IPFIX Message containing this Template and a Data Record
>>    is shown in Figure 2"
>> 
>> -
>> OLD:
>>    A Message containing this Template and a Data Record
>>    is shown in Figure 2, and a corresponding JSON Object using the text
>>    format defined in this document is shown in Figure 3.
>> 
>> NEW:
>> 
>>    An IPFIX Message containing this Template and a Data Record
>>    is shown in Figure 2, and a corresponding JSON Object using the text
>>    format defined in this document is shown in Figure 3.
>> 
>> 
>> Regards, Benoit
>> 
>> 
>> 
>> 
>> _______________________________________________
>> IPFIX mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/ipfix
> 
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
signature.asc (application/pgp-signature, 496 B)