> Anybody can explain shortly the reason of the change
RECOMMENDED ->
> recommended?
Yes, I changed it because the 'idnits' tool complained
about it.
In fact, RFC 2119 says:
.... Authors who follow these
guidelines
should incorporate this phrase near the beginning of
their document:
The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL",
"SHALL
NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY",
and
"OPTIONAL" in this document are to be
interpreted as described in
RFC 2119.
So, since http://ops.ietf
.org/mib-security.html contains no mention
of RFC 2119, and no mention of including the above paragraph
in the MIB
document, I presumed that its use of
"RECOMMENDED" is not in the sense of
RFC 2119. Therefore, I changed the document to be
idnits-compliant by
making the simplest, least disruptive change, which is most
consistent
with all previous RFCs that I have generated containing
recommendations
for use and deployment of SNMPv3, including the two RFCs
which this WG
had published last week.
Keith.
>
> Thanks,
>
> Dan
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen lucent.com]
> > Sent: Thursday, April 06, 2006 12:42 AM
> > To: Keith McCloghrie; Romascanu, Dan (Dan)
> > Cc: sgaicisco.com; cdscisco.com; imssietf.org;
> > skodecisco.com; Black_Davidemc.com
> > Subject: RE: [imss] RE: AD review of:
> > draft-ietf-imss-fc-rtm-mib-03.txt
> >
> > 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:bwijnenlucent.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
|