Subject: [Pppext] I-D Action:draft-ietf-pppext-trill-protocol-03.txt

From: [email-masked]
Date: Wed, 30 Mar 2011 12:45:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF.

	Title           : PPP TRILL Protocol Control Protocol
	Author(s)       : J. Carlson
	Filename        : draft-ietf-pppext-trill-protocol-03.txt
	Pages           : 6
	Date            : 2011-03-30

The Point-to-Point Protocol (PPP) [1] defines a Link Control Protocol
(LCP) and a method for negotiating the use of multi-protocol traffic
over point-to-point links.  This document describes support for
Transparent Interconnection of Lots of Links (TRILL) Protocol,
allowing direct communication between Routing Bridges (RBridges) via
PPP links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pppext-trill-protocol-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: James Carlson <[email-masked]>
Date: Wed, 30 Mar 2011 16:18:01 -0400

> 	Filename        : draft-ietf-pppext-trill-protocol-03.txt

For reference, here are the substantive changes made in the document
since the -02 draft:

245,249c245,247
<       can form an IS-IS System ID.  Resolving that issue is an
<       implementation-dependent matter, but it is expected that, if at
<       all possible, some means of minimizing the need for
<       administrative configuration SHOULD be considered in order to
<       accomplish the RBridge goal of zero configuration.
---
>       can form an IS-IS System ID.  Resolving that issue is outside the
>       scope of this document, but see [8] for one mechanism that should
>       be considered in this situation.
> INTERNET-DRAFT  The PPP TRILL Protocol Control Protocol       March 2011
314a315,316
>    [8] W. Simpson, "Generation of Unique IS-IS System Identifiers,"
>        work in progress, March 2011
318,319c321,322
<    The author thanks Donald Eastlake, Linda Dunbar, and Radia Perlman
<    and for their comments and help.
---
>    The author thanks Linda Dunbar, Donald Eastlake, Radia Perlman and
>    William A. Simpson for their comments and help.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 31 Mar 2011 10:47:05 -0400

Seems better to me!  Although, I'd thought my draft would be normative,
rather than informative.  And there should probably be references to the
appropriate RFCs in the security section, too.  But those can be added by
the RFC Editor.

---

From: James Carlson <[email-masked]>
Date: Thu, 31 Mar 2011 11:37:59 -0400

William Allen Simpson wrote:
> rather than informative.

I don't believe it is, for the same reason that I don't believe that the
original issue raised was actually in scope of the draft I'd written.

The issue you've raised and that you're dealing with in your draft is an
overall system design issue, and particularly a _potential_ problem with
IS-IS -- depending entirely on the system environment.  It's not
something that someone working on a PPP link for TRILL needs to worry
about.  It's not related to negotiation or carriage of data; nothing
about a PPP TRILL link.  It *is* something that someone designing the
IS-IS part of the system should worry about, because he has to get that
System ID value.

So I believe that an informative reference is _more_ than sufficient.
Frankly, I would prefer to say nothing at all about the issue, because
it's really outside the scope of this draft to explain or otherwise
account for IS-IS implementation details.  Particularly ones that may
well change over time.

>  And there should probably be references to the

Adding a new NCP normally adds no additional security issues beyond the
usual "authenticate your links and/or encrypt traffic if the situation
warrants."  Is that what you're referring to?  If not, then please
provide more detailed references for what is "appropriate" here, and
I'll add them if they're reasonably in scope.

(In other words, there's no way I'm going to add any documentation about
IS-IS security issues.  That's *way* out of scope, and I'm simply
guaranteed to get it wrong.  If not now, then certainly over time.  But
references to RFC 1994 or 1968 or some such would be OK, though I think
it might be bordering on pedantic to force each new PPP RFC to direct
implementors to these documents.  Real implementors -- or at least
modestly competent ones -- know that they've got to look through more
than one RFC to do the job, depending on circumstances.)