Bert,
While you and I both agree with the boilerplate's
recommendations for
the implementation and use of SNMPv3, it is my belief that
at least one
of them is trying to impose the use of SNMPv3 on
implementors and/or
operators, and therefore, given that RFC 2119 says:
6. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo must be used
with care
and sparingly. In particular, they MUST only be used
where it is
actually required for interoperation or to limit behavior
which has
potential for causing harm (e.g., limiting
retransmisssions) For
example, they must not be used to try to impose a
particular method
on implementors where the method is not required for
interoperability.
I suggest that we must not use these imperatives in this
situation.
(Note that the above paragraph from 2119 actually contains
"must not"
in lower case, i.e., it is wrong to capitalise every
occurrence of
these imperatives.)
Keith.
> I think it is better to keep the CAPITALIZED language
and add
> (use) the reference to rfc2119.
>
> Bert
>
> > -----Original Message-----
> > From: Keith McCloghrie [mailto:kzm cisco.com]
> > Sent: Saturday, April 08, 2006 22:31
> > To: dromascaavaya.com
> > Cc: bwijnenlucent.com; kzmcisco.com; 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
> >
> >
> > > 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:bwijnenlucent.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
>
_______________________________________________
imss mailing list
imssietf.org
https://w
ww1.ietf.org/mailman/listinfo/imss
|