Gen-art review of draft-ietf-sip-media-security-requirements-07

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-sip-media-security-requirements-07.txt
Reviewer: Elwyn Davies
Review Date:  10 October 2008
IETF LC End Date: 13 October 2008
IESG Telechat date: (if known) -

Summary:
This document is almost ready for the IESG.  I have a couple of comments
and queries about the reasoning in a few of the requirements.
Meta-comment:  To a non-SIPper the problems to be solved and the
requirements look very challenging!  And to think S in SIP might once
have meant...
Disclaimer: Whilst the requirements appear sensible and internally
consistent, I have no idea if the set is complete or really appropriate.
The explanations in s4 are very helpful and clear for a naive reader
like me. Likewise, I do not have the necessary knowledge to verify the
statements in the various appendices relating to existing proposals.
Again they look reasonable sensible.

Comments:
s5.1, Requirement R-RTP-VALID:  I think some explanation of  why '...the key
         negotiation packets MUST NOT pass the RTP validity check
         defined in Appendix A.1 of [RFC3550].' would help.  This looks

Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Dear Vijay;

On Oct 10, 2008, at 5:31 PM, Vijay K. Gurbani wrote:

> Marshall Eubanks wrote:
>> I support this moving forward. My reading of the room in Dublin was
>> that there was serious support for this and certainly a critical mass
>> to move forward.
>
> Marshall: Thank you for your review.  More inline.
>
>> Some comments in the charter below. This document clearly needs some
>> more work. As a overall comment, I think it is premature to discuss
>> ALTO "servers" and would keep the charter focused on describing the
>> ALTO "service."
>
> In an earlier reply to Vidya I note that the charter does indeed
> predominantly refer to "ALTO services" over "ALTO server".
> Having said that, if I did not convince you through that
> argument, then we can leave the "s/ALTO server/ALTO service"
> discussion on the table.
>
>> I do not see consensus at this moment as to a central
>> service solution versus a distributed solution.
>
> Agreed.

To me, this agreement answers the previous point. (Servers presupposes  
the answer, service does not IMO.)

Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

I agree with the sentiment that this work is too important to not move  
forward. While feelings at the BoF were mixed, the work done since the  
BoF has been substantial, particularly in the area of narrowing the  
charter's scope. The ALTO work as it has been put forth in the current  
charter has potential value not only for diverse applications (as the  
IPTV example below suggests), but also for a diversity of network  
operators facing difficult technical and policy trade-offs arising  
from ever-changing network usage. All sides will benefit from moving  
forward.

Alissa Cooper
Center for Democracy & Technology

On Oct 10, 2008, at 12:29 AM, Daniel Park wrote:

> I also agree to move it forward. One example: ALTO issue is quickly  
> coming up in the IPTV business. P2P for IPTV service already takes  
> place in some of standard bodies (e.g., DVB, EBU, etc...).  So, it's  
> a good timing not to missing over the important business changes...
>
> -- 
> Daniel Park [at] Samsung Electronics
> Standard Architect, blog.naver.com/natpt
>
>
>
> On Fri, Oct 10, 2008 at 10:36 AM, Richard Barnes <rbarnes <at> bbn.com>  
> wrote:
> On the contrary, I perceived pretty strong agreement at the BoF that  
> the ALTO problem, as expressed in the documents and presentations,  

Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Lakshminath Dondeti wrote:
> The minutes (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say
> this:
> 
> +++++++++++++++
> Many people agreed that this is important work for the IETF, also some
> (less) people hummed against.  Hum was inconclusive - some of the "no"
> hums were (in Jon's words) vehement.
> +++++++++++++++
> 
> Given that there was no consensus, it would have been nice if the
> sponsoring AD(s) or the IESG explained what's going on, but then
> transparency, it appears, is not really a goal in this case.  If the
> idea was to just go forward anyway, we really wasted 3, may be 6 months.
>   The half measures are a waste of everyone's time.

Lakshminath, the objections raised during the BoF in Dublin were on very
specific issues, namely the "general service discovery problem"
supposedly addressed by the charter, a too broad scope in terms of
information exchanged between ALTO clients and ALTO servers, and the
connection between traffic localization and optimization someone seemed
to see implied in the problem statement. During the weeks following the
meeting, people who had expressed concerns at the mic and on the list
constructively contributed to the discussion and the group converged on
a charter the current version is a slight variant of. For this reason,
and for the amount of interest shown in Dublin  -- we called
inconclusive the hum on the charter, but interest in the problem was
made pretty clear by what we heard at the mic, by the number of
contributors, and by the number of people in the room -- we managed to
convince our sponsoring AD (and transitively the IESG) to send it out
for IETF-wide review. If the community identifies new serious issues or
considers the old ones not completely addressed, probably a new BoF will
be the best way to sort them out.

Of course I'm only speaking for myself, not certainly on behalf of Lisa
nor the IESG.

--

-- 
Ciao,
Enrico

_______________________________________________
Ietf mailing list
Ietf <at> ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

Contrary to what some people seem to have interpreted my email to mean, I did actually say that the work is
needed.  I was noting the lack of consensus from the last BoF and I definitely feel a second BoF is more
appropriate at this time to iron out the disagreements.  However, I am still not trying to block the work - I
am saying that there are some critical things to alter in the charter proposal.

As Lakshminath notes, the notion of "service" vs. "server" is more than a terminology issue.  It is
important that we consider the possibility of ALTO being provided as a distributed service, potentially
in an overlay context.  I also see the charter being restrictive in terms of assuming a subset of
information types to be provided by the ALTO server.  We need to shoot for a much more generic and extensible
mechanism.  Another important missing piece is the ability for peers to publish information about
themselves - without that, the request/response protocol alone carries much less value.

Regards,
Vidya

> -----Original Message-----
> From: Lakshminath Dondeti [mailto:ldondeti <at> qualcomm.com]
> Sent: Thursday, October 09, 2008 10:17 PM
> To: Richard Barnes
> Cc: Narayanan, Vidya; p2pi <at> ietf.org; 'iesg <at> ietf.org'
> Subject: Re: [p2pi] WG Review: Application-Layer Traffic
> Optimization (alto)
>
> On 10/9/2008 6:36 PM, Richard Barnes wrote:
> > On the contrary, I perceived pretty strong agreement at the
> BoF that
> > the ALTO problem, as expressed in the documents and
> presentations, as
> > an important one to solve.  There was some disagreement about
> > solutions, but there seemed to be agreement about the general idea
> > that it would be useful to create an ALTO service that could help
> > peers optimize their peer selection.
>
> Richard,
>
> The minutes
> (http://www.ietf.org/proceedings/08jul/minutes/alto.txt) say
> this:
>
> +++++++++++++++
> Many people agreed that this is important work for the IETF, also some
> (less) people hummed against.  Hum was inconclusive - some of the "no"
> hums were (in Jon's words) vehement.
> +++++++++++++++
>
> Given that there was no consensus, it would have been nice if
> the sponsoring AD(s) or the IESG explained what's going on,
> but then transparency, it appears, is not really a goal in
> this case.  If the idea was to just go forward anyway, we
> really wasted 3, may be 6 months.
>   The half measures are a waste of everyone's time.
>
> >
> > The question of "service" versus "server" in the text is a complete
> > non-issue, purely a matter of wording.
>
> No it is not; please see below.
>
> > In all of the "ALTO service"
> > scenarios Vidya describes, there is ultimately a single host that
> > provides ALTO information, which you might as well call an
> "ALTO server".
> >
>
> A distributed service is not necessarily provided by a single host.
>
> > Since it addresses an important problem, and a problem that many
> > people agree is important, I support moving forward with this work.
>
> I for one think that there needs to be much more clarity on
> the goals and the terminology before just moving forward and
> producing useless RFCs.
>
> regards,
> Lakshminath
>
> >
> > --Richard
> >
> >
> >
> > Narayanan, Vidya wrote:
> >> I am surprised to see that ALTO is being proposed for a WG
> after the
> >> last BoF concluded with no consensus whatsoever.  I think a second
> >> BoF is more appropriate than a WG on the topic at this time.  That
> >> said, I do see the need for this work, although I have
> some comments
> >> on the current direction.
> >>
> >> Overall, I think we should work with the notion of an ALTO
> "service"
> >> rather than specifically an ALTO "server".  The ALTO
> service may be
> >> provided by a server, a cluster of distributed servers or as a
> >> service in an overlay.  Although some of the charter wording talks
> >> about a "service" rather than a "server", there is enough
> mention of
> >> a "server" entity to imply a strict client-server protocol.
> >>
> >> As part of that, I think there are a couple of key things
> that need
> >> to be addressed here:
> >>
> >> - A protocol that allows peers (or ALTO clients) to publish
> >> information about themselves as part of the ALTO service.
> An example
> >> of such information may be the uplink/downlink bandwidth
> of the peer.
> >>
> >> - The ability to register information types with IANA and extend
> >> these.  The request/response protocol should be a generic enough
> >> container for any information that peers can provide and look for,
> >> plus what may be available from service providers, etc.
> There may be
> >> some guidelines on how such information types can be
> registered and
> >> we may start with default ones.
> >>
> >> Some further comments/questions inline.
> >>
> >>> -----Original Message-----
> >>> From: ietf-announce-bounces <at> ietf.org
> >>> [mailto:ietf-announce-bounces <at> ietf.org] On Behalf Of IESG
> Secretary
> >>> Sent: Monday, October 06, 2008 1:36 PM
> >>> To: IETF Announcement list
> >>> Cc: p2pi <at> ietf.org
> >>> Subject: WG Review: Application-Layer Traffic Optimization (alto)
> >>>
> >>> A new IETF working group has been proposed in the
> Applications Area.
> >>> The IESG has not made any determination as yet.  The
> following draft
> >>> charter was submitted, and is provided for informational purposes
> >>> only.  Please send your comments to the IESG mailing list
> >>> (iesg <at> ietf.org) by Monday, October 13, 2008.
> >>>
> >>> Application-Layer Traffic Optimization (alto)
> >>> =============================================
> >>> Last Modified: 2008-09-29
> >>>
> >>> Current Status: Proposed Working Group
> >>>
> >>> Chair(s): TBD
> >>>
> >>> Applications Area Director(s):
> >>>
> >>> Lisa Dusseault (lisa at osafoundation.org) Chris Newman
> >>> (Chris.Newman at sun.com)
> >>>
> >>> Applications Area Advisor:
> >>>
> >>> Lisa Dusseault (lisa at osafoundation.org)
> >>>
> >>> Mailing List:
> >>>
> >>> General Discussion: p2pi at ietf.org To Subscribe:
> >>> https://www.ietf.org/mailman/listinfo/p2pi
> >>> Archive: http://www.ietf.org/pipermail/p2pi/
> >>>
> >>> Description of Working Group:
> >>>
> >>> A significant part of the Internet traffic today is generated by
> >>> peer-to-peer (P2P) applications used for file sharing, real-time
> >>> communications, and live media streaming.  P2P
> applications exchange
> >>> large amounts of data, often uploading as much as
> downloading.  In
> >>> contrast to client/server architectures, P2P applications
> often have
> >>> a selection of peers and must choose.
> >>>
> >>> One of the advantages of P2P systems comes from redundancy in
> >>> resource availability.  This requires choosing among download
> >>> locations, yet applications have at best incomplete information
> >>> about the topology of the network.  Applications can
> sometimes make
> >>> empirical measurements of link performance, but even when
> this is an
> >>> option it takes time.
> >>> The application cannot always start out with an optimal
> arrangement
> >>> of peers, thus causing at least temporary reduced performance and
> >>> excessive cross-domain traffic.  Providing more
> information for use
> >>> in peer selection can improve P2P performance and lower ISP costs.
> >>>
> >>> The Working Group will design and specify an Application-Layer
> >>> Traffic Optimization (ALTO) service that will provide
> applications
> >>> with information to perform better-than-random initial peer
> >>> selection.
> >>> ALTO services may take different approaches at balancing factors
> >>> including maximum bandwidth, minimum cross-domain traffic, lowest
> >>> cost to the user, etc.  The WG will consider the needs of
> >>> BitTorrent, tracker-less P2P, and other applications, such as
> >>> content delivery networks (CDN) and mirror selection.
> >>>
> >>
> >> What does the above sentence mean? If we are putting such a list
> >> together, we must also take into account needs from structured P2P
> >> overlays such as those being specified in P2PSIP.
> >>
> >>> The WG will focus on the following items:
> >>>
> >>> - A "problem statement" document providing a description of the
> >>>   problem and a common terminology.
> >>>
> >>> - A requirements document.  This document will list
> requirements for
> >>> the ALTO service, identifying, for example, what kind of
> information
> >>> P2P applications will need for optimizing their choices.
> >>>
> >>> - A request/response protocol for querying the ALTO service to
> >>> obtain information useful for peer selection, and a format for
> >>> requests and
> >>> responses.   The WG does not require intermediaries
> between the ALTO
> >>> server and the peer querying it.  If the requirements analysis
> >>> identifies the need to allow clients to delegate third-parties to
> >>> query the ALTO service on their behalf, the WG will
> ensure that the
> >>> protocol provides a mechanism to assert the consent of the
> >>> delegating client.
> >>>
> >>
> >> Is this meant to allow for entities such as proxies to be
> in the path?
> >>
> >>> - A document defining core request and response formats and
> >>> semantics to communicate network preferences to applications.
> >>>  Since ALTO services may be run by entities with
> different level of
> >>> knowledge about the underlying network, such preferences may have
> >>> different representations. Initially the WG will
> consider: IP ranges
> >>> to prefer and to avoid, ranked lists of the peers
> requested by the
> >>> client, information about topological proximity and approximate
> >>> geographic locations.
> >>> Other usages will be considered as extensions to the charter once
> >>> the work for the initial services has been completed.
> >>>
> >>
> >> Earlier, it is mentioned that the requirements document will
> >> determine the types of information that are useful for P2P
> >> applications.  Given that, it seems premature to conclude
> that the WG
> >> should consider the above mentioned parameters.  Also, as
> I mentioned
> >> earlier, I think it is essential to keep the protocol and message
> >> formats extensible and allow for exchange of any
> registered information type.
> >>
> >> Another question I have is about the assumptions around
> expected peer
> >> addressing models.  Some of the above seems to hint at IP
> addresses -
> >> is this an assumption already?
> >>
> >>> - In order to query the ALTO server, clients must first
> know one or
> >>> more ALTO servers that might provide useful information.  The WG
> >>> will look at service discovery mechanisms that are in use, or
> >>> defined elsewhere (e.g.
> >>> based on DNS SRV records or DHCP options).  If such discovery
> >>> mechanisms can be reused, the WG will produce a document
> to specify
> >>> how they may be adopted for locating such servers.
> >>> However, a new, general-purpose service discovery
> mechanism is not
> >>> in scope.
> >>>
> >>
> >> Alternately, the clients may look for ALTO services within an
> >> overlay.  This can be modeled as service discovery within
> the overlay
> >> - I'm, however, not suggesting that we take on solutions for that.
> >>
> >>> When the WG considers standardizing information that the
> ALTO server
> >>> could provide, the following criteria are important to
> ensure real
> >>> feasibility.
> >>>
> >>> - Can the ALTO service technically provide that information?
> >>> - Is the ALTO service willing to obtain and divulge that
> information?
> >>> - Is it information that a client will find useful?
> >>
> >> I'm not sure how useful it is for us to answer this question.  The
> >> protocol we develop simply needs to be a container for any
> >> information that has a registered type and fits a certain format.
> >>
> >>> - Can a client get that information without excessive
> privacy concerns
> >>>   (e.g. by sending large lists of peers)?
> >>> - Is it information that a client cannot find easily some
> other way?
> >>>
> >>> After these criteria are met, the generality of the data will be
> >>> considered for prioritizing standardization work, for example the
> >>> number of operators and clients that are likely to be able to
> >>> provide or use that particular data.
> >>
> >> If we can build an extensible protocol, we don't need to
> define all
> >> possible kinds of information that get carried in it.
> >>
> >>> In any
> >>> case, this WG will not propose standards on how congestion is
> >>> signaled, remediated, or avoided, and will not deal with
> information
> >>> representing instantaneous network state.
> >>> Such issues belong to other IETF areas and will be treated
> >>> accordingly by the specific area.
> >>>
> >>> This WG will focus solely on the communication protocol between
> >>> applications and ALTO servers.  Note that ALTO services may be
> >>> useful in client-server environments as well as P2P environments,
> >>> although P2P environments are the first focus.  If, in
> the future,
> >>> the IETF considers changes to other protocols for actually
> >>> implementing ALTO servers (e.g.
> >>> application-layer protocols for Internet coordinate
> systems, routing
> >>> protocol extensions for ISP-based solutions), such work
> will be done
> >>> in strict coordination with the appropriate WGs.
> >>>
> >>
> >> I hope we can also look at the above from a generalized service
> >> perspective rather than just a client-server perspective.
> >>
> >> Thanks,
> >> Vidya
> >>
> >>> Issues related to the content exchanged in P2P systems are also
> >>> excluded from the WG's scope, as is the issue dealing
> with enforcing
> >>> the legality of the content.
> >>>
> >>> Goals and Milestones (very tentative dates):
> >>>
> >>> Apr 2009: Working Group Last Call for problem statement Jun
> >>> 2009: Submit problem statement to IESG as Informational Aug
> >>> 2009: Working Group Last Call for requirements document Oct
> >>> 2009: Submit requirements document to IESG as Informational Jan
> >>> 2010: Working Group Last Call for request/response protocol Jan
> >>> 2010: Working Group Last Call for usage document for
> communicating
> >>> network preferences Mar 2010: Submit request/response protocol to
> >>> IESG as Proposed Standard Mar
> >>> 2010: Submit usage document to IESG as Proposed Standard May
> >>> 2010: Working Group Last Call of discovery mechanism Jul
> >>> 2010: Submit discovery mechanism to IESG as Proposed Standard Aug
> >>> 2010: Dissolve or re-charter
> >>>
> >>> Initial Drafts for Consideration
> >>> - draft-marocco-alto-problem-statement-02 -- Application-Layer
> >>> Traffic Optimization (ALTO) Problem Statement
> >>> - draft-kiesel-alto-reqs-00 -- Application-Layer Traffic
> >>> Optimization
> >>> (ALTO) Requirements
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> IETF-Announce mailing list
> >>> IETF-Announce <at> ietf.org
> >>> https://www.ietf.org/mailman/listinfo/ietf-announce
> >>>
> >> _______________________________________________
> >> Ietf mailing list
> >> Ietf <at> ietf.org
> >> https://www.ietf.org/mailman/listinfo/ietf
> >>
> > _______________________________________________
> > p2pi mailing list
> > p2pi <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/p2pi
> >
>

Weekly posting summary for ietf <at> ietf.org

Total of 39 messages in the last 7 days.

script run at: Fri Oct 10 00:53:01 EDT 2008

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 10.26% |    4 |  9.77% |    25110 | tglassey <at> earthlink.net
 10.26% |    4 |  6.89% |    17701 | julian.reschke <at> gmx.de
  5.13% |    2 |  8.00% |    20546 | dotis <at> mail-abuse.org
  5.13% |    2 |  5.67% |    14571 | hardie <at> qualcomm.com
  5.13% |    2 |  4.94% |    12695 | john-ietf <at> jck.com
  5.13% |    2 |  4.15% |    10650 | olaf <at> nlnetlabs.nl
  2.56% |    1 |  6.52% |    16757 | vidyan <at> qualcomm.com
  5.13% |    2 |  3.69% |     9473 | tim.polk <at> nist.gov
  2.56% |    1 |  3.77% |     9697 | stephen.farrell <at> cs.tcd.ie
  2.56% |    1 |  3.47% |     8903 | harald <at> alvestrand.no
  2.56% |    1 |  3.38% |     8682 | ogud <at> ogud.com
  2.56% |    1 |  3.37% |     8654 | jonne.soininen <at> nsn.com
  2.56% |    1 |  3.23% |     8305 | christer.holmberg <at> ericsson.com
  2.56% |    1 |  3.02% |     7761 | lars.eggert <at> nokia.com
  2.56% |    1 |  2.89% |     7413 | nweaver <at> icsi.berkeley.edu
  2.56% |    1 |  2.83% |     7275 | john.elwell <at> siemens.com
  2.56% |    1 |  2.70% |     6942 | ingemar.s.johansson <at> ericsson.com
  2.56% |    1 |  2.48% |     6363 | narten <at> us.ibm.com
  2.56% |    1 |  2.32% |     5956 | cheshire <at> apple.com
  2.56% |    1 |  2.18% |     5612 | brian.e.carpenter <at> gmail.com
  2.56% |    1 |  2.16% |     5546 | leslie <at> thinkingcat.com
  2.56% |    1 |  2.09% |     5378 | ben <at> estacado.net
  2.56% |    1 |  2.03% |     5216 | jason.weil <at> cox.com
  2.56% |    1 |  1.79% |     4597 | michael.dillon <at> bt.com
  2.56% |    1 |  1.73% |     4456 | remi.denis-courmont <at> nokia.com
  2.56% |    1 |  1.73% |     4443 | paul.hoffman <at> vpnc.org
  2.56% |    1 |  1.60% |     4119 | alexey.melnikov <at> isode.com
  2.56% |    1 |  1.59% |     4075 | hartmans-ietf <at> mit.edu
--------+------+--------+----------+------------------------
100.00% |   39 |100.00% |   256896 | Total

NTIA request for feedback on DNSSEC deployment at the root zone

Folks,

The National Telecommunications and Information Administration  
published a "Notice of Inquiry" entitled
"Enhancing the Security and Stability of the Internet's Domain  Name  
and Addressing System" in today's
Federal Register:

> SUMMARY: The Department of Commerce (Department) notes the increase in
> interest among government, technology experts and industry
> representatives regarding the deployment of Domain Name and Addressing
> System Security Extensions (DNSSEC) at the root zone level. The
> Department remains committed to preserving the security and stability
> of the DNS and is exploring the implementation of DNSSEC in the DNS
> hierarchy, including at the authoritative root zone level.  
> Accordingly,
> the Department is issuing this notice to invite comments regarding
> DNSSEC implementation at the root zone.

If you have an opinion on whether DNSSEC should or should not be  
deployed in the root zone, I urge you to make
that position known by submitting comments.   Comments are due on  
November 24, 2008.   Contact details are
included in the NOI.

The "html" version of the NOI is available at
          http://frwebgate5.access.gpo.gov/cgi-bin/waisgate.cgi? 
WAISdocID=559077321003+0+0+0&WAISaction=retrieve

The PDF version is available at
          http://frwebgate5.access.gpo.gov/cgi-bin/PDFgate.cgi? 
WAISdocID=559077321003+0+1+0&WAISaction=retrieve

There are links to a number of process flow diagrams that may  
interest you.  (The Federal Register cannot include graphic
content.) Note that you will need to tweak the provided links  
regardless of which version you select; there are formatting
and linewrap issues that prevent following the links automatically.

Thanks,

Tim Polk

draft-hoffman-utf8-rfcs-03.txt

Hi.

A few brief comments on this document....

(1) A mailing list for discussion is not designated.  While I
would normally suggested rfc-interest, the document appears to
be written on the assumption that approval of this proposal
rests with the IETF (presumably via the IESG) and IAOC and not
with the RFC Editor (with presumed review by the IAB), so I am
sending to this list.

(2) The document seems to assume that availability of UTF-8
systems (or other systems based on Unicode with easy
transcoding) is now near-ubiquitous.  Actual experience,
especially with documents being transmitted between computers by
email and similar means, appears to be different.  While I look
forward to the day at which comprehensive UTF-8 support is
universally available, at least as an interchange format, I do
not believe that we are there yet... and that there is still a
considerable gap, especially among systems that, instead of
being ASCII-only, have been developed with a focused on either
ISO 8859-1 or on a national coding system in East Asia.

(3) The document indicates that display systems that cannot
properly handle UTF-8 usually display an incorrect character
from which the user can make inferences.   While that sometimes
happens --sometimes with considerable information loss as we
have seen with a common anomaly with quoted sections of email
when the system on which the response is being composed and
those on both sides do not all prefer UTF-8-- it is at least
equally common to see an "undisplayable character" indication
which is the same for all such characters, e.g., a small box or
question-mark.  The problem is less likely with RFCs than with
random email, but we do, often, quote from RFCs and I-Ds in
email messages while working on them.  Once those "undisplayable
character" indicators are transferred from one system to
another, information is irretrievably lost... finding "better
display software" (rarely a realistic choice) is not an option
for recovering that information.

(4) Permitting critical information in RFCs (including any
information that is considered normative and author contact
information) to be exclusively in non-ASCII UTF-8 creates the
possibilities that a would-be implementer may not be able to
interpret the document or that it will be impossible to contact
the author(s), especially if, as an anti-spam precaution,
authors supply postal addresses and not email ones.

(5) I think we could quibble at great length about the advice
that should be given about compatibility characters.  While it
is probably sensible to discourage their use, it is quite easy
to imagine cases in which they might be important if a string
was going to be represented correctly.   Those cases
specifically include correct spelling of author names in some
parts of the world and examples that, for one reason or another,
actually have to illustrate the role of those characters... and
author names and examples appear to be the main justifications
for this proposal.  On the other hand, as the authors point out,
the issues with input methods and display of compatibility
characters are often much more serious than they are with their
equivalents, especially when display routines start performing
character substitutions for characters for which they lack
precise and accurate display capability.

I suggest that the authors concentrate less on painting a rosy
picture of how widely UTF-8 is deployed and how easily the
problems can be overcome (e.g., "just get better display
software [, even if that requires replacing hardware and
operating systems ]"), and, instead, concentrate on a definition
that would provide reasonable and effective fallbacks when
things go wrong as, at least for the present, they certainly
will.  For example, permitting UTF-8 (with arbitrary non-ASCII
characters) by itself in contact information is not sensible for
the reasons given above, but permitting UTF-8 only with a
requirement for either ASCII transliteration (or equivalent) or
RFC 5137 encoding to be present as an alternative might be
perfectly sensible at the current level of UTF-8 deployment and
availability.  Similar comments would apply to references,
especially normative ones (the principle that the IETF operates
in English and that English, and only English, is needed to
understand its technical specifications goes well beyond the
question of UTF-8 in RFCs and this document does not appear to
intend to change it), and to at least some examples that were
necessary to understand the normative text.

    --john

RFC 2141 - URN Syntax

Hi,

I was looking at <http://tools.ietf.org/html/rfc2141> (URN syntax) and 
noticed that it's only a proposed standard. There do not seem to be any 
errata recorded (<http://www.rfc-editor.org/errata_search.php?rfc=2141>).

Would there be any objections if I tried to update the stuff that needs 
to be updated (references, ABNF), and submit as Draft Standard?

BR, Julian

The IETF policy needs to be expanded for two types of IPR Declarations.

Folks
The problem the IETF and its Management Face is that the creation of the IPR
process is not well, and IETF document's are regularly published by the IETF
without any understanding as to what those publishing events do to the
larger picture of the IP and its license.

IPR Design Flaws
----------------------
The IPR page has some interesting failings and the one that is really
important is that it blends "forward looking license statements" not
particular to any specific or existing IP with actual IPR disclosures in
with real Disclosure Statements regarding already existing IP controls
making it difficult to search that IPR DB for actually important IPR Claims.

Here is a specific filings from the NSA that is properly
done: https://datatracker.ietf.org/ipr/858/; and here is a filing that
is essentially meaningless - its a political statement about
events not disclosed and so it has no effect here except to
say that they intend to play nice. https://datatracker.ietf.org/ipr/170/

This architecture of IP Process makes it virtually impossible to search the
IPR DB for issues which may pertain to an initiative not yet or already
under way inside the IETF. That is a failing which is unacceptable since it
renders the IPR Process effectively useless as too costly to perform
for each document filed with the IETF as part of a Standards Practice.

In closing, this "blending of useless info" with specific patent information 
just
complicates the practice and document's the lack of design forethought that
went into the IPR Page and its workflow processes.

The fix
----------
Somehow - all IP Submissions to the IETF need to be verified against the IPR
DB and failing to do so makes the IETF's publishers co-conspirator's in an
electronic fraud under 18 USC 1030 (or so I personally believe).  If they
(those submissions) are published then there MUST be some notice in them
that there are relevant IPR filings and that the IPR DB needs to be checked
by all who would use this IP.

Because of the complexity and lack of design forethought that went into the
IPR-Disclosure Page IMHO it is unrealistic to just claim that people have to
check the IPR DB and that they all know this. That simply is not true in
most cases IMHO.

---
Personal Disclaimers Apply

TS Glassey