Re: Last Call: Adding a fragment identifier to the text/csv media type(see <draft-hausenblas-csv-fragment-06.txt>)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
From: "Pete Resnick" <presnick@xxxxxxxxxxxxxxxx>
To: "t.p." <daedulus@xxxxxxxxxxxxx>
Cc: <ietf@xxxxxxxx>
Sent: Monday, October 14, 2013 8:45 PM
> On 10/13/13 5:42 AM, t.p. wrote:
> > I find the security considerations in this registration rather weak.
> > What might have sufficed in 2005 seems to me inadequate for 2013.  I
> > would expect a clearer statement of what are or are not considered
> > threats or attacks and what mitigations there then are for them.
>
> I don't know that everyone is really understanding the request that is
> being made here. It is a bit unusual.
>
> RFC 4180 <http://tools.ietf.org/html/rfc4180> contains the current
> registration for text/csv. That registration has the "Change
Controller"
> as "IESG", which is to say it's a registration from an IETF document.
> Barring any change, that registration would remain exactly as it is
> (including its current Security Considerations).
>
> Someone outside of the IETF is publishing a document describing how to
> use fragment identifiers with text/csv. That document is being
published
> in the Independent Stream by the RFC Editor. Since the publication of
> RFC 4180, "fragment identifier" was added to the media type
registration
> procedures. <http://tools.ietf.org/html/rfc6838#section-4.11> The
> present document (draft-hausenblas) wants to update the existing IETF
> registration to include it's idea of fragment identifiers (which was
> absent from the RFC 4180 registration), though it will leave the IETF
> (via the IESG) as "Change Controller".
>
> This Last Call is to find out if the IETF is OK with a non-IETF
document
> updating an IETF registration. If the answer is "no", then we leave
the
> 4180 registration in place, or we tell the ISE that draft-hausenblas
is
> not conforming to IETF processes and that we want it to be an
> IETF-stream document. If the answer is "yes", we go ahead with the
> registration change based on whatever the ISE publishes. We can send
> comments to the author and to the ISE asking for changes, but it's not
> an IETF document; IETF consensus is not required and the ISE can
publish
> it anyway.
>
> So, your Last Call comments are *simply* on the registration update.
The
> document is not ours on which to comment.

Indeed, I fully understand that.  It is the new registration for this
media type that I am commenting on, nothing else, that the new
registration, if approved, will cause the IANA entry to point to the
text from this 2013 (more likely 2014) RFC for which I would expect the
Security Considerations, an integral part of this registration
regardless of what else is in this I-D, to be up to the standards that
the IETF impose on work carried out in 2013, which are higher than those
that were in place 10 years ago.  As I know from having been part of the
process of producing RFC over the past 10 years.

So I regard this registration as unsuitable as it stands and would
expect the IESG to ask for an updated Security Considerations.

I am not commenting on any aspect of this I-D except insofar as it
provides text that will form the registration as it will appear in the
IANA reference.

Tom Petch

>
> pr
>
> > ----- Original Message -----
> > From: "The IESG"<iesg@xxxxxxxx>
> > To: "IETF Announcement List"<ietf-announce@xxxxxxxx>
> > Cc:<iana@xxxxxxxx>
> > Sent: Thursday, October 10, 2013 7:50 PM
> >
> > The IESG has received a request to update the IANA registration of
> > the text/csv media type, adding an optional fragment identifier.
> > The request comes from a document in the Independent stream, and the
> > IESG is the change controller for the text/csv media type.
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> > final comments on this action. Please send substantive comments to
the
> > ietf@xxxxxxxx mailing lists by 2013-10-24. Exceptionally, comments
may
> > be sent to iesg@xxxxxxxx instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > The document making the request can be obtained via
> > http://datatracker.ietf.org/doc/draft-hausenblas-csv-fragment/
> >
>
> --
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
>






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]