Keith/Dan,
I am basically happy with revision 3.
I am surprised to see that RECOMMENDED was changed to
lowercase
in the security considerations section.
If I were still AD I would require that to be changed back
to
upper case as per the template at:
http://www.
ops.ietf.org/mib-security.html
That template text was agreed to by MIB doctors and Security
Area
geeks a few years back, and it was not easy to agree on the
text.
Doc is ready for IETF LC, above comment can be addressed as
rfc-editor note or be considered IETF LC comments.
Bert
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen lucent.com]
> Sent: Wednesday, March 08, 2006 21:17
> To: Keith McCloghrie
> Cc: sgaicisco.com; cdscisco.com; imssietf.org;
dromascaavaya.com;
> skodecisco.com; Black_Davidemc.com
> Subject: [imss] RE: AD review of:
draft-ietf-imss-fc-rtm-mib-02.txt
>
>
> Inline
>
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:kzmcisco.com]
> > Sent: Wednesday, March 08, 2006 16:21
> > To: bwijnenlucent.com
> > Cc: Black_Davidemc.com; cdscisco.com; skodecisco.com;
> > kzmcisco.com;
> > sgaicisco.com; imssietf.org; dromascaavaya.com
> > Subject: Re: AD review of:
draft-ietf-imss-fc-rtm-mib-02.txt
> >
> >
> > Bert,
> >
> > Thanks for the review.
> >
> Welcome
>
> > > This document is ready for IETF Last Call.
> > >
> > > One topic that I would prefer to see
addressed:
> > >
> > > - When I see:
> > > t11FcRouteDestAddrId OBJECT-TYPE
> > > SYNTAX FcAddressIdOrZero
> > > MAX-ACCESS not-accessible
> > > STATUS current
> > > DESCRIPTION
> > > "The destination Fibre
Channel Address Identifier of
> > > this route. A zero-length string
for this field is
> > > not allowed."
> > > ::= { t11FcRouteEntry 1 }
> > >
> > > I then wonder why the syntax is not:
> > >
> > > SYNTAX FcAddressIdOrZero (SIZE(3))
> > >
> > > So that the restriction that zero-length is
not allowed is
> > > also machine readable.
> >
> > While I agree in principle, I think it also has
one other effect:
> > it changes t11FcRouteDestAddrId from being a
variable-length string
> > into a fixed-length string, which only matters
because
> > t11FcRouteDestAddrId is present in the INDEX
clause, and thus,
> > I fear that some implementations might get the
INDEX-ing wrong (re:
> > difference between bullets 2 and 3 at top of RFC
2578's page 28).
> > Thus, if you really want to see the restriction
reflected in the
> > SYNTAX clause, I would prefer to do so as:
> >
> > SYNTAX OCTET STRING (SIZE (3))
> >
> > so that it uses a regular construct, and
implementors will
> immediately
> > know what to do. Do you agree ?
> >
>
> Thanks Keith, I had overlooked that aspect of variable
length
> for indexing.
> Using OCTET STRING as you suggest does fix my initial
> comment, but then
> takes away that this is a FCAddressId.
> So I am not sure which choice I prefer. Does WG have
any comments?
> Are there any implementers on the list who want to
comment?
>
> So I have no firm opinion on which choice I like best
anymore.
>
>
> > > Could be addressesd after IETF Last Call,
even with an
> > RFC-Editor note.
> > >
> > > Mainly have some NITs below.
> > > You may consider them as initial IETF Last
Call comments.
> > > Let me know if you rather do a new rev first
or if you
> > > prefer to do IETF LC now. I will probably let
IETF LC extend
> > > beyond the IETF week, because people are
probably busy reviewing
> > > documents for the IETF week itself.
> >
> > I'd prefer to fix them now, but I'll wait for
your response to this
> > message before doing so.
> >
> > > - t11FcRouteRowStatus has a pretty meager
DESCRIPTION clause
> > > For example, from the DESCRIPTION clause of
t11FcRouteIfDown
> > > it seems that maybe a 'destroy' to the
RowStatus object
> > > may not take immediate effect? You might
want to describe that.
> > > It is also unclear if any writeable objects
can be written
> > > when a row is active?
> >
> > The last sentence of RowStatus's DESCRIPTION in
RFC 2579 says that
> > a 'destroy' requires the row to be removed
immediately. There was
> > discussion in T11.5 of the relationship between
this table and the
> > routing mechanisms that a FC switch uses, and we
agreed that such a
> > relationship is proprietary, and that the MIB
needs to stay at
> > arms-length from being too specific about this
> relationship. Thus, I
> > would prefer not to add text talking about it.
> >
> > There is one thing I can add, which is implicit in
t11FcRouteTable's
> > DESCRIPTION, but it would probably be useful to
add a more explicit
> > statement in t11FcRouteRowStatus's DESCRIPTION:
> >
> > The only rows which can be deleted by
setting this
> object to
> > 'destroy' are those for which
t11FcRouteProto has the value
> > 'netmgmt'.
> >
> > Then, it won't be so meagre  .
> >
>
> Good.
>
> > > - The 4 OBJECT clauses that you did as
comments in the
> > > MODULE-COMPLIANCE are normally put as
comments inside the
> > > DESCRIPTION clause of the MODULE-COMPLIANCE
clause itself.
> > > That way the text is better kept when MIB
module gets
> > > extracted from RFC. Not a blocking comment
though.
> >
> > OK, I'll move them. (The downside is that the
double-quotes have to
> > change, e.g., to single-quotes).
> >
> yep, but thanks for moving them. I think it makes IETF
MIB docs more
> consistent. And I just happen to like consistency in
this space.
>
>
> > > - Section 7 seems redundant with the back
matter, and might as
> > > well be removed.
> >
> > I'll let the RFC Editor do that.
> >
>
> Mmm... why is that?
> If you do a new rev anyway, why not just make it right
BEFORE it
> goes to RFC-Editor?
>
> > > - In the references section, are the details
for [FC-SW-4] now
> > > known? If so, might want to fill them out.
> >
> > Yes, we filled them in recently on one of the
other FC MIBs.
> > Thanks for reminding me of that.
> >
>
> Thanks,
> Bert
> > Keith.
> >
>
> _______________________________________________
> imss mailing list
> imssietf.org
> https://w
ww1.ietf.org/mailman/listinfo/imss
>
_______________________________________________
imss mailing list
imssietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss
|