RE: Last Call: Textual Conventions for IPv6 Flow Label to Proposed Standard

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: zaterdag 5 april 2003 8:29
> To: iesg@ietf.org
> Subject: Re: Last Call: Textual Conventions for IPv6 Flow Label to
> Proposed Standard
> 
> 
> On Fri, 4 Apr 2003, The IESG wrote:
> > The IESG has received a request from the Operations & Management 
> > Open Area Working Group to consider Textual Conventions for IPv6 
> > Flow Label <draft-ietf-ops-ipv6-flowlabel-00.txt> as a Proposed 
> > Standard.  
> 
> Looks pretty good.
> 
Thanks

> As being uneducated wrt. deeper implications, I would like to see more
> explicit justification for FlowLabelOrAny.  I cannot imagine all that many
> uses that the extra '-1' for any value might bring, except for the

I/we are not claiming if there are MANY oir just a few who need the -1.

But the fact that Diffserv MIB (RFC3289) and Framework PIB (RFC3318) need
to be able to filter on either a specific FlowLabel or on ANY flowlabel,
that is why we came up with the FlowLabelOrAny spec, so that it will
be done in ONE CONSISTENT manner. There were several ways of doing things
already.

So that is the explanation/movivation/justification.

If you buy into that, can you suggest specific text to be added?
Maybe it is just a matter of axpanding the first sentence of the
introduction from:
   Several standards-track MIB modules have defined objects to represent
   an IPv6 Flow Label (sometimes refered to as Flow ID)
into
   Several standards-track MIB modules have defined objects to represent
   an IPv6 Flow Label (sometimes refered to as Flow ID) and IPv6 Flow Label
   filters
Would that address your concern?

> implementation laziness (just report -1 with everything for read access).  
> This might be different if you were aiming towards R/W 
> access.. which in turn might be a bad idea.
> 
They are indded max-access READ-WRITE or READ-CREATE.
I do not see the problem with that either. Pls explain.

> Another minor issue is that one might want to informationally 
> refer to draft-ietf-ipv6-flow-label-06.txt.
> 
I can do so if it makes sense. When the question was asked before
(I believe it was in private email), the answer we got was:

>> I think the MIB draft should have a normative reference to the 
>> flow label draft to avoid any surprises later.
>
>Why?  The field is actually defined in RFC 2460, and the MIB
>doesn't deal with any of the issues regarding the use of the
>flow label, as defined in the flow label draft.
>
>If possible, we'd like to avoid a dependence on the flow label
>draft, since the flow label TCs are needed immediately for
>MIB work in other areas.

As informational reference, it will allow to be referenced as
"work in progress", so that won't hold us up. So I can do so
if it makes a big diffrence. But since the claim is that the
field is actually defined in RFC2460 (to which there is a normative
reference), I think we're covered already.

> An editorial nit:
> 
>    unneeded compelxity.
> 
> ==> s/compel/comple/
> 
Thanks for catching, fixed in my source.

Bert
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>