RE: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Glen Zorn]

Arnt Gulbrandsen [mailto://a...@gulbrandsen.priv.no] writes:

> Simon Josefsson writes:
> > There is no requirement in the IETF process for organizations to
> > disclose patents as far as I can see. The current approach of only
> > having people participate, and disclose patents, in the IETF is easy
> > to work around by having two persons in an organization doing
> > different things: one works on specifying and standardizing
> > technology, and the other is working on patenting the technology.
> 
> How can you practically avoid the first person knowing about it?

It seems very easy to me, and need not imply any kind of plotting.  Many
large companies offer incentives for filing patents and in that case it is
in one's own self interest to be on the lookout for patentable ideas
whatever the source may be...

> 
> Arnt
> ___
> 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: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) to Proposed Standard

[Glen Zorn]

Paragraph 3 of section 4 says:

   Because this cipher suite is equivalent to an empty
   "renegotiation_info" extension, only renegotiation_info" may be used
   rehandshakes.

Leaving aside the incorrect punctuation, this doesn't make any sense to me.


In section 5, suggest replacing all occurrences of the word "draft" with the
word "specification".


In section 6.2, s/NOT allow clients who do not offer the
"renegotiation_info" extension/NOT allow clients which do not offer the
"renegotiation_info" extension/.





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

Spotted at an IEEE conference

[Richard Barnes]

___
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

[Stuart Cheshire]

On 30 Nov, 2009, at 15:23, Phillip Hallam-Baker wrote:


90% of this proposal is equally relevant to the enterprise case.
But the multicast part is not.


The document is called "Multicast DNS". Which parts of the document  
do you think do *not* relate to multicast?


Stuart Cheshire 
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

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

Gen-ART LC Review of draft-ietf-hip-native-api-09

[Ben Campbell]

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-hip-native-api-09
Reviewer: Ben Campbell
Review Date: 2009-11-30
IETF LC End Date: 2009-12-03
IESG Telechat date: (if known)

Summary: This draft is ready for publication as an experimental RFC. I have a 
small number of editorial comments that might be worth addressing if there is a 
new version prior to publication.

Major issues:

None

Minor issues:

None

Nits/editorial comments:

--Section  1, paragraph 3:
Please expand ORCHID on first mention.


-- Section 1, paragraph 4:
Please expand LSI on first mention.

-- Section 4.2, first paragraph after figure 3:

Am I correct in assuming the EAI_FAMILY error only happens if the ai_family 
field was set to AF_HIP? That is, it would not make sense for AF_UNSPEC? The 
paragraph structure makes it looks like it applies to both.

-- idnits returns the following, which I include without prejudice:

> idnits 2.11.15 
> 
> tmp/draft-ietf-hip-native-api-09.txt:
> 
>   Checking boilerplate required by RFC 5378 and the IETF Trust (see
>   http://trustee.ietf.org/license-info):
>   
> 
>   == The document has an IETF Trust Provisions (12 Sep 2009) Section 6.c(i)
>  Publication Limitation clause.
> 
> 
>   Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
>   
> 
>  No issues found here.
> 
>   Checking nits according to http://www.ietf.org/ID-Checklist.html:
>   
> 
>  No issues found here.
> 
>   Miscellaneous warnings:
>   
> 
>   == Line 393 has weird spacing: '... structsoc...'
> 
>   == Line 395 has weird spacing: '... structadd...'
> 
>   == The document seems to lack a disclaimer for pre-RFC5378 work, but was
>  first submitted before 10 November 2008.  Should you add the disclaimer?
>  (See the Legal Provisions document at
>  http://trustee.ietf.org/license-info for more information.) -- however,
>  there's a paragraph with a matching beginning. Boilerplate error?
> 
> 
>   Checking references for intended status: Experimental
>   
> 
>   == Outdated reference: A later version (-10) exists of
>  draft-ietf-shim6-multihome-shim-api-09
> 
>   == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533
> 
> 
>  Summary: 0 errors (**), 6 warnings (==), 0 comments (--).
> 
>  Run idnits with the --verbose option for more detailed information about
>  the items above.
> 
___
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

[Stuart Cheshire]

On 25 Nov, 2009, at 01:52, W.C.A. Wijngaards wrote:


* The rule that .local names MUST be sent to mdns(port 5353).  I feel
this is a little too strong, there are sites out there that have  
set ups

with .local in their unicast DNS.  Propose: SHOULD.



I think you may be misreading this.

A statement of "MUST do X" does not imply "MUST NOT do NOT X".

A host implementing Multicast DNS, performing a Multicast DNS query,  
MUST send that query to the Multicast DNS port, or it won't work.  
There's no "SHOULD" about it. An implementation cannot choose to send  
the Multicast DNS query to a different port and expect it to work.


A host implementing Multicast DNS generally implements a variety of  
other name resolution mechanisms like standard unicast DNS, NetBIOS,  
a local "/etc/hosts" file, etc., and names can be looked up via those  
mechanisms too. Indeed, you will find that if you install iTunes on  
your PC, even at a site that's set up a private DNS server for  
"local", the sky does not fall. What happens is that Windows (and Mac  
OS X too) look up dot-local names both ways.


Looking up names more than one way is not as efficient as it could  
be, and it might be better if we didn't have to do that, but it does  
work.


I will add some text explaining this.

Stuart Cheshire 
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

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

Re: Last Call: draft-ietf-pkix-attr-cert-mime-type (Theapplication/pkix-attr-cert Content Type for AttributeCertificates) to Informational RFC

[Spencer Dawkins]

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-pkix-attr-cert-mime-type-02
Reviewer: Spencer Dawkins
Review Date: 2009-11-30
IETF LC End Date: 2009-11-29
IESG Telechat date: (Not known)

Summary: This document is ready for publication as an Informational RFC.

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

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Scott Brim]

Simon Josefsson allegedly wrote on 11/30/2009 10:11 AM:
> There is no requirement in the IETF process for organizations to
> disclose patents as far as I can see.  The current approach of only
> having people participate, and disclose patents, in the IETF is easy to
> work around by having two persons in an organization doing different
> things: one works on specifying and standardizing technology, and the
> other is working on patenting the technology.

Simon, from rfc3979:

   l. "Reasonably and personally known": means something an individual
  knows personally or, because of the job the individual holds,
  would reasonably be expected to know.  This wording is used to
  indicate that an organization cannot purposely keep an individual
  in the dark about patents or patent applications just to avoid the
  disclosure requirement.  But this requirement should not be
  interpreted as requiring the IETF Contributor or participant (or
  his or her represented organization, if any) to perform a patent
  search to find applicable IPR.


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

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Scott Lawrence]

On Mon, 2009-11-30 at 18:50 +0100, Simon Josefsson wrote:
> Arnt Gulbrandsen  writes:
> 
> > Simon Josefsson writes:
> >> There is no requirement in the IETF process for organizations to
> >> disclose patents as far as I can see. The current approach of only
> >> having people participate, and disclose patents, in the IETF is easy
> >> to work around by having two persons in an organization doing
> >> different things: one works on specifying and standardizing
> >> technology, and the other is working on patenting the technology.
> >
> > How can you practically avoid the first person knowing about it?
> 
> Make sure (through confidentiality agreements) that the second one do
> not talk with the first?  Putting them in different continents helps.

Not relevant in this case - the participating individuals were named on
the patent applications as inventors.  It would be hard to convince a
judge that they didn't know...


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

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Brian E Carpenter]

On 2009-12-01 06:03, Thierry Moreau wrote:
> Simon Josefsson wrote:
>> Brian E Carpenter  writes:
>>
>>  
>>> On 2009-11-24 06:44, Steven M. Bellovin wrote:
>>>
 On Mon, 23 Nov 2009 08:16:49 -0500
 Scott Brim  wrote:

  
> Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM:
>
>> John-Luc said he is bound by confidentiality obligations from his
>> company, and I think the same applies to most employees of larger
>> organizations.  There is nothing explicit in BCP 79 to protect
>> against this apparent conflict of interest, or is there?
>>   
>Since disclosure is required
>for anyone submitting documents or participating in IETF
> discussions, a person who does not disclose IPR for this reason, or
> any other reason, must not contribute to or participate in IETF
> activities with respect to technologies that he or she reasonably and
> personally knows to be Covered by IPR which he or she will not
> disclose.
>
> 
 Precisely.  The conflict Simon mentions was of course known to most of
 the WG; that's one reason we have that clause.
   
>>> IMHO, BCP79 creates no particular problem for corporate lawyers who
>>> are instructed by their corporate management to ensure that the company
>>> behaves as a good citizen in its standards activities. This is strongly
>>> in the company's interests, anyway, since failure to disclose when
>>> required by a standards process threatens the validity of the patent.
>>> 
>>
>> There is no requirement in the IETF process for organizations to
>> disclose patents as far as I can see.  The current approach of only
>> having people participate, and disclose patents, in the IETF is easy to
>> work around by having two persons in an organization doing different
>> things: one works on specifying and standardizing technology, and the
>> other is working on patenting the technology.

Replying first to Simon:

The requirement is indeed on individual participants and only if they
"reasonably and personally" know about the IPR. But employees participating
in an activity for their employer are (afaik, IANAL) acting as agents
of their employer, and it's standard practice in most companies for
them to have their legal obligations such as IPR disclosure handled by
a company lawyer or IPR specialist. So the distinction really doesn't
matter. I believe that we included "reasonably and personally known"
exactly because of the problem of employees of one department of a big
company not knowing what other departments were doing, and to avoid the
onerous cost of a patent search for employees of companies holding tens
of thousands of patents. I believe that this setting of the rules has
worked well since the disclosure requirement was introduced in 1996.

> Hi Simon,
> 
> This is certainly correct in principles. But to which extent the IETF
> disclosure approach "is easy to work around by having two persons ..."
> is a matter of appreciation.
> 
> My understanding is that it is not easy to arrange protocol engineer
> rolls in such a way. I'm quite sure you don't have a clear case which
> you can refer to support the opposite view. The reason I am confident is
> that both inventor status and an IETF contributor require creativity in
> general. The IETF collective engineering faces technological challenges
> like any other design group.
> 
> I guess it is not realistic to expect managers to send protocol
> engineers with little creativity traits to the IETF in order to preserve
> the ability to file patent applications without disclosure.
>>> It really is not the IETF's problem. It is a problem for a company that
>>> chooses not to behave as a good citizen.
>>> 
>>
>> The situation remains that the IETF does not have any mechanism to apply
>> pressure on organizations to disclose patent information.
>>
>>   
> This is certainly correct, but I am afraid the cause is more profound
> than the above IPR disclosure work around. Specifically, the Qualcom vs
> Broadcom case on JVT over H.264 IPR would have taught corporate lawyers
> that a standardization body membership contract binding to the
> corporation is a must for IPR disclosure enforcement against the
> corporation. (I am not a lawyer ...) The IETF does not use this approach.

Replying to Thierry:

Again, IANAL, but I understand that participants and their employers
are bound by the IETF rules by the simple fact of participation, with
no need for an explicit contract. The famous Note Well text is simply
a reminder of that. The IETF doesn't need to enforce anything; patent
holders who break the rules will have to explain why to a judge, if
someone challenges their patent in court.

Of course, we can underline the point by choosing to rescind a standard
if a participant is found to have broken the rules.

Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ie

Gen-ART review of draft-ietf-sasl-gs2-18

[Spencer Dawkins]

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-sasl-gs2-18
Reviewer: Spencer Dawkins
Review Date: 2009-11-30
IETF LC End Date: 2009-11-18 (oops!)
IESG Telechat date: 2009-12-03

Summary: This document is almost ready for publication as a Proposed 
Standard. I did have one minor question about 13.3 (in my LATE review), but 
it should not be difficult to resolve, if an AD agrees with my question.


I did tag a fair number of nits, but these aren't part of the Gen-ART 
review, and are simply included as a convenience for anyone else who edits 
the document.


1.  Introduction

  The GS1 bridge failed to gain wide deployment for any GSS-API
  mechanism other than The "Kerberos V5 GSS-API mechanism" [RFC1964]

Spencer (nit): s/The "Kerberos/"The Kerberos/

  [RFC4121], and has a number of problems that lead us to desire a new

Spencer (nit): s/lead/led/

  bridge.  Specifically: a) GS1 was not round-trip optimized, b) GS1
  did not support channel binding [RFC5056].  These problems and the
  opportunity to create the next SASL password-based mechanism, SCRAM

Spencer (nit): please expand SCRAM on first use.

  [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL
  applications via GS2, provide the motivation for GS2.

  In particular, the current consensus of the SASL community appears to
  be that SASL "security layers" (i.e., confidentiality and integrity
  protection of application data after authentication) are too complex
  and, since SASL applications tend to have an option to run over a
  Transport Layer Security (TLS) [RFC5246] channel, redundant and best
  replaced with channel binding.

Spencer (nit): it's a LONG way from "too complex" to "redundant" in this 
sentence ;-) suggest moving "redundant" before the subclause, just for 
readability.


3.3.  Examples

  The last step translate each decimal value using table 3 in Base32

Spencer (nit): s/translate/translates/?

  [RFC4648].  Thus the SASL mechanism name for the SPKM-1 GSSAPI
  mechanism is "GS2-DT4PIK22T6A".

8.  GSS-API Parameters

  The mutual_req_flag MUST be set.  If channel binding is used then the
  client MUST check that the corresponding ret_flag is set when the
  context is fully establish, else authentication MUST fail.

Spencer (nit): s/establish/established/

  Use or non-use of deleg_req_flag and anon_req_flag is an
  implementation-specific detail.  SASL and GS2 implementors are
  encouraged to provide programming interfaces by which clients may
  choose to delegate credentials and by which servers may receive them.
  SASL and GS2 implementors are encouraged to provide programming
  interfaces which provide a good mapping of GSS-API naming options.

11.  GSS_Inquire_mech_for_SASLname call

  To allow SASL clients to more efficiently identify which GSS-API
  mechanism a particular SASL mechanism name refers to we specify a new
  GSS-API utility function for this purpose.

Spencer (nit): whew! hard to parse. Suggest "We specify a new GSS-API 
utility function to allow SASL clients to more efficiently identify the 
GSS-API mechanism that a particular SASL mechanism name refers to", or 
something like that?


13.3.  Additional Recommendations

  If the application requires security layers then it MUST prefer the
  SASL "GSSAPI" mechanism over "GS2-KRB5" or "GS2-KRB5-PLUS".

Spencer (minor): If "prefer the mechanism" is the right way to describe 
this, I apologize, but I don't know what the MUST means in practice - if 
this needs to be at MUST strength, I'd expect text like "MUST use X and MUST 
NOT use Y or Z", or "MUST use X unless the server doesn't support X".


14.  GSS-API Mechanisms that negotiate other mechanisms

  A GSS-API mechanism that negotiate other mechanisms interact badly

Spencer (nit): s/negotiate/negotiates/, and probably s/interact/will 
interact/ ?


  with the SASL mechanism negotiation.  There are two problems.  The
  first is an interoperability problem and the second is a security
  concern.  The problems are described and resolved below.

14.1.  The interoperability problem

  If a client implement GSS-API mechanism X, potentially negotiated
  through a GSS-API mechanism Y, and the server also implement GSS-API

Spencer (nit): s/implement/implements/

  mechanism X negotiated through a GSS-API mechanism Z, the
  authentication negotiation will fail.

14.2.  Security problem

  If a client's policy is to first prefer GSSAPI mechanism X, then non-
  GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
  mechanisms Y and Z but not X, then if the client attempts to
  negotiate mechanism X by using a GSS-API mechanism that negotiate

Spencer (nit): s/negotiate/negotiates/

  other mechanisms (such as SPNEGO), it may end up using mechanism Z

Spenc

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

[Dave Thaler]

The biggest problem I have with this document is among those pointed out by 
Wouter:
> * The rule that .local names MUST be sent to mdns(port 5353). I feel 
>   this is a little too strong, there are sites out there that have set ups 
>   with .local in their unicast DNS. Propose: SHOULD. 

As stated above, it's already a somewhat common practice to use .local 
in *private* DNS namespaces (e.g., corporate networks), whether we like 
it or not, and the current text in the mdns draft section 3 is incompatible
with this (i.e., it proposes to break them).

The current practice is cited in many places including:
http://tools.ietf.org/html/draft-kato-dnsop-local-zones-00 
> While it has yet been described in a RFC, .local is used to provide a
> local subspace of the DNS tree.  Formal delegation process has not been
> completed for this TLD.  In spite of this informal status, .local has
> been used in many installations regardless of the awareness of the
> users.

http://en.wikipedia.org/wiki/Top-level_domain 
> The top-level pseudo domain local is required by the Zeroconf protocol. 
> It is also used by many organizations internally, which may become a 
> problem for those users as Zeroconf becomes more popular.

And there's lots of places people have complained about this conflict
with mdns, such as:

http://lists.apple.com/archives/Macnetworkprog/2004/Oct/msg00089.html 
http://www.markwilson.co.uk/blog/2007/11/managing-simultaneous-access-to-resources-from-both-internal-and-external-dns-namespaces.htm
 
http://www.macosxhints.com/article.php?story=20040806232315819 
etc

-Dave
___
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

[Stuart Cheshire]

On 23 Nov, 2009, at 09:11, Cullen Jennings wrote:

Pretty much all the emails I have received on this have suggested  
we should just go publish it now. To be clear, I was not talking  
about forming a WG to go do a standards track version of this. I  
was talking about clicking one flag in the data tracker and  
changing it from information to standards track and publishing the  
draft "as is" as standards track.



I support this, with one modification: I don't think we need to  
commit to publishing this draft literally "as is".


People like Dave Cridland have pointed out legitimate style  
criticisms, which I'm happy to fix in the next couple of weeks.


As I'm sure you know (but others may not) a Standards-Track RFC  
doesn't need a Working Group. It's possible to have an Individual  
Submission Standards-Track RFC, subject to the IETF community  
reviewing it and finding it to be worthwhile, and this would not be  
the first time I've done that. Last year we published RFC 5227, "IPv4  
Address Conflict Detection", as an Individual Submission Standards- 
Track RFC.


I think Multicast DNS easily meets criteria for Proposed Standard. In  
fact, in terms of stability, maturity, deployment, number of  
independent implementations, etc., it easily meets criteria that for  
other protocols would qualify them for Draft Standard status.


When other Standards-Track RFCs and other standards bodies (ECMA,  
WiFi alliance, ISO/IEC, XMPP, etc.) need to reference Multicast DNS,  
having a Standards-Track document to reference helps avoid procedural  
objections.


Stuart Cheshire 
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

___
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

[Stuart Cheshire]

On 19 Nov, 2009, at 06:14, Dave Cridland wrote:

Since people thought I was merely being amusing, instead of also  
intending to make a point, let me rephrase in a dry, dull, and  
serious tone, so I'm no longer told it was "very amusing, but not  
much help".


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.


Thank you. I think you are right.

Unfortunately, the specification of both of them suffers in,  
essentially, the same ways.


...

- A considerable amount of space is given over to Apple trademarks,  
which I confess to finding deeply irritating. mDNS is not nearly so  
bad as DNS-SD in this regard, but this still applies. I have no  
problem with acknowledging the input of Apple here, but there's a  
thin line between acknowledgement and outright product placement.


I would be happy to work with you in the next couple of weeks to de- 
cruft the document and get a cleaned up draft submitted before  
Christmas.


What you're seeing is the end result of a gradual accretion of text  
over the course of eight years since draft-00 in 2001. It was  
natural, especially in the early days, that many of the examples came  
from Apple products. Here and now, in 2009, if this is to be  
published as a Standards Track RFC, I don't have any problem with  
removing many or even all mentions of Apple and Apple products.


FWIW, I see no need to go through an extensive BOF process, and -  
again given the levels of deployment - I'd anticipate rapid  
progress through the standards-track ought to be possible.



I agree.

Stuart Cheshire 
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

___
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

[Stuart Cheshire]

On 18 Nov, 2009, at 13:30, Peter Dambier wrote:


Apple supports it.
Linux supports it (mostly).
BSD supports it (mostly).

So half the world supports it.
When Microsoft too supports it, it is a standard.

I do support it (becomming a standard).



Some additional data points:

Anyone using iTunes on Windows also has Multicast DNS on Windows,  
which is quite a lot of people.


And there are the hand-held devices like iPhones and Google Android  
phones, where peer-to-peer games and other network applications use  
Multicast DNS.


Also, other devices like network printers use Multicast DNS too. (If  
you have a network printer, click on the Bonjour button in the Safari  
sidebar and see if your printer's status and configuration web page  
appears. If you're on Windows, you can get Safari from www.apple.com/safari/>.)


And if you have a TiVo, they use Multicast DNS too.

These days, if you use computers at all, you've got to be trying  
*really* hard not to own or use some device that has Multicast DNS in  
it.


Stuart Cheshire 
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

___
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

[Alexey Melnikov]

Julien ÉLIE wrote:


Hi,


Hi Julien,


- 'ESMTP and LMTP Transmission Types Registration '


[...]


Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html
Initial set of implementations is currently in the datatracker (see 
below).


I do not know to whom I should write that.
There is a trailing space at the end of the title.


RFC Editor is not responsible for that. I can ask Secretariat.


And the above URL is not the right one.


Implementation report for RFC 3848 is not upload yet to the URL listed 
above.

It can be found at the URL you've deleted from your reply.

The implementation report will be uploaded to 
http://www.ietf.org/iesg/implementation.html after IETF LC.


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

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Simon Josefsson]

Arnt Gulbrandsen  writes:

> Simon Josefsson writes:
>> There is no requirement in the IETF process for organizations to
>> disclose patents as far as I can see. The current approach of only
>> having people participate, and disclose patents, in the IETF is easy
>> to work around by having two persons in an organization doing
>> different things: one works on specifying and standardizing
>> technology, and the other is working on patenting the technology.
>
> How can you practically avoid the first person knowing about it?

Make sure (through confidentiality agreements) that the second one do
not talk with the first?  Putting them in different continents helps.

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

Re: [secdir] secdir review of draft-melnikov-imap-keywords-06

[Arnt Gulbrandsen]

Samuel Weiler answers Alexey:
Isn't it enough to have them in a consensus doc?")  And how do you 
expect the expert to encourage/enforce the SHOULD, given the 
"favour registering it over requiring perfect documentation" 
guideline?  Again, the current text isn't as clear as I'd like.


This is intentional. This is a judgment call by the expert.


This sounds inconsistent.  I'm hearing "it's within the scope of the 
expert's judgement to require an IETF Consensus doc" and "In cases 
when an IMAP Keyword being registered is already deployed, Expert 
Reviewers should favour registering it over requiring perfect 
documentation."  If I were an implementer who got told "you need a 
consensus doc", I'd be more than a little tempted to go ahead and 
deploy, then reapply for the registration.


That's now how it happens. The consensus issues mostly have been about 
naming (different names for the same thing), and IMO were caused by 
lack of knowledge/communication. Merely talking two the expert would 
likely fix most.


Also, I'd like to mention that Lisa asked two people whether they could 
serve; both of her nominees are people who would be likely to give 
helpful answers, not send implementers away with one-sentence answer 
such as "go write a consensus doc".


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

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Arnt Gulbrandsen]

Simon Josefsson writes:
There is no requirement in the IETF process for organizations to 
disclose patents as far as I can see. The current approach of only 
having people participate, and disclose patents, in the IETF is easy 
to work around by having two persons in an organization doing 
different things: one works on specifying and standardizing 
technology, and the other is working on patenting the technology.


How can you practically avoid the first person knowing about it?

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

RE: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity (TLS) Renegotiation Indication Extension) toProposed Standard

[Robert Dugal]

I support draft-ietf-tls-renegotiation-01.txt. 

-- 
Robert DugalSenior Software Developer
Certicom Corp.  A Subsidiary of Research In Motion 
rdu...@certicom.com
direct905.501.3848
fax     905.507.4230
www.certicom.com

-Original Message-
From: tls-boun...@ietf.org [mailto:tls-boun...@ietf.org] On Behalf Of The IESG
Sent: Monday, November 30, 2009 10:38 AM
To: IETF-Announce
Cc: t...@ietf.org
Subject: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport LayerSecurity 
(TLS) Renegotiation Indication Extension) toProposed Standard

The IESG has received a request from the Transport Layer Security WG 
(tls) to consider the following document:

- 'Transport Layer Security (TLS) Renegotiation Indication Extension '
as a Proposed Standard

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@ietf.org mailing lists by 2009-12-14. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-01.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19412&rfc_flag=0

___
TLS mailing list
t...@ietf.org
https://www.ietf.org/mailman/listinfo/tls

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Thierry Moreau]

Simon Josefsson wrote:

Brian E Carpenter  writes:

  

On 2009-11-24 06:44, Steven M. Bellovin wrote:


On Mon, 23 Nov 2009 08:16:49 -0500
Scott Brim  wrote:

  

Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM:


John-Luc said he is bound by confidentiality obligations from his
company, and I think the same applies to most employees of larger
organizations.  There is nothing explicit in BCP 79 to protect
against this apparent conflict of interest, or is there?
  

   Since disclosure is required
   for anyone submitting documents or participating in IETF
discussions, a person who does not disclose IPR for this reason, or
any other reason, must not contribute to or participate in IETF
activities with respect to technologies that he or she reasonably and
personally knows to be Covered by IPR which he or she will not
disclose.



Precisely.  The conflict Simon mentions was of course known to most of
the WG; that's one reason we have that clause.
  

IMHO, BCP79 creates no particular problem for corporate lawyers who
are instructed by their corporate management to ensure that the company
behaves as a good citizen in its standards activities. This is strongly
in the company's interests, anyway, since failure to disclose when
required by a standards process threatens the validity of the patent.



There is no requirement in the IETF process for organizations to
disclose patents as far as I can see.  The current approach of only
having people participate, and disclose patents, in the IETF is easy to
work around by having two persons in an organization doing different
things: one works on specifying and standardizing technology, and the
other is working on patenting the technology.

  

Hi Simon,

This is certainly correct in principles. But to which extent the IETF 
disclosure approach "is easy to work around by having two persons ..." 
is a matter of appreciation.


My understanding is that it is not easy to arrange protocol engineer 
rolls in such a way. I'm quite sure you don't have a clear case which 
you can refer to support the opposite view. The reason I am confident is 
that both inventor status and an IETF contributor require creativity in 
general. The IETF collective engineering faces technological challenges 
like any other design group.


I guess it is not realistic to expect managers to send protocol 
engineers with little creativity traits to the IETF in order to preserve 
the ability to file patent applications without disclosure.

It really is not the IETF's problem. It is a problem for a company that
chooses not to behave as a good citizen.



The situation remains that the IETF does not have any mechanism to apply
pressure on organizations to disclose patent information.

  
This is certainly correct, but I am afraid the cause is more profound 
than the above IPR disclosure work around. Specifically, the Qualcom vs 
Broadcom case on JVT over H.264 IPR would have taught corporate lawyers 
that a standardization body membership contract binding to the 
corporation is a must for IPR disclosure enforcement against the 
corporation. (I am not a lawyer ...) The IETF does not use this approach.


Regards,

- Thierry Moreau

/Simon
___
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

[W.C.A. Wijngaards]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I have reviewed draft (-08) and support it, on the Informational track.

Review comments.

* The NSEC type is used for negative responses (from a discussion in
DNSEXT).  However, the draft specifies that only the bitmap for types
0-255 is to be included.  I feel this is overly constrained.  The
restriction may prove burdensome, also since those types are not really
in use anyway (except DLV), the effect of the rule is very low.  Is this
for backwards compatibility?  If it is for packet size, well, TXT
records can be large too and are not disallowed either.

* The document is verbose, but well written.

* The rule that .local names MUST be sent to mdns(port 5353).  I feel
this is a little too strong, there are sites out there that have set ups
with .local in their unicast DNS.  Propose: SHOULD.

* The mdns resolver is highly integrated into the device it is on, with
an 'active interest and notification API'-recommended, with interface
changes (up down netmasks) and sleep-wake cycle information used.  Thus
this is very different from unicast DNS, whose servers are more
independent.  The rule to do punycode (unicast) to utf8 (multicast)
conversion does not make the codebase smaller.

* There is a line about the use of DNSSEC when mdns is used during a
unicast DNS outage.  The sentiment about protecting against forged
answers is fine (this issue is handled well in general), but I think
building a chain of trust towards DNSSEC-attested data is going to be
very hard when unicast DNS is down.

* I noted that the TC flag on unicast still means TCP fallback but this
does not work in all cases.  It is of course very useful to get large
replies to legacy (unicast) queriers.  Case: the other hosts can see a
multicast query, and the full answer cannot be sent on multicast (due to
size, even with TC=1 on multicast for message concatenation), the other
hosts conclude there is no answer after timeout.  The unicast response
to the querier does have the required effect, but only for the original
querier.  This is probably not an issue since such large (9kb RR rdata)
records are not common.  A response that would trigger TCP connections
from all multicast hosts on the network is probably not such a good idea
:-)  Some multicast error response, SERVFAIL for that query, so the
other hosts do not modify their cache? (since existing code ignores
rcode!=0, this is probably backwards compatible)

* It may be prudent to have in conflict resolution a line that says that
if repeated conflicted announcements of unique records are observed by
another host, then the host SHOULD consider itself to have lost (and
rename itself).  Or put differently: if a particular host on the network
keeps causing conflicts, get out of the way, even if the spec says you
should have won, because this avoids packet-chatter on the network.

Best regards,
   Wouter
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAksM/mEACgkQkDLqNwOhpPjivQCbBx+PkX9gYv5k5ZjVs8Wa1dZW
93EAoIcyGETGZf4UYXZMcVoS2Y2WGY++
=l/6N
-END PGP SIGNATURE-
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [secdir] secdir review of draft-melnikov-imap-keywords-06

[Samuel Weiler]

On Wed, 18 Nov 2009, Alexey Melnikov wrote:

Further registrations will be done by the designated expert. I am 
concerned that if I put all of them in the document, then the 
document will never finish.


Sympathies.


And for the common-use:

   Registration of an IMAP keyword intended for common use (whether or
   not they use the "$" prefix) requires Expert Review [RFC5226].  IESG
   appoints one or more Expert Reviewer, one of which is designated as
   the primary Expert Reviewer.  IMAP keywords intended for common use
   SHOULD be standardized in IETF Consensus [RFC5226] documents. ...
   In cases when an IMAP
   Keyword being registered is already deployed, Expert Reviewers
   should favour registering it over requiring perfect documentation.

Would it be better to say: "requires either IETF Consensus or Expert 
Review"?


Not everybody is subscribed to ietf or ietf-announce mailing lists, so I 
would like for all common use registrations to go through the expert.


I don't like the logic (while not everybody is subscribed to the 
lists, your expert surely could be, and it's easy from an AD to punt 
the doc to the expert).


That said, since you want everything to go through the expert, to 
avoid confusion, I suggest removing the citation to the inapplicable 
5226 metric: "IETF Consensus [RFC5226]".


(For example: do the registrations made in this doc have to go through 
Expert Review?


No, because they are a part of the document that creates the registry ;-).

Isn't it enough to have them in a consensus doc?")  And how do you expect 
the expert to encourage/enforce the SHOULD, given the "favour registering 
it over requiring perfect documentation" guideline?  Again, the current 
text isn't as clear as I'd like.


This is intentional. This is a judgment call by the expert.


This sounds inconsistent.  I'm hearing "it's within the scope of the 
expert's judgement to require an IETF Consensus doc" and "In cases 
when an IMAP Keyword being registered is already deployed, Expert 
Reviewers should favour registering it over requiring perfect 
documentation."  If I were an implementer who got told "you need a 
consensus doc", I'd be more than a little tempted to go ahead and 
deploy, then reapply for the registration.


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

Re: [secdir] secdir review of draft-melnikov-imap-keywords-06

[Tero Kivinen]

Samuel Weiler writes:
> >>Registration of an IMAP keyword intended for common use (whether or
> >>not they use the "$" prefix) requires Expert Review [RFC5226].  IESG
> >>appoints one or more Expert Reviewer, one of which is designated as
> >>the primary Expert Reviewer.  IMAP keywords intended for common use
> >>SHOULD be standardized in IETF Consensus [RFC5226] documents. ...
> >>In cases when an IMAP
> >>Keyword being registered is already deployed, Expert Reviewers
> >>should favour registering it over requiring perfect documentation.
> >> 
> >> Would it be better to say: "requires either IETF Consensus or Expert 
> >> Review"?
> >
> > Not everybody is subscribed to ietf or ietf-announce mailing lists, so I 
> > would like for all common use registrations to go through the expert.
> 
> I don't like the logic (while not everybody is subscribed to the 
> lists, your expert surely could be, and it's easy from an AD to punt 
> the doc to the expert).

Acting as an IANA expert for IKEv2 registries, I have noticed that
expert do not get any option to say anything for documents which go
through IESG. The IANA registry is just updated without any discussion
with expert in those cases. So I do not think whether it affects
anything if you say "requires Expert Review" compared to the "requires
Expert Review or IETF Consensus", or at least you might want to add
explicit text to make it sure that the review policy mandates that all
assignments go through the Expert..
-- 
kivi...@iki.fi
___
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

[Julien ÉLIE]

Hi,


- 'ESMTP and LMTP Transmission Types Registration '

[...]

Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation.html
Initial set of implementations is currently in the datatracker (see below).


I do not know to whom I should write that.
There is a trailing space at the end of the title.
And the above URL is not the right one.

--
Julien ÉLIE

« Hâte-toi de bien vivre et songe que chaque jour
 est à lui seul une vie. » (Sénèque) 


___
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!

[Jim Schaad]

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


> -Original Message-
> From: rfc-interest-boun...@rfc-editor.org [mailto:rfc-interest-
> boun...@rfc-editor.org] On Behalf Of Julian Reschke
> Sent: Tuesday, November 24, 2009 5:02 AM
> To: IETF discussion list; rfc-inter...@rfc-editor.org; xml2rfc
> Subject: [rfc-i] Important: do not publish "draft-iab-streams-headers-
> boilerplates-08" as is!
> 
> Hi,
> 
> I just created five test cases representing the appendices A.1 to A.5.
> Turns out that the text in the examples is not in sync with the
> definitions in Section 3 (see, for instance,
>  b.a2.test.xhtml>).
> 
> Best regards, Julian
> 
> Julian Reschke wrote:
> > Julian Reschke wrote:
> >>
> >>  08#section-3.2.3>
> >> says:
> >>
> >>"Information about the current status of this document, any
> errata,
> >>and how to provide feedback on it may be obtained at
> >>http://www.rfc-editor.org//rfc.html"
> >>
> >> Can we please recommend *not* to put a file extension into the URL?
> >>
> >> BR, Julian
> >> ...
> >
> > Hi,
> >
> > in the meantime I have finished a prototype implementation of the new
> > boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is
> > available from ,
> and
> > requires the use of two new extension Processing Instructions to
> enable
> > the new boilerplate:
> >
> >   
> >   
> >
> > (where the first enables the new format, while the second provides
> the
> > information about whether there was consensus, something the current
> > xml2rfc format doesn't provide).
> >
> > I haven't found any problems in addition to what was reported before,
> > except for a trailing dot in one of the boilerplate statements, and
> > cases of repeating sentence beginnings -- maybe all of this can be
> fixed
> > during AUTH48 (although I'd prefer to see this in a new draft for
> > community review).
> >
> > For the record, here's a complete summary:
> >
> > -- snip --
> > 3.1.  The title page header
> >
> >  This describes the area where the work
> originates.
> >   Historically, all RFCs were labeled Network Working Group.
> >   "Network Working Group" refers to the original version of
> today's
> >   IETF when people from the original set of ARPANET sites and
> >   whomever else was interested -- the meetings were open -- got
> >   together to discuss, design and document proposed protocols
> >   [RFC0003].  Here, we obsolete the term "Network Working Group"
> in
> >   order to indicate the originating stream.
> >
> >   The  is the name of the RFC stream, as defined
> in
> >   [RFC4844] and its successors.  At the time of this publication,
> >   the streams, and therefore the possible entries are:
> >
> >   *  Internet Engineering Task Force
> >
> >   *  Internet Architecture Board
> >
> >   *  Internet Research Task Force
> >
> >   *  Independent
> >
> > JRE: as discussed earlier: should this be "Independent Submission"
> > instead of "Independent"?
> >
> >[:]  Some relations between RFCs in
> the
> >   series are explicitly noted in the RFC header.  For example, a
> new
> >   RFC may update one or more earlier RFCs.  Currently two
> >   relationships are defined: "Updates", and "Obsoletes"
> [RFC2223].
> >   Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
> >   Other types of relationships may be defined by the RFC Editor
> and
> >   may appear in future RFCs.
> >
> > JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".
> >
> > 3.2.2.  Paragraph 2
> >
> >The second paragraph of the "Status of This Memo" will now include
> a
> >paragraph describing the type of review and exposure the document
> has
> >received.  This is defined on a per-stream basis, subject to
> general
> >review and oversight by the RFC Editor and IAB.  There is a
> specific
> >structure defined here to ensure there is clarity about review
> >processes and document types.  These paragraphs will need to be
> >defined and maintained as part of RFC stream definitions.  Initial
> >text, for current streams, is provided below.
> >
> >The paragraph may include some text that is specific to the
> initial
> >document category, as follows: when a document is Experimental or
> >Historic the second paragraph opens with:
> >
> >Experimental:  "This document defines an Experimental Protocol for
> >   the Internet community."
> >
> >Historic:  "This document defines a 

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

[Alice Hagens]

Can we please recommend *not* to put a file extension into the URL?


The text can be updated - there is no file extension. The URL is of  
the form:

http://www.rfc-editor.org//rfc

For example:
http://www.rfc-editor.org/info/rfc2026

RFC Editor/ah

On Nov 24, 2009, at 7:01 AM, Julian Reschke wrote:


Hi,

I just created five test cases representing the appendices A.1 to A.5.
Turns out that the text in the examples is not in sync with the
definitions in Section 3 (see, for instance,
).


Best regards, Julian

Julian Reschke wrote:

Julian Reschke wrote:




says:

   "Information about the current status of this document, any  
errata,

   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

Can we please recommend *not* to put a file extension into the URL?

BR, Julian
...


Hi,

in the meantime I have finished a prototype implementation of the new
boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is
available from ,  
and
requires the use of two new extension Processing Instructions to  
enable

the new boilerplate:

  
  

(where the first enables the new format, while the second provides  
the

information about whether there was consensus, something the current
xml2rfc format doesn't provide).

I haven't found any problems in addition to what was reported before,
except for a trailing dot in one of the boilerplate statements, and
cases of repeating sentence beginnings -- maybe all of this can be  
fixed

during AUTH48 (although I'd prefer to see this in a new draft for
community review).

For the record, here's a complete summary:

-- snip --
3.1.  The title page header

 This describes the area where the work  
originates.

  Historically, all RFCs were labeled Network Working Group.
  "Network Working Group" refers to the original version of  
today's

  IETF when people from the original set of ARPANET sites and
  whomever else was interested -- the meetings were open -- got
  together to discuss, design and document proposed protocols
  [RFC0003].  Here, we obsolete the term "Network Working  
Group" in

  order to indicate the originating stream.

  The  is the name of the RFC stream, as  
defined in

  [RFC4844] and its successors.  At the time of this publication,
  the streams, and therefore the possible entries are:

  *  Internet Engineering Task Force

  *  Internet Architecture Board

  *  Internet Research Task Force

  *  Independent

JRE: as discussed earlier: should this be "Independent Submission"
instead of "Independent"?

   [:]  Some relations between RFCs  
in the
  series are explicitly noted in the RFC header.  For example,  
a new

  RFC may update one or more earlier RFCs.  Currently two
  relationships are defined: "Updates", and  
"Obsoletes" [RFC2223].

  Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
  Other types of relationships may be defined by the RFC  
Editor and

  may appear in future RFCs.

JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".

3.2.2.  Paragraph 2

   The second paragraph of the "Status of This Memo" will now  
include a
   paragraph describing the type of review and exposure the  
document has
   received.  This is defined on a per-stream basis, subject to  
general
   review and oversight by the RFC Editor and IAB.  There is a  
specific

   structure defined here to ensure there is clarity about review
   processes and document types.  These paragraphs will need to be
   defined and maintained as part of RFC stream definitions.  Initial
   text, for current streams, is provided below.

   The paragraph may include some text that is specific to the  
initial

   document category, as follows: when a document is Experimental or
   Historic the second paragraph opens with:

   Experimental:  "This document defines an Experimental Protocol for
  the Internet community."

   Historic:  "This document defines a Historic Document for the
  Internet community."

JRE: the way paragraph 2 is generated, we end up with instances where
the 1st and 2nd sentence both start with "This document". This is  
ugly.

Is it too late to fix this?

  In addition a sentence indicating the consensus base within the
  IRTF may be added: "This RFC represents the consensus of the
   Research Group of the Internet Research Task  
Force

  (IRTF)." or alternatively "This RFC represents the individual
  opinion(s) of one or more members of the  Research
  Group of the Internet Research Task Force (IRTF)".

JRE: trailing dot missing in 2nd variant.


3.2.3.  Paragraph 3

   "Information about the current status of this document, any  
errata,

   and how t

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Alfred Hönes]

Folks,

At Tue, 24 Nov 2009 16:00:48 +0100, Julian Reschke wrote:

> To illustrate the problem: for "IETF Experimental, with Consensus
> Call", we get:
>
>"This document defines an Experimental Protocol for the Internet
> community. This document is a product of the Internet Engineering
> Task Force (IETF). It represents the consensus of the IETF
> community..."
>
> I think
>
>"This document defines an Experimental Protocol for the Internet
> community. It is a product of the Internet Engineering Task Force
> (IETF) and represents the consensus of the IETF community..."
>
>
> would read much better.
>
> Best regards, Julian


(1)
For clarity in the "Experimental" case, I'd like to add:

The sentence,
   "Discussion and suggestions for improvement are requested."
had been left over in multiple examples in Appendix A.  It had
been confirmed that it would be deleted in all instances, since
this sentence does not appear in the normative text of the memo.
But apparently, it has been left undetected in the example in A.2.


At Mon, 26 Jan 2009 10:52:20 +0100, Olaf Kolkman wrote:
> On Jan 23, 2009, at 5:13 PM, Alfred Hönes wrote:
>
> ...
>
> Again Alfred, thanks ...
>
> You identified 2 issues, that have not been brought up before. And
> although we should have passed the done-is-done point I think that
> these points are substantive enough to address, while IMHO not really
> contentious, and since I am spinning the document for all the NITS I
> plan to address them as below.
>
>>   start quote  
>>
>> However, I have one general concern, and one important suggestion:
>>
>> The boilerplate sentence
>>  "Discussion and suggestions for improvement are requested."
>> apparently now shall only be included for Experimental RFCs.
>>
>> In the past, it was generally applied, and I always understood
>> it to be at the heart of the IETF process and culture.
>> I don't recall that this topic has been discussed on the list,
>> so it's dropping might have happened inadvertantly.  Please check.
>> IMHO, Proposed Standards (for instance) would need feedback
>> perhaps even more than Experimental documents; only for RFCs
>> immediately published as Historic this clause makes less sense.
>> In the case of Independent Submissions describing 3rd-party
>> protocols, RFC publication might have been sought for just this
>> goal, to start discussion in the IETF at large.
>> According to my experience, even the IAB appreciates feedback
>> to IAB Stream RFCs after publication.   :-)
>
> This inconsistency seemed to have been introduced inadvertently.
>
> I propose to _not_ have this information in the boilerplate but
> include it explicitly in where the "Updates to this Reference"
> refers to (in section 3.4).

... and so it has been confirmed on the list subsequently,
and so happened the text changes, with the sincle exception
of the leftover sentence in Appendix A.2.

Hence, I conclude this sentence can be deleted by the RFC Editor
or in AUTH48 without violating procedural rules.


(2)
Even worse from the stylistic perspective is the "Historic" case;
for instance, assuming an IETF WG documenting an original
contribution to its work (text constructed according to Sect.3):

|  This document is not an Internet Standards Track specification; it
|  has been published for the historical record.
|
|! This document defines a Historic Document for the Internet community.
|! This document is a product of the Internet Engineering Task Force
|  (IETF).  It has been approved for publication by the Internet
|  Engineering Steering Group (IESG).  Not all documents approved by the
|  IESG are candidate for any level of Internet Standards; see Section 2
|  of RFC .


I strongly recommend to change

   "This document defines a Historic Document ..."
to
   "This document is a Historic Document ..."

and continuing with  "It is ..." in the next sentence, as proposed
by Julian for the "Experimental" case above.


(3)
IIRC, the IAB Chair once had stated on the rfc-interest list that,
in order to speed up the approval and publication of the document,
final wordsmithing shall be deferred to the RFC Editor.

Does this still hold?

If yes, please let the RFC Editor perform as usual what they are
being paid for, or adjust the language in AUTH48!

Thanks!




Note -- for the record of those who did not follow the discussion:

The much more pleasant and locical permutation of the same text
for the above case ...

|  This document is a Historic Document for the Internet community.
|  It is not an Internet Standards Track specification; it has been
|  published for the historical record.
|
|  This document is a product of the Internet Engineering Task Force
|  (IETF).  It has been approved for publication by the Internet
|  Engineering Steering Group (IESG).  Not all documents approved by the
|  IESG are candidate for any level of Internet Standards; see Section 2
|  of RFC .

... had been rejected.
There have

Re: RIM patents using a mime body in a message (and ignores IETF IPR rules)

[Simon Josefsson]

Brian E Carpenter  writes:

> On 2009-11-24 06:44, Steven M. Bellovin wrote:
>> On Mon, 23 Nov 2009 08:16:49 -0500
>> Scott Brim  wrote:
>> 
>>> Simon Josefsson allegedly wrote on 11/23/2009 5:03 AM:
 John-Luc said he is bound by confidentiality obligations from his
 company, and I think the same applies to most employees of larger
 organizations.  There is nothing explicit in BCP 79 to protect
 against this apparent conflict of interest, or is there?
>>>Since disclosure is required
>>>for anyone submitting documents or participating in IETF
>>> discussions, a person who does not disclose IPR for this reason, or
>>> any other reason, must not contribute to or participate in IETF
>>> activities with respect to technologies that he or she reasonably and
>>> personally knows to be Covered by IPR which he or she will not
>>> disclose.
>>>
>> Precisely.  The conflict Simon mentions was of course known to most of
>> the WG; that's one reason we have that clause.
>
> IMHO, BCP79 creates no particular problem for corporate lawyers who
> are instructed by their corporate management to ensure that the company
> behaves as a good citizen in its standards activities. This is strongly
> in the company's interests, anyway, since failure to disclose when
> required by a standards process threatens the validity of the patent.

There is no requirement in the IETF process for organizations to
disclose patents as far as I can see.  The current approach of only
having people participate, and disclose patents, in the IETF is easy to
work around by having two persons in an organization doing different
things: one works on specifying and standardizing technology, and the
other is working on patenting the technology.

> It really is not the IETF's problem. It is a problem for a company that
> chooses not to behave as a good citizen.

The situation remains that the IETF does not have any mechanism to apply
pressure on organizations to disclose patent information.

/Simon
___
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

[Arnt Gulbrandsen]

james woodyatt writes:
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.


It's not difficult to get a standards-track RFC out quickly from this 
point. Unusual, yes, but not difficult. Mark Crispin did it in a week 
or so for RFC 4315 (another basically sound document with severe but 
superficial problems).


The document author/editor has to react to comments and fix issues 
promptly. That's all there really is to it.


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