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

[James Carlson <[e-mail]>]

William Allen Simpson wrote:
> Seems better to me!  Although, I'd thought my draft would be normative,
> 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
> appropriate RFCs in the security section, too.  But those can be added by
> the RFC Editor.

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.)

-- 
James Carlson         42.703N 71.076W         <[e-mail]>