Tom: but MPLS could be used anywhere. It isn't designed in a way that using it would be dangerous.
Fred: but there will always be environments that would benefit from special optimizations, such as cellular or satellite or high-performance computing. It's reasonable for us to standardize for the special needs of those environments too - they need interoperability and they use IP.
Scott
On Jan 30, 2014 9:17 AM, "t.p." <daedulus@xxxxxxxxxxxxx> wrote:
----- Original Message -----
From: "Spencer Dawkins" <spencerdawkins.ietf@xxxxxxxxx>
To: "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx>
Cc: "IETF discussion list" <ietf@xxxxxxxx>
Sent: Wednesday, January 29, 2014 3:45 PM
> I'm replying to Brian and to Scott here ...
>
> On 01/28/2014 05:11 PM, Brian E Carpenter wrote:
> > Hi Spencer,
> >
> > I think there's a bit more to be said, though.
> >
> > The goal is to make the Internet work better, not to make
> > private networks work better. Actually RFC 3935 defines
> > the IETF's scope as: "protocols and practices for which
> > secure and scalable implementations are expected to have
> > wide deployment and interoperation on the Internet, or to
> > form part of the infrastructure of the Internet."
> >
> > So if there are two ways of doing something, one of which
> > works globally and one of which only works locally, the choice
> > is a no-brainer. If a local-only solution comes up to the IESG,
>
> I couldn't agree with Brian and Scott more. I'm focusing on "comes up
to
> the IESG".
>
> My point is that the sooner someone asks "so, is this really intended
> for deployment on the global Internet?", the better. If working groups
> and authors thought about that before, or even during, WGLC time, I
> would like to think that we would have fewer cases where the question
is
> asked for the first time in AD review, or in directorate reviews, or
in
> IETF Last Call.
Spencer
By this criterion, would MPLS ever have entered the Standards Track?
It is a protocol that works supremely well within the private network of
an ISP; extending it to work across the Internet worldwide is more of a
challenge and, from what I recall, was not contemplated at the time of
RFC3031.
Tom Petch
>
> I don't think it's controversial at all that the IETF does better when
> documents don't encounter Late Surprises (tm). If the first time
someone
> says "but this is only intended to be used when $whatever" is in an
> email exchange during IETF Last Call, that's a Late Surprise, and the
> chances that the best outcome will happen aren't going up at that
point.
>
> As I said in my note, this is my personal suggestion. I'm not asking
for
> an Applicability Statement as a mandatory section in all IDs,
precisely
> because of Brian's point that the default is "this proposal is
suitable
> for deployment on the global Internet". I'm asking working groups and
> authors to consider whether that's true for their proposals, or if I
> should be reviewing with something else in mind.
>
> And as always, I encourage people to Do The Right Thing.
>
> Spencer
>
> > I think the first question is "Why isn't there a globally
> > applicable solution to this problem?". Then the second question
> > is "Why is this on the standards track, rather than being an
> > informational document for the record?". And the third question
> > is "Why is this better as an IETF document rather than an
> > Independent Submission?".
> >
> > There may be perfectly good answers to those questions, but
> > IMHO they need to be asked.
> >
> > Regards
> > Brian
> >
> > On 29/01/2014 09:14, Spencer Dawkins wrote:
> >> Disclaimer - I'm one of the ADs who will be balloting your
documents
> >> until at least March 2015, but I'm only one of 15 ADs, and haven't
> >> talked about this with the rest of the IESG.
> >>
> >> The past week has brought me yet another example of an idea that
could
> >> be a good idea, but not under every possible set of conditions,
being
> >> evaluated as if we had to decide whether it was a good idea in all
> >> cases, or a bad idea. This might sound familiar to you, but if it
does,
> >> let's not talk about that specific case.
> >>
> >> The longer (and more painfully) we talk during Last Call, the more
> >> details we unearth that help me to understand what document
> >> authors/working groups are thinking, and that's good, but if it was
less
> >> painful, that would be even better.
> >>
> >> http://tools.ietf.org/html/rfc2026#section-3.2 describes
Applicability
> >> Statements, as distinct from Technical Specifications, and says
(among
> >> other things):
> >>
> >> An Applicability Statement specifies how, and under what
> >> circumstances, one or more TSs may be applied to support a
particular
> >> Internet capability.
> >>
> >> ...
> >>
> >> An AS may describe particular methods of using a TS in a
restricted
> >> "domain of applicability", such as Internet routers, terminal
> >> servers, Internet systems that interface to Ethernets, or
datagram-
> >> based database servers.
> >>
> >>
> >> Speaking only for myself, I don't expect Proposed Standards to be
> >> perfect, and to work perfectly in every situation, but if a
> >> specification doesn't describe any limits on applicability, I'm
going to
> >> be evaluating it as if it will be used on the open Internet (that's
what
> >> the "I" in "IETF" stands for).
> >>
> >> If a draft says it's only intended to be used within an IP subnet,
I'd
> >> evaluate it differently. I might ask that the authors/working group
> >> consider what the TTL should be set to, so that what starts out
within
> >> an IP subnet stays within an IP subnet, but (to use one actual
example)
> >> we wouldn't be arguing about whether it's OK to send 32K max-length
> >> packets over an arbitrary Internet path at line rate without
getting any
> >> feedback about path capacity - there are probably paths where that
would
> >> work, and there are definitely paths where it would not.
> >>
> >> If a draft says it's only intended to be used on provisioned,
managed
> >> internetwork links subject to SLA monitoring, I'd evaluate it
differently.
> >>
> >> If a draft says "this is a hack, intended for use on old hardware
that
> >> can't do $X", I'd evaluate it differently.
> >>
> >> There are other limited-use scenarios that would make me evaluate a
> >> draft differently.
> >>
> >> None of this is a guaranteed pass, but it would help me a lot. It
would
> >> likely help other reviewers, too.
> >>
> >> So, if you don't intend for your draft to be used on the global
> >> Internet, please say so! As per
> >> http://tools.ietf.org/html/rfc2026#section-3.3, it's not necessary
to
> >> put an Applicability Statement in a different draft; just a section
that
> >> says (another actual example) "this has been tested using these
> >> parameters on a lightly-loaded LAN, and it works there", that is
more
> >> helpful than a tug of war(*) about whether something is a good idea
or a
> >> bad idea in all situations, in front of a live studio audience.
> >>
> >> Thanks to Alia Atlas for nudging me to think about this more.
> >>
> >> Spencer
> >>
> >> p.s. If you have feedback about what I'm thinking, I'd love for you
to
> >> share it, whether on this list, privately to me, to the 2015
Nomcom, or
> >> to other Nomcom-eligible IETF participants when you're asking them
to to
> >> sign the recall petition ;-)
> >>
> >> (*) http://en.wikipedia.org/wiki/Tug_of_war
> >>
>
>