[RAI] RE: RAI guidelines for e2e

["Henry Sinnreich" <[e-mail]>]

Mary and Jon,

Your attached comments show indeed the reflection in the RAI guidelines
of the architectural principles of the Internet and included there is
also e2e.

Some small but critical improvements are however suggested.

1. Updated list of IAB documents

Add to "The review may also consider the applicability of the following
generally agreed IETF criteria as appropriate:" the more recent RFC 4924
"Reflections on Internet Transparency"
ftp://ftp.rfc-editor.org/in-notes/rfc4924.txt 

2. Accurate labeling for "truth in advertising" and relevant RFCs

>But I don't think that specifications that talk about ways in which our
>endpoints could -also- work in non-transparent environments should be
>bounced by RAI reviewers on those grounds.

Fully agree, I-D reflecting non-transparent environment should not be
bounced but should be encouraged to support accurate labeling, such as
is recommended for example in RFC 4084 "Terminology for Describing
Internet Connectivity"
ftp://ftp.rfc-editor.org/in-notes/rfc4084.txt 

Besides accurate labeling, RAI documents should also discuss the
compliance with relevant RFCs. An excellent role model is the ICE I-D
where IAB considerations are discussed in detail in section 22;
including on how RFC 3424 on UNSAF is met.

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-mmusic-ice-
18.txt 

ENUM documents would be made more interesting by discussing the existing
and proposed new Internet and web naming and addressing schemas what the
benefit to RAI area applications may be (compare DNS usage, HIP, NUTSS,
p2p namespaces). Or just leave ENUM to IP-TDM gateway services (where I
think it belongs)? 

Why insisting on e2e?

The success of the Internet and many Internet businesses, including
endpoint application developers depend on it, as well as the whole
Internet economy. Accurate labeling and referral to relevant IAB and
other RFCs will improve the RAI review guidelines.

The discussions on this list have shown mixed opinions, so the
clarifications suggested here seem to be required indeed.

My two cents,

Henry

-----Original Message-----
From: Mary Barnes [mailto:[e-mail]] 
Sent: Friday, October 05, 2007 5:40 PM
To: Henry Sinnreich; Dan Wing; Eric Rescorla; Hadriel Kaplan
Cc: [e-mail]
Subject: RE: [RAI] RAI guidelines for e2e

Henry,

The RAI review guidelines:
http://www.softarmor.com/rai/art/review-guidelines.html
do currently recommend reviewing for applicability some of the more
general Internet Architecture documents, such as 
http://www.ietf.org/rfc/rfc3439.txt
which does have a section on 2.1. entitled "The End-to-End Argument and
Simplicity".  

We can certainly add RFC4924 to the list of general recommendations to
consider when doing reviews.  It was not on the list for other review
teams since it's a new RFC.   However, I don't think one can suggest
that the guidelines have totally left out the concept because that
document is missing. 

I can't speak for SPEERMINT or ENUM, but your concern about SIPPING
seems to be targetted at ftp://ftp.rfc-editor.org/in-notes/rfc3427.txt
which does allow for this whole process of P-headers, which are
typically applicable to the walled garden situations you mention.  The
documents defining P-headers are not SIPPING WG documents nor are they
endorsed by the WG.  They are only ever published as Informational and
they are progressed as individual AD sponsored documents. We do require
an "expert" review of those documents to ensure that they don't violate
the guidelines set out in RFC 3427, which did follow the normal IETF
review process and went through IETF Last call in July of 2002.  So, you
are correct, in that there is some IETF effort to support these
activities, but the alternative of the other SDOs defining new SIP
headers without any guidance from IETF at all was not deemed desireable
at the time.   I don't think we have any SIPPING WG documents that are
explicitly for walled gardens. We do have documents that allow for
involvement of some elements in the network (beyond Proxies, which IMHO
can be viewed in the purest sense to break the e2e principle), but I
don't recall anyone raising concerns about those breaking the end-to-end
principle in the past - they are enablers for endpoints that don't
support some of the more complex functionality and they are required to
follow fundamental SIP protocol rules.  

So, can you please be more explicit about what work with RAI has
progressed or is underway (other than P-headers) that violates the e2e
guidelines?   Or, are you suggesting we should Obsolete RFC 3427 and let
the other SDOs define whatever they want in terms of SIP headers?  

Thanks,
Mary. 

From: Peterson, Jon [[e-mail]]
Sent: Friday, October 05, 2007 5:23 PM
To: Henry Sinnreich; Dan Wing; Eric Rescorla; Hadriel Kaplan
Cc: [e-mail]
Subject: RE: [RAI] RAI guidelines for e2e


I think the RAI Area and its constituent groups have always been
committed to the e2e model and to Internet transparency. Like any other
part of the IETF, I think our groups also reflect a diverse marketplace
in which there are many divergent ideas about how applications and
services might be deployed. We have always tried to optimize for the
specification of implementations that would, under all circumstances, be
compatible with an open and unrestricted network, even if such
implementations are additionally capable of detecting and operating in
networks where less desirable conditions apply.

SPEERMINT exists because we believe it is possible to deploy the "edge"
features desired by service providers in a non-intrusive manner,
preserving the e2e properties of SIP. SPEERMINT attempts to demonstrate
this to the marketplace, in the hopes that this will make SIP more
robust, compatible, and secure in its use across the Internet. This does
not, in my opinion, facilitate the rise of walled garden networks -
instead it benefits both the users within walled gardens and those
outside who hope to communication with them. In order to demonstrate
this, SPEERMINT needs to explore and address requirements in a language
likely to persuade service providers. If it cannot do this, then the
work cannot complete its chartered goals.

While I do think it is necessary for RAI reviewers to be mindful of the
e2e model and Internet transparency, I think a review of a SPEERMINT
document along the lines of, "Well, this document talks about service
providers and SBCs and edges, so it should be rewritten to describe
voice as just an application running over an agnostic bit pipe" just
isn't salient, even if it happens to be true. 

Nor do I think it is the place of every SPEERMINT document to defend
SPEERMINT's charter in an "e2e considerations" section or what have you.
I completely agree that if our specifications produce endpoints that no
longer operate well on the public Internet, then we've lost sight of the
big picture. But I don't think that specifications that talk about ways
in which our endpoints could -also- work in non-transparent environments
should be bounced by RAI reviewers on those grounds. If anyone would
like to take a stab at guidelines that capture this, I'm sure it would
be useful going forward.

Jon Peterson
NeuStar, Inc.


_______________________________________________
RAI mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rai