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

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

> > > 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.
> 
> The problem of READ-WRITE or READ-CREATE seems to be that the MIB object
> cannot exist before a connection has been established.  But then it
> already has a flow label (or none) associated to it.  It seems too late to
> change it on the fly.
> 
> So, being able to change flow labels of existing flows seems like 
> something you must be very, very careful about in any case.
> 
> Hope this clarifies my concern.
>  
Somewhat... but why don't you take a look at RFC3289 and RFC3318 and
tell me if you see anything wrong. (not that they may be speaking
of FlowID instead of FlowLabel... but they mean the same thing).

I think that both RFCs are OK. Bot allow for writable/creatable objects
and I think in the way they use it it is OK.
I can see that there mightbe other uses that are not OK, but that of
course needs to be evaluated on a case by case basis, which the
MIB developers and later MIB doctors all do (or so I assume).

> > > 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.
> 
> Yep, I certainly support this -- there is no need to tie the 
> progress to
> the flow label spec (and there is nothing used here which is not in
> RFC2460 so normative is not needed AFACS).. but if you're 
> interested in
> how flow labels are to be used, it makes sense to read the flow label
> draft, and informative reference seems justified.
>  
I am willing to add it. I've taken it offline to you an the person
who suggested that referencing just 2460 was OK.
We'll see what comes out of that.

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