The following summary was sent to the ISMS list. It has received no comment.
In related news, Eliot is working with several people to explore the
call home option within the O&M community.
--- Begin Message ---
Hi. We had a very productive review of the ISMS charter on the ietf
list. Here's my response and action plan going forward on that issue.
Based on comments on the list here, comments to the ietf list,
numerous phone calls/jabber sessions and in-person discussions I
believe everyone will be able to move forward with this proposal. If
there are problems let me know and we'll see what we can do.
Included in this message:
* Review of IETF Discussion
* IESG Decision and AD Comments
* evaluating Extensibility of ISMS Output
Review of IETf Discussion
There was significant interest in considering firewall and NAT
traversal for SNMP and for broader management applications. Several
people pointed out why this is more involved than just specifying
extensions to the ISMS ssh draft. Several people said they believed
that the actual extensions to the ISMS drafts are simple.
There was rough consensus that it would be a bad idea to produce ISMS
specifications that did not even enable firewall/nat traversal and
then later decide that this traversal was an important extension to
the SNMP architecture.
However there was also a rough consensus that ISMS need not block on
the decisions about whether to implement traversal or about the
specific architectural issues. A few people did raise the concern
that having two standards come out requiring products to be updated
first for ISMS and then later for traversal would be
undesirable. However the rough consensus was that these efforts need
not block each other.
I make no consensus call on whether there is a consensus in the SNMP
community to extend SNMP to support firewall and NAT traversal.
That's a call I'm not qualified to make and one that needs to be made
by the O&M ADs. In addition that decision needs to happen within the
O&M area.
I didn't see a specific charter text proposal change. There was
something reasonably close I believe from David Nelson proposing that
we add something about considering call home in the design of ISMS to
the charter. While there was support for this consideration expressed
both on the ietf list and the isms list, there was not a rough
consensus that charter changes are required.
Summary of IESG Decision and AD Comments
The IESG has approved the ISMS charter with no modifications. The
announcement will come out as soon as I find a chair to replace Ken.
Chairs and participants should move forward under the new charter.
For example it would be reasonable for the chairs to approve documents
that meet charter deliverables.
However it is important that we consider the firewall and nat
traversal issues in our design of the ISMS architecture. In
particular we should consider firewall and nat traversal as a possible
extension to ISMS. It is desirable that we be able to accommodate such
an extension with the protocols we design.
Similarly we should follow the discussion of this extension in the O&M
area. If the O&M area decides to extend SNMP in this direction and
completes the appropriate architectural work, then we will need to
support firewall and nat traversal in our protocol.
That said, there are two things we must not do. First, we cannot
standardize firewall and nat traversal in the ISMS protocol without a
normative reference to a specification for how it works in SNMP. It's
not a good idea for devices to be saying "manage me," without an SNMP
architecture that provides for configuration of this functionality and
for well defined semantics. In other words, we can enable traversal
as an extension, we can have an extension ready to plug into the
document and we can plug in that extension if the SNMP community gives
us the architectural framework to reference. we cannot plug in the
extension before that happens and we will not wait if we're done and
the SNMP community is still working on the issue. Also, if the SNMP
community decides that they are not interested in firewall/nat
traversal we will spend much less time on it.
The other thing we must not do is allow firewall and nat traversal to
block our progress. If we get to a situation where we have a rough
consensus if we ignore firewall and nat traversal, but we are unable
to efficiently form a consensus while considering firewall and nat
traversal, then we move on ignoring firewall and nat traversal for
that issue. Things do change if the SNMP community formally decides
to implement firewall and nat traversal for us. If that happens, then
parts of firewall and nat traversal may be blocking issues for us. In
addition, some of the people arguing for solving the traversal problem
believe that working on the architectural extensions within ISMS might
be reasonable. This would require a charter revision, but I would not
object to such a charter revision if the right people were following
ISMS and if it had sufficient O&M support. I also would not object to
doing the work elsewhere.
Evaluating Extensibility of ISMS
Extensibility of protocols is an important evaluation criteria. When
looking at the ISMS output, I will look at how easy it would be to add
likely extensions to the protocol. Is there sufficient capability
negotiation? Can we add fields, messages or functionality? Are there
clear policies for how extensions are managed? I will be surprised if
ISMS output meets extensibility goals and could not be extended to
support firewall and nat traversal. I would certainly require an
explanation from the working group of why this was the case.
Sam Hartman
Area Director
_______________________________________________
Isms mailing list
Isms(_at_)lists(_dot_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/isms
--- End Message ---
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf