Subject: [newtrk] where to state that something is required (Comment: PIm Sparse Mode to Proposed (fwd))

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2005 05:21:39 +0200

I think Sam's note to the IETF list today pretty clearly indicates the 
problem we have with saying "this is the mandatory to implement mechanism 
for this protocol in this context", given that neither the protocol or the 
mechanism should need to be revised in order to make that statement.

                  Harald

---------- Forwarded Message ----------
Date: 27. oktober 2005 11:19 -0400
From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Comment: PIm Sparse Mode to Proposed

[IETf, the following is a ballot comment on the PIM Sparse Mode
document which is before the IESG today.  This is not a discuss: I am
not holding the document until this issue is fixed.  I do not expect
the authors to address my comment, but I do ask the community to
consider the issue.]

This comment is not a discuss, but I am certainly not thrilled with
the current situation.  This document does not define a mandatory to
implement security mechanism.  It does tell network administrators how
to use IPsec to secure PIM.

That's not really enough for several reasons.  First, it does not
require the necessary features of IPsec be implemented along side PIM.
Second, it provides a reasonably bad user experience: the user has to
use a general mechanism that doesn't know about PIM not one that knows
about PIM.  So the user has to encode all the information about PIM
and its traffic flows for the general mechanism.  Unfortunately it is
probably not as simple as having vendors provide easy configuration
tools.  While a vendor could do that for their own products, the user
has enough flexibility in how they configure things that such a vendor
would not be guaranteed to work with other products or arbitrary
sites.

So I'm not going to block this document.  However we must do better in
the future.  The primary purpose of this comment is to say that I'm
not happy with this direction and that the fact that this document
passes IESG review may not be used as a justification that future work
should be allowed through.

I would certainly hold work started today to a higher standard.  This
document would also get a discuss because it has no mandatory
automated key management if it were new work.

We will have to work on what scale is appropriate for work already in
progress.

On a more positive note, I'd like to thank the authors for a really
well written document.  I wish all the specs I had to review were of
this quality.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---------- End Forwarded Message ----------

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 30 Oct 2005 21:13:22 -0800 (PST)

On Fri, 28 Oct 2005, Harald Tveit Alvestrand wrote:
> I think Sam's note to the IETF list today pretty clearly
> indicates the problem we have with saying "this is the mandatory
> to implement mechanism for this protocol in this context", given
> that neither the protocol or the mechanism should need to be
> revised in order to make that statement.

Seems to me that the stand-alone Applicability Statement is
tailor-made for exactly this purpose.

//cmh

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Larry Masinter <[email-masked]>
Date: Sun, 30 Oct 2005 23:51:08 -0800

> > revised in order to make that statement.

draft-ietf-newtrk-interop-reports-00.txt
section 2, 4th bullet: 

  o  A feature description should indicate whether implementation is
      REQUIRED or optional for the protocol.

So the protocol feature set could say, for each feature, whether
it is mandatory to implement.

5th bullet

   o  Protocols may define multiple roles (e.g., client/server/proxy).
      Protocol Feature Set can include sets of roles, and feature
      specifications can identify the roles for which the feature is
      appropriate.

I think the 'mandatory to implement' status should be per-role,
so that "in this context" would also be covered.

Larry
-- 
http://larry.masinter.net

.