Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard

[Dave CROCKER]

The IESG wrote:
The IESG has received a request from an individual submitter to 
consider the following document:


- 'ESMTP and LMTP Transmission Types Registration '
  RFC 3848 as a Draft Standard



 +1

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard

[ned+ietf]

The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
>
> - 'ESMTP and LMTP Transmission Types Registration '
>   RFC 3848 as a Draft Standard


+1 


Ned

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Request for comments on proposed changes to the IETF Trust Legal Provisions (TLP)

[Marshall Eubanks]

Greetings;

The Trustees are proposing additional changes to the Legal Provisions  
Relating to IETF Documents effective September 12, 2009 (TLP 3.0).  
This is a formal request for community review, with a 30 day review  
period ending on December 27, 2009


The additional changes proposed here (TLP 4.1) are A.) at the request  
of the Alternate Stream managers regarding the treatment of 'code  
components' and B.) at the request of the community regarding the  
addition of Alternate Stream managers to the warranty disclaimer.  
These changes result from the discussion of the proposed changes  
announced on 23 October, which are included in this document for  
review as section C. PDF versions and differences between the existing  
TLP are available at http://trustee.ietf.org/policyandprocedures.html.


A.)  Elimination of BSD licensing for Alternate Stream documents

This action requires revisions to four sections: 4.c, 8.e, 8.f, and  
8.g as follows: [Note *** indictes begin and end added text)


Section 4.  License to Code Components.

c.	License.In addition to the licenses granted under Section 3,  
unless one of the legends contained in Section 6.c.i or 6.c.ii is  
included in an IETF Document containing Code Components, such Code  
Components are also licensed to each person who wishes to receive such  
a license on the terms of the “Simplified BSD License", as described  
below.  If a licensee elects to apply the BSD License to a Code  
Component, then the additional licenses and restrictions set forth in  
Section 3 and elsewhere in these Legal Provisions shall not apply  
thereto.  ***Note that this license is specifically offered for IETF  
Documents and may not be available for Alternate Stream documents. See  
Section 8 for licensing information for the appropriate stream.***


Section 8.  Application to non-IETF Stream Documents

[Note:  This language added to IAB, IRTF and Indep Submissions  
paragraphs:
	***Section 4 of these Legal Provisions shall not apply to documents  
in the [Stream], and all references to Section 4 hereof shall be  
disregarded with respect to documents in the [Stream]***]


	e.	IAB Document Stream.   Pursuant to Section 11 of RFC 5378, the IAB  
requested, as of April 4, 2008, that the IETF Trust act as licensing  
administrator for the IAB Document Stream and that these Legal  
Provisions be applied to documents submitted and published in the IAB  
Document Stream following the Effective Date of RFC 5378.  ***Section  
4 of these Legal Provisions shall not apply to documents in the IAB  
Document Stream, and all references to Section 4 hereof shall be  
disregarded with respect to documents in the IAB Document Stream***  
*** pursuant to [Refefrence] published on [DATE]***.  [Note: this last  
addition reflects the authority for the Elimination of BSD licensing  
for the IAB]


	f.	Independent Submission Stream.   Pursuant to RFC [] published  
on [DATE], the manager of the Independent Submission Stream has  
requested that the IETF Trust act as licensing administrator for the  
Independent Submission Stream and that these Legal Provisions be  
applied to documents submitted and published in the Independent  
Submission Stream following [DATE].  *** Section 4 of these Legal  
Provisions shall not apply to documents in the Independent Submission  
Stream, and all references to Section 4 hereof shall be disregarded  
with respect to documents in the Independent Submission Stream.***


	g.	IRTF Document Stream.   Pursuant to RFC [] published on  
[DATE], the manager of the IRTF Document Stream has requested that the  
IETF Trust act as licensing administrator for the IRTF Document Stream  
and that these Legal Provisions be applied to documents submitted and  
published in the IRTF Document Stream following [DATE].  ***Section 4  
of these Legal Provisions shall not apply to documents in the IRTF  
Document Stream, and all references to Section 4 hereof shall be  
disregarded with respect to documents in the IRTF Document Stream.***


B.)  Addition of Alternate Stream managers to warranty disclaimer

This action requires revision to two sections, 7.a and 8.c.ii.

7.  Terms Applicable to All IETF Documents

ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON AN  
"AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS  
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, THE  
INTERNET ENGINEERING TASK FORCE *** AND ANY APPLICABLE MANAGERS OF  
ALTERNATE STREAM DOCUMENTS, AS DEFINED IN SECTION 8 BELOW***, DISCLAIM  
ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY  
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY  
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A  
PARTICULAR PURPOSE.


8.  Application to non-IETF Stream Documents
c.  Alternate Stream License.

ii.	Each occurrence of the term “IETF Contribution” and “IETF  
Documen

Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[james woodyatt]

On Nov 19, 2009, at 06:14 , Dave Cridland wrote:
> 
> There exist a few protocols based around mDNS and DNS-SD, in particular in 
> combination, and the general high-level design of both protocols is 
> essentially sound. These are sometimes standards-track specifications of the 
> IETF - I seem to recall some of the SIP related protocols are DNS-SD/mDNS 
> based. In other SDOs, there are also standards track specifications based 
> around the combination, such as the XSF's XEP-0174 - 
> http://www.xmpp.org/extensions/xep-0174.html - and these are also reliant on 
> a stable, well-specified, protocol. To my mind, this implies that both 
> specifications need to be standards track, if that status has any meaning at 
> all - and I firmly believe it should and does.

Chiming in to add another ongoing standards effort that would like to reference 
this document by its RFC number: the TC32-TG21 - Proxying Support for Sleep 
Modes program at ECMA International, which is now circulating a draft for TC 
postal vote.  See  
for more information about this effort.

One reason to prefer a standards track document here would be to preempt 
procedural objections in ISO/IEC about references to informational category 
IETF documents, which have been known to arise from time to time in that body.  
There is some concern in TC32-TG21 about such objections to ancillary citations 
of RFC 4795, which is *also* an informational category document.  It's possible 
ISO/IEC won't object to the informational status of either document, but we 
have a chance to preempt those objections now by publishing mDNS as 
standards-track.

That said, having an RFC number for an informational mDNS document-- in a small 
number of weeks-- would be orders of magnitude more preferable than not having 
it, and having to wait an indefinite period of time for a standards track RFC 
to be published, if that's what IETF decides to do.

To make the obvious explicit, I support publishing this document as an RFC 
without any further delay.

If it could be published as standards-track, instead of informational, 
*without* *any* *further* *delay*, that would be excellent.  However, I believe 
there is nothing to be gained for the Internet community by any further delay 
in publishing this important document.

It should have been published years go, fergawdzakes.  Faster, please.


--
james woodyatt 
member of technical staff, communications engineering


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard

[Tony Hansen]

The IESG wrote:
The IESG has received a request from an individual submitter to consider 
the following document:


- 'ESMTP and LMTP Transmission Types Registration '
  RFC 3848 as a Draft Standard


+1

Tony Hansen
t...@att.com

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART LC review of draft-dusseault-http-patch-15.txt

[Lisa Dusseault]

I've added extra explanatory text in section 2 as well as the Security
Considerations section.  It's normative, but dependent on the use case
being appropriate, which gives emphasis to the implementor but still
allows the right thing to be done.

Lisa

On Fri, Nov 13, 2009 at 4:16 PM, Brian E Carpenter
 wrote:
> Roy,
>
> Just a couple more comments below, and then I will have
> said all I can usefully say.
>
> On 2009-11-14 12:57, Roy T. Fielding wrote:
>> On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
>>> On 2009-11-13 23:35, Julian Reschke wrote:
 Brian E Carpenter wrote:
> On 2009-11-13 20:19, Julian Reschke wrote:
>> Brian E Carpenter wrote:
>>> As far as I can tell, the proposal places the burden for ensuring
>>> atomicity entirely on the server. However, PATCH is explicitly not
>>> idempotent. If a client issues a PATCH, and the server executes the
>>> PATCH,
>>> but the client then fails to receive an indication of success due to
>>> an extraneous network glitch (and TCP reset?), then what prevents the
>>> client
>>> issuing the same PATCH again? In other words, absent a two-phase
>>> commit,
>>> there appears to be no transactional integrity.
>> How is this different from PUT or POST? If you need repeatability of the
>> request, just make the request conditional using "if-match"...
> PATCH seems more dangerous than those simply because it is partial
> update of a resource, and I don't feel it's sufficient to say that
> there might be a way of detecting that it has failed to complete,
> if you're executing a series of patches that build on one another.
 POST can be a partial update as well, for the simple reason that POST
 can be *anything*. As a matter of fact, people are using POST right now,
 as PATCH was removed in RFC 2616.
>>> I wasn't involved in reviewing RFC2616 (or in the original design of POST,
>>> even though it happened about 20 metres from my office at that time). But
>>> yes, POST also lacks transactional integrity. Incidentally, that recently
>>> caused me to donate twice as much as I intended to the relief fund for
>>> the tsunami in Samoa, although the direct cause was a network glitch.
>>
>> That doesn't have anything to do with POST lacking transactions.
>> Any server is fully capable of detecting repeated transactions
>> just by looking at the data sent.
>
> Not in this case. The service was instantiated once, received
> a legitimate series of POSTs, including the final one triggered
> by a SUBMIT button, and then the final response code to the client
> (a standard browser) vanished, for whatever reason. [Digression
> about why this failure was probably caused by a NAT deleted.]
> The human client simply sees a browser timeout and has no possible
> way of knowing whether the SUBMIT executed. As it turns out, my credit
> card bill later showed that it did.
>
> Talking about transactional integrity in the IETF has always been
> hard, for some reason. But something described as "patch" is exactly
> where you need it, IMHO.
 PATCH does not need to be special, and shouldn't be special. That being
 said, it wouldn't hurt to clarify that PATCH can be made repeatable
 (idempotent) by making it conditional.
>>> I would make that a SHOULD and, as I said originally, be more precise
>>> about how to use strong ETags to achieve it.
>>
>> No.  The patch format may be designed to be repeatable (append).
>> The patch format may include its own conditions (context diffs,
>> before/after metadata, etc.).  HTTP is neither a filesystem nor
>> a database, so don't expect the protocol to interfere with
>> legitimate communication just because some resources might
>> require transactions for tightly-coupled behavior.  That is not
>> the protocol's job.
>
> Given that HTTP took the stateless approach that it did,
> I don't expect the protocol to embed transactional integrity.
> But I do expect the protocol spec to describe in normative terms
> how to detect a relatively likely type of failure. I agree
> that whether that is needed depends on the use case for PATCH.
>
>     Brian
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-cheshire-dnsext-multicastdns (Multicast DNS) to Informational RFC

[Stephane Bortzmeyer]

On Wed, Nov 18, 2009 at 06:07:17AM -0800,
 The IESG  wrote 
 a message of 23 lines which said:

> - 'Multicast DNS '
> as an Informational RFC

I do not think that the publication of this document as it is would be
a good idea.

The main reason is that it reserves a Top-Level Domain (".local")
which is already used at many sites, without any sort of reasonable
process, except "we already decided to use it and deployed the code".

Unlike what the text of the I-D says in section 3.1, there is little
evidence that IETF can do so. Unless what happened with RFC 2606,
nothing indicates that IANA/ICANN or any other body agreed to the
"hijack".

The I-D also gives questionable advices such as using ".home" or
".lan" which are not (and for good reasons) in RFC 2606. 

The only reasons given in the current discussion on ietf@ietf.org are
"it is already deployed" and "we need such a protocol for the
dentist's office".

The first one is weak: certainly, it should not be possible for any
company to have a RFC just by deploying a protocol is has unilaterally
conceived. The IETF is not a Patent Office: it *does* check the
applications.

Also, the I-D is not a pure description of a deployed protocol. For
instance, it says "it is even more important to use DNSSEC or other
security mechanisms to ensure that the response is trustworthy" while
the current implementations have no such mechanism.

The second reason is also questionable since IETF already has RFC
4795, which is not mentioned even once in the I-D we are discussing!







signature.asc
Description: Digital signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Julian Reschke]

Jim Schaad wrote:

Let's just get this published and go with what we have even if it does not
necessarily read real pretty.  The text of the strings can be updated at a
later point by a modification of the RFC Style Guide if there are enough
complaints about how the text looks.  Given that it is boilerplate, I
personally don't care that it does not flow.

Jim


1) The text in the current draft is inconsistent. Please fix it. This is 
purely editorial.


2) Changing the boilerplate again adds another code path to all tools 
that need to produce it, requires additional test cases and so on (keep 
in mind that the tools we are written so that they can produce the 
correct boilerplate for historic documents as well). BTW I think we need 
a volunteer for xml2rfc.tcl to implement this anyway; it will not 
magically happen unless somebody digs into the TCL code and implements it.


Best regards, Julian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf