Re: RE: AD request / L2 Triggers Charter Statement

James,
  My opinion on this is not to underestimate the
importance of informational RFCs.
  I checked at IETF's RFC pages and noticed that yes,
you are right most of the APIs defined so far are
informational RFCs (IPv6 API 2292, Service Location
API, etc.). 
  Curiously, the security APIs (RFC 2744 and 2853) are
of proposed standards. I could not see any difference
in the way these APIs are defined, i.e. 2292 and 2744.
  Also let me point out that RFC 3022 which defines
NAT/NAPT behaviour is also informational and this was
what I meant by the first sentence of this mail.
  So what is wrong with informational RFCs that are
needed and have great potential to be used?

Regards,
--- James Carlson <[email protected]>
wrote:
> Phil Neumiller writes:
> > Its ironic that the IETF is more than willing to
> specify what bits should be
> > in the payload of an L2 device and on a wire (that
> they can't directly touch)
> > but not be willing to communicate with an L2
> device (which they can directly
> > touch) in any standard way.
> 
> I think you're confusing two very different things
> here:
> 
> 	- the documents that are standardized via the IETF
> 
> 	- the work that folks do to make useful systems
> 
> The two are quite different.  Just because people
> have to do any
> number of special efforts in design or
> implementation of any part of
> TCP/IP does *not* make all of those efforts into
> IETF standards
> issues.
> 
> The problem is that system designs vary by much more
> than I (or
> probably anyone else on this list) can possibly
> comprehend.  The IETF
> is not a software interface standards group.  It's
> really not.  There
> are many such groups -- X/Open being one that has
> been cited here
> before.  Linus Torvalds perhaps being another.  ;-}
> 
> The point is that there's no such thing as One True
> System
> Architecture.  Perhaps, if one is stuck writing
> software for a
> particularly ubiquitous O/S, it might seem that way,
> but it's just not
> true.
> 
> Worse still, the IETF's structure is really not set
> up to handle such
> issues.  The IETF (and the IESG) have fair
> cross-sections of folks who
> build IP-speaking devices for a living, but the
> folks who do system
> interfaces for a living don't all participate here. 
> They're off in
> the appropriate standards bodies.
> 
> >  Over the years it seems that the IETF matured
> > to the point of almost completely specifying the
> IP to Ethernet binding.
> 
> No.  It specifies where the bits belong inside the
> Ethernet frames.
> That's all it can specify.  It doesn't specify
> whether the hardware
> interface is interrupt-driven or polled, whether the
> driver is single
> or multithreaded, whether the entrance to the IP
> stack is an upcall, a
> BSD soft interrupt, or a DLPIv2 STREAMS M_PROTO
> message.
> 
> It doesn't, and I'm arguing that it can't and must
> not.
> 
> >  If
> > we use the OO concept of inheritance, or design
> patterns, isn't logical that
> > one would seek commonalities between L2 to IP
> bindings and standardize
> > this?
> 
> Seeking the commonality, and documenting the
> necessary bits and the
> known good practices (or at least the possible
> alternatives) all seem
> like mostly good things.  Unfortunately, I see no
> hope at all of
> "standardizing" any such thing.
> 
> What external test do you apply to show that some
> vendor has followed
> a design practice?
> 
> >  It seems that just some maturing of the
> relationship between L2s and the
> > IP layer is needed here.  For some reason, I think
> this will eventually happen.
> > It may take a long while though...
> 
> On a given system architecture, this can be done. 
> The IETF doesn't
> just support one particular design philosophy, no
> matter how "good" it
> might seem right now.  Design strategies are passing
> fads that come
> and go; protocols are forever.
> 
> > Yet inter-operating with multiple L2s is somehow
> deemed NOT useful?
> 
> Correct.  That's not interoperability.  That's
> perhaps "system design"
> or "code reuse" or "making things easier for third
> party integration."
> It's not interoperability by any stretch of IETF
> terms.  There's only
> one party involved as far as the IETF is concerned;
> the system itself
> is a node on an IP network.  Saying that you ought
> to be internally
> interoperable with yourself is probably axiomatic.
> 
> > It is an area that huge amounts of proprietary
> code is written to do the
> > same thing over and over again, right?
> 
>
--behcet

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/