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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 25 Jan 2014 20:24:23 -0000

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:[email-masked]] 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
> [email-masked] mailing lists by 2014-02-18. Exceptionally, comments may be
> sent to [email-masked] 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.

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 27 Jan 2014 09:20:04 +0000

> public domain, but I don't understand the meaning of IETF consensus with respect

+1

The Independent RFC Stream would seem more appropriate.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Mon, 27 Jan 2014 14:10:45 +0000

Yeah, we've been inconsistent. And I'm not saying we should block the document from being published on the IETF stream. But maybe the IESG wants to put a note on it or something.

Lars

On 2014-1-27, at 14:55, Thomas Narten <[email-masked]> wrote:

> At Mon, 27 Jan 2014 09:20:04 +0000,
> Eggert, Lars wrote:
>> 
>> [1  <text/plain; us-ascii (quoted-printable)>]
> Well, if you run a document through the RFC Stream publication
> process, it doesn't get the same level/type of review as does running
> it through the IETF. At least in theory.
> 
> So if one wanted to get IETF folk to review it, running it through
> IETF consensus (or something) doesn't seem unreasonable.
> 
> I don't know that we actually have an exact category for these kinds
> of documents. Indeed, the categories we have are rather course, and
> one can identify plenty of past documents that one might argue could
> have/should have been published in a different stream than it
> was. E.g., looking backwards for "cisco" documents published as RFCs:
> 
>> A new Request for Comments is now available in online RFC libraries.
>>        RFC 6812
>> 
>>        Title:      Cisco Service-Level Assurance Protocol 
>>        Status:     Informational
>>        Stream:     Independent
>>        Date:       January 2013
>>        I-D Tag:    draft-cisco-sla-protocol-04.txt
> 
> It was published in the RFC editor stream.
> 
> On the other hand:
> 
>>        RFC 6759
>>        Title:      Cisco Systems Export of Application 
>>                    Information in IP Flow Information Export 
>>                    (IPFIX) 
>>        Status:     Informational
>>        Stream:     IETF
>>        Date:       November 2012
>>        I-D Tag:    draft-claise-export-application-info-in-ipfix-10.txt
> 
> It was published via the IETF stream.
> 
> Thomas
>

---

From: Thomas Narten <[email-masked]>
Date: Mon, 27 Jan 2014 08:55:47 -0500

Thomas

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Jan 2014 01:14:46 +0100

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)

> .

---

From: Pete Resnick <[email-masked]>
Date: Mon, 27 Jan 2014 18:56:05 -0600

> it through the IETF. At least in theory.

If it were running through a WG and the WG wanted to publish it, I'd be 
much more likely to believe that it was getting a better level/type of 
review than running it through the ISE. But just getting a Last Call as 
an AD-sponsored document? I have my doubts.

And though Lars is right that we've been darn inconsistent about it, 
2026 does say that we're not supposed to be doing that:

http://tools.ietf.org/html/rfc2026#section-4.2.3

The ISE can always send a message to the IETF list saying, "I'd like the 
IETF to have a look at this document and send comments." I think it is 
almost identically as effective as sending out an IETF Last Call for an 
AD-sponsored Informational document.

I can imagine times where an AD-sponsored Informational document is 
useful, but I'm guessing there are far less than the number of times we 
do it.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jan 2014 01:18:00 +0000

Pete,

> http://tools.ietf.org/html/rfc2026#section-4.2.3

Which also says:

  "In order to differentiate these Internet-Drafts
   they will be labeled or grouped in the I-D directory so they are
   easily recognizable."

Pretty modern eh;-) And hightly likely to be meaningful
to readers.

More relevant though, the same section implies correctly
that it'd be a bad plan to let people easily "circumvent
the Internet Standards Process" and I would argue that
doing an IETF LC is a fine way for that be tested. About
as good as the ISE asking the IESG probably on balance
though the trade offs differ.

I suspect we'll be better off just not getting bothered
until such time as someone takes on the always-gargantuan
task of updating this bit of 2026.

> useful, but I'm guessing there are far less than the number of times we

I'm not at all clear why its useful to be bothered about
that. Can you explain how we all win?

I've no idea what's in draft-yourtchenko, but I do not
have any general problem with something that could be sent
to the ISE being handled in this way. And nor should any
of us I reckon, unless we prefer pointless process over
getting-stuff-done, in the absence of a particular issue
with the draft.

S.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 27 Jan 2014 19:30:45 -0600

> that. Can you explain how we all win?

Somehow I feel responsible to actually review AD-sponsored documents, 
both for content as well as for IETF consensus. It wastes my time as an 
AD. I suppose I could get over that and simply review them for end-runs.

I suppose there's also the bigger question of why other ADs are wasting 
their time sponsoring, reviewing, and doing all of the process nonsense 
associated with publishing a draft that not even a WG is interested 
enough to do all of that with. I guess that's mostly that AD's problem, 
but it's time wasted that could be better spent. (As you are fond of 
saying, ADs will always fill there time, no matter what they really have 
to do. I say let them fill it with other things.)

And then of course is the "stake in the heart" of any semblance of our 
document categories meaning anything. ("Sometimes, Informational means 
there is IETF consensus that this is a good piece of information; 
sometimes not.") But I suppose that spilled milk is under the dam or 
over the bridge and we might as well lie in it.

> ...I do not
> getting-stuff-done...

That's exactly my point. Seems pointless to waste time on the process 
for this document when we could dump it over the wall and let the ISE 
deal with it. Unless there's some reason it's important for the IETF to 
waste time on it.

pr

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jan 2014 01:43:14 +0000

> over the bridge and we might as well lie in it.

The semblance of that semblance has long left the building
I reckon.

> deal with it. Unless there's some reason it's important for the IETF to

Ah sorry, the waste-of-time I meant was caring about the
process here, i.e. what you're doing:-)

I do agree ADs ought use their judgement as to what to
sponsor. But that's enough of a rule for my taste.

S.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Jan 2014 18:18:13 -0800

On 1/27/2014 5:30 PM, Pete Resnick wrote:
> enough to do all of that with.

1. Not all documents require the work of a working group.  If there is 
believed to be no actual work to do on a document, then keeping it out 
of a wg isn't about lack of interest but lack of... work to do.

2. All that reviewing is called quality assurance.  I always thought 
that our open review processes had more to do with quality than with a 
status label.

Has the model changed and the standards label is all that matters these 
days?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: joel jaeggli <[email-masked]>
Date: Mon, 27 Jan 2014 22:50:21 -0800

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

I'd actually like the communities input that there is not something
catastrophically wrong to sending the document on it's merry way that
I've missed.

>> public domain, but I don't understand the meaning of IETF consensus

It seems highly likely that others have both implemented parsing of
these IEs and may well do so in the future for IEs which are not
depreciated. The fact that these are vendor specific doesn't preclude
there being interoperability concerns given that they are by their
nature exported. Much of Netflow and IPFIX has at one time been vendor
specific.

I don't think there much point is asking a working group to hold the pen
on this given that existing usage of existing values isn't likely to change.

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jan 2014 02:40:45 -0500

--On Tuesday, 28 January, 2014 01:43 +0000 Stephen Farrell
<[email-masked]> wrote:

>> And then of course is the "stake in the heart" of any
>> semblance of our document categories meaning anything.
>> ("Sometimes, Informational means there is IETF consensus that
>> this is a good piece of information; sometimes not.") But I
>> suppose that spilled milk is under the dam or over the bridge
>> and we might as well lie in it.
> 

Hmm. The community went to a lot of effort not long ago,
partially IIR at the urging of the then-IESG and IAB, to
identify RFCs by stream and to allow the streams to include
specific statements about review and consensus in the Status
section.  I wouldn't try to refute a claim that few people pay
attention to those labels and that text, but it is there and it
is supposed to be functional.  

Again IIR, we did not get rid of AD-sponsored at the time for
two reasons: 

(1) Many people felt that there were a few reasons for using
that process.  Most of them involved documents that had been
considered in and abandoned by a WG (including when a WG had
been closed with some documents still in progress).  If an AD
felt that they should continue to be processed in the IETF where
the context existed, that seemed to be more sensible than
starting over with the ISE and less context.  That principle
seems to me to apply whether the document is Standards Track,
inherently Informational, or published as a record of an
alternative that was considered and not chosen.  Others involved
suggestions for minor process patches or equivalent, where
AD-sponsorship of a document developed in the community seems
like a better option than the more recent pattern of
AD-initiated, AD-written (even with co-authors), and
AD-sponsored that, given professional courtesy within the IESG,
appears to be a recipe for abuse (even if actual abuses were
rare).

(2) The IESG didn't like the idea of giving up one of its
prerogatives.  Since they had to approve the relevant document
and changes, pushing to take it away from them seemed futile.

>> That's exactly my point. Seems pointless to waste time on the
>> process for this document when we could dump it over the wall
>> and let the ISE deal with it. Unless there's some reason it's
>> important for the IETF to waste time on it.

> sponsor. But that's enough of a rule for my taste.

I agree in the sense that I don't think that trying to write
fine distinctions into rules would help in this case.  And, to
repeat an argument from another thread that seems far more
applicable here, ADs who are inclined to abuse the system will
always find a way.

On the other hand, members of the community who believe that
particular ADs are not exercising good judgment in this area,
e.g., prioritizing their time and the community's on
AD-sponsored documents over getting the IETF's critical path
work done, should communicate their concerns to the Nomcom
which, I hope, is able to listen to new issues up to the day
that they deliver their reports about selections.   There is a
long history that, once a topic like this turns up and is
discussed, ADs who are reappointed consider their reappointment
as evidence of community approval for whatever they have been
doing, so comments to the Nomcom (this year and next) are now a
lot more important than they were a week ago.

Just IMO, of course.
    john

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Jan 2014 10:46:41 +0100

Let me reply to myself: I forgot an important point, which might be 
useful if people start discussing AD sponsoring of this document, 
without actually having read it.

Let me stress the first sentence of the Introduction section.

    The section 4 of [RFC7012] defines the IPFIX Information Elements in
    the range of 1-127 to be compatible with the NetFlow version 9
    fields, as specified in the "Cisco Systems NetFlow Services Export
    Version 9" [RFC3954].

So this draft is clearly linked to the work in IPFIX RFC 7012 (IPFIX 
information model) and must follow the RFC 7013 rules (Guidelines for 
Authors and Reviewers of IPFIX Information Elements), therefore would 
benefit from more reviews.

It's probably not too clear from the abstract, and should be improved.

OLD:

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

NEW:
    This document describes some additional IPFIX Information Elements in
    the range of 1-127, which is the range compatible with field types used
    by NetFlow version 9 inRFC3954  <http://tools.ietf.org/html/rfc3954>, as specified in the IPFIX Information Model
    RFC 7012.
  
Regards, Benoit (an as author)

> times in the IPFIX WG, and also why it would benefit from a wider 
> review than the independent stream.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Jan 2014 11:17:10 -0000

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).

Joel points out that it is valuable to check that the publication of this
document doesn't break anything else. I think that is a fine answer to my
question and would ask that, in future, when the scope or intent of a last call
is limited, that limit be explicitly called out in the last call so that no-one
waste review effort. I also think that when the RFC is published it should not
use boilerplate that says the document is a product of the IETF if the IETF did
not have the opportunity to edit the technical content. It would be better to
say that the IETF had consensus to publish the document but that it is not a
product of the IETF.

Cheers,
Adrian

> From: Benoit Claise [mailto:[email-masked]]
> Sent: 28 January 2014 00:15
> To: [email-masked]; [email-masked]
> Subject: Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 28 Jan 2014 06:58:11 -0600

Adrian,

Nicely said.

If we can give reviewers a clue about what we hope they are looking for,
we're more likely to get the results we hope for.

And being accurate about the review we asked for in the final document seems
helpful.

Spencer

On Tuesday, January 28, 2014, Adrian Farrel <[email-masked]> wrote:

> > From: Benoit Claise [mailto:[email-masked] <javascript:;>]
> > To: [email-masked] <javascript:;>; [email-masked] <javascript:;>
> > > public domain, but I don't understand the meaning of IETF consensus
> with
> > respect
> > > to this document.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >> From: IETF-Announce [mailto:[email-masked]<javascript:;>]
> On Behalf Of
> > The
> > >> IESG
> > >> [email-masked] <javascript:;> mailing lists by 2014-02-18.
> Exceptionally, comments may be
> > >> sent to [email-masked] <javascript:;> instead. In either case, please
> retain the

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Jan 2014 09:10:57 -0500

--On Tuesday, 28 January, 2014 06:58 -0600 Spencer Dawkins at
IETF <[email-masked]> wrote:

>...
> If we can give reviewers a clue about what we hope they are
> looking for, we're more likely to get the results we hope for.

Of course, one of the long-time characteristics of the
Independent Submission system is the ability to get
tightly-focused reviews from people with relevant experience.

Is there any chance that, rather than continuing this discussion
on the IETF list to the point of general exhaustion, the IESG
and ISE (and maybe some RSAG members) could sit down in London
and produce some general guidelines about how to allocate such
categories as...

(1) Corporate or similar specs, proposed to be documented in the
RFC Series for the information of the community.

(2) Documents considered in a WG that fail to get traction or
that are overtaken by events but that don't get strong
opposition within the WG.

(3) Documents considered by a WG that don't get approval, either
because the WG finds series defects or because it selected a
different path or set of alternatives.

(4) Documents clearly appropriate for IETF work but for which no
existing WG is available and appropriate and for which there is
little enough controversy that setting up a WG is not worth the
trouble.

(5) Documents that are not relevant to the Internet going
forward but for which publication appears to have significant
historical value.

(6) Documents that may be important or useful for the network
but that do not directly relate to the sorts of work the IETF is
doing (or has the institutional competence to do).

(7) Documents that affect IETF process but for which there is no
consensus for forming a WG or processing in other ways.

(8) Documents whose purpose is to create an IANA registration
under "specification required" provisions of some existing
protocol.

There is probably a longer list, and some of those categories
overlap.   I'd be opposed to firm rules because, as we usually
discover about such things, there are always edge cases and
judgment calls.  But, if agreement could be reached on some
general guidelines and maybe even presented in a plenary to
inform the community and get comments, it would probably be a
big help to all concerned.

   john

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 28 Jan 2014 11:00:43 -0600

> and produce some general guidelines about how to allocate such

This is a very helpful suggestion.

Spencer

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Jan 2014 21:00:51 -0000

Thanks Benoit, that is an important point and is really helpful.
 
So, do I read you right if I say that this document records some NetFlow v9
features and codepoints that were accidentally missed when RFC 3954 was written.
 
Or are these later modifications to NetFlow v9 (let's call it v9.x) that use the
same code point range but were not actually part of v9?
 
The question might arise as to whether this document is supposed to update 3954.
 
Thanks,
Adrian
 
From: Benoit Claise [mailto:[email-masked]] 
Sent: 28 January 2014 09:47
To: [email-masked]; [email-masked]; Andrew Yourtchenko
Subject: Re: Last Call: <draft-yourtchenko-cisco-ies-09.txt> (Cisco Specific
Information Elements reused in IPFIX) to Informational RFC
 
Let me reply to myself: I forgot an important point, which might be useful if
people start discussing AD sponsoring of this document, without actually having
read it.

Let me stress the first sentence of the Introduction section.
   The section 4 of [RFC7012] defines the IPFIX Information Elements in
   the range of 1-127 to be compatible with the NetFlow version 9
   fields, as specified in the "Cisco Systems NetFlow Services Export
   Version 9" [RFC3954]. 
So this draft is clearly linked to the work in IPFIX RFC 7012 (IPFIX information
model) and must follow the RFC 7013 rules (Guidelines for Authors and Reviewers
of IPFIX Information Elements), therefore would benefit from more reviews.

OLD:
 
NEW:
   This document describes some additional IPFIX Information Elements in 
   the range of 1-127, which is the range compatible with field types used 
   by NetFlow version 9 in RFC3954 <http://tools.ietf.org/html/rfc3954> , as
specified in the IPFIX Information Model
   RFC 7012.

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. 

Hi, 

to this document. 

Thanks, 
Adrian 

-----Original Message----- 

Abstract 

. 

.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 28 Jan 2014 22:42:46 +0100

hi Adrian, all,

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

> record of what Cisco did (continue to publish it, but don't ask for review of

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.

> 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).

> 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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 31 Jan 2014 12:53:39 +0100

> record of what Cisco did (continue to publish it, but don't ask for review of
If I would have to chose between, this is closer to the later.
I meant closer, because there is an important clarification here: the 
review of BCP 184 "Guidelines for Authors and Reviewers of IP Flow 
Information Export (IPFIX) Information Elements" must be done. And the 
best way to have reviews from more people, not only the IPFIX IE 
doctors, was to present the work to the IPFIX WG (this was done several 
times).
So you should see this document as a clean up of the range 1-127, which 
was allocated to NetFlow v9 at the time, while the IPFIX information 
elements were standardized. That lead to some IPFIX information elements 
being deprecated in that range, because there were better standardized 
solutions:
- samplingInterval, samplingAlgorithm, classNamestandardized in PSAMP
- layer2packetSectionOffset, layer2packetSectionSize, 
layer2packetSectionData standardized in 
draft-ietf-ipfix-data-link-layer-monitoring-08 
<https://datatracker.ietf.org/doc/draft-ietf-ipfix-data-link-layer-monitoring/> 
(recently in RFC editor queue)

What would have been really wrong is to try to publish the draft years 
ago, via the ISE, and pushing proprietary information elements.

Regarding one of your question in the different email: The question 
might arise as to whether this document is supposed to update 3954.

Not sure that question makes sense.
NetFlow is a confusing term as it covers at the same time the Metering 
Process, the Exporting Process, and Information Elements (In IPFIX, 
there are clear distinctions between those terms). This draft doesn't 
update RFC 3954: there is no NetFlow 9.x. This draft updates the 
information model (read the IPFIX information elements) used by IPFIX 
and NetFlow v9 export protocol.

Regards, Benoit

---

From: Andrew Feren <[email-masked]>
Date: Fri, 31 Jan 2014 13:14:33 -0500

Hi all,

I don't currently have an opinion on the proper process, but I do have a
few last call comments.

"5.3.  IEs assigned for NetFlow v9 compatibility

   ElementId: 105..126

   These element IDs are not covered by this draft and left "as is",
   i.e. for Netflow v9 compatibility."

should be

"5.3.  IEs assigned for NetFlow v9 compatibility

   ElementId: 105..127

   These element IDs are not covered by this draft and left "as is",
   i.e. for NetFlow v9 compatibility."

[change summary : 126 -> 127  and Netflow -> NetFlow ]

Despite the fact that Appendix B change 07 says its semantics were
changed to 'identifier' based on my comments semantics for
ipv4RouterSc(43) should be 'default'.  To be fair I don't think I
originally specified what the semantics should be just that they
shouldn't be ipv4address.

Finally one nit that I'm somewhat ambivalent about.  I'd not abbreviate
"Shortcut" to "Sc" in ipv4RouterSc.

With the above changes the document looks good to me.

-Andrew