Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific Info

hi Adrian, all,

answering as an IPFIX geek and RFC 7013 IE-Doctors reviewer, inline…

On 28 Jan 2014, at 12:17, Adrian Farrel <adrian(_at_)olddog(_dot_)co(_dot_)uk> 
wrote:

Thanks Benoit,

And I am not much concerned with the process here as with the meaning of the
IETF last call.

Reading the document, I don't understand what would happen if I found 
something
that I thought should be different. It looks to me that this is a record of 
what
has been implemented and deployed. That is fine and good, but I don't see what
my review is supposed to give as input.

It seems to me that either this is an IETF document describing some IPFIX
widgets (drop all the Cisco stuff, get the WG to agree they want the feature,
and let the IETF do a proper review probably as Standards Track) or it is a
record of what Cisco did (continue to publish it, but don't ask for review of
the content).


My understanding is it’s the latter: for these, we basically have to presume 
that the _content_ of the Information Element descriptions correctly describes 
the behavior in NetFlow Version 9, and cannot change the descriptions to 
improve them for general use, because this is essentially the opening of an 
(older) internal spec. Indeed, note that 11 of the 18 of the Information 
Elements are being added to the registry as deprecated already, as they have 
been replaced by improved Information Elements within the context of further 
development of IPFIX.

Joel points out that it is valuable to check that the publication of this
document doesn't break anything else.


That's one utility of wider review here. Another is to ensure that there are no 
obvious errors: either inconsistencies in the descriptions (though none of the 
descriptions make reference to external sources that the community could check) 
or in the various fields of the registry (abstract data type and semantics; 
these will also be checked in the IE-Doctors review).

And on this question:

The question might arise as to whether this document is supposed to update 
3954.


In general, when documents only change the IPFIX Information Element registry, 
we consider that separate from changes to the protocol. Documents proposing new 
Information Elements don't update RFC 5102; Indeed, RFC 7012, which obsoletes 
5102, even removed all the Information Element definitions to make it very 
clear to implementors that the IANA registry was now the normative reference 
for them.

Of course, 3954 is a bit of an oddity in that it contains both protocol and 
information model, but at the same time, 3954 only exists in an IETF context as 
part of the candidate evaluation for IPFIX protocols. So since we don't really 
expect anyone to implement it (indeed, we'd much rather they implement IPFIX), 
I don't see how having this document referenced from 3954 would improve 
interoperability of flow measurement: the Information Elements will be added to 
the registry, which is where we want everyone to look.

Best regards,

Brian

-----Original Message-----
From: Benoit Claise [mailto:bclaise(_at_)cisco(_dot_)com]
Sent: 28 January 2014 00:15
To: adrian(_at_)olddog(_dot_)co(_dot_)uk; ietf(_at_)ietf(_dot_)org
Subject: Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific
Information Elements reused in IPFIX) to Informational RFC

Adrian,

Not an answer to the process question, but some background information
on this draft.
This draft, which is now 3 years old, has been evolving with the IPFIX
standardization.
For example, looking at
http://tools.ietf.org/rfcdiff?url2=draft-yourtchenko-cisco-ies-09.txt,
you can see the interaction with the IPFIX WG document
ietf-ipfix-data-link-layer-monitoring: now that
ietf-ipfix-data-link-layer-monitoring is in the RFC editor queue, the
draft has been simplified, and some IPFIX Information Elements in the
range 1-127 became deprecated.
This explains why the draft has been presented and reviewed multiple
times in the IPFIX WG, and also why it would benefit from a wider review
than the independent stream.

Regards, Benoit (as draft author)

Hi,

I have a process question on this last call which is not clear from the last
call text.

Are we being asked to consider whether publication of this document is

useful,

or are we being asked for IETF consensus on the *content* of the document?

It seems from the document that the content is descriptive of something
implemented by a single vendor. I applaud putting that information into the
public domain, but I don't understand the meaning of IETF consensus with

respect

to this document.

Thanks,
Adrian

-----Original Message-----
From: IETF-Announce [mailto:ietf-announce-bounces(_at_)ietf(_dot_)org] On 
Behalf Of

The

IESG
Sent: 21 January 2014 12:33
To: IETF-Announce
Subject: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific
Information Elements reused in IPFIX) to Informational RFC

The IESG has received a request from an individual submitter to consider
the following document:
- 'Cisco Specific Information Elements reused in IPFIX'
  <draft-yourtchenko-cisco-ies-09.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf(_at_)ietf(_dot_)org mailing lists by 2014-02-18. Exceptionally, 
comments may be
sent to iesg(_at_)ietf(_dot_)org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes some additional Information Elements of Cisco
   Systems, Inc. that are not listed in RFC3954.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-yourtchenko-cisco-ies/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-yourtchenko-cisco-ies/ballot/

No IPR declarations have been submitted directly on this I-D.

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific Information Elements reused in IPFIX) to Informational RFC