Re: Important Information about IETF 76 Meeting Registration

[Stephane Bortzmeyer]

On Mon, Aug 24, 2009 at 11:06:31AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 17 lines which said:

> Any statement somewhere explaining what will be done with the data?
> Since you talk about "electronic blue sheets", I assume there will
> be many sensors, at least one per room so, in theory, the readers
> may be able to gather a lot of data about attendees.

OK, the complete lack of answer is in itself a good indication. I will
opt out.

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

Re: Important Information about IETF 76 Meeting Registration

[Alexa Morris]

Stephane,

My apologies, I actually thought that I'd responded to this.

Handheld readers will be passed around the meeting rooms, much as the  
clipboards are now (and still will be). Individuals will swipe their  
card through the reader and pass it on. Once collected, the data will  
be used as the current Blue Sheet data is used, that is, to respond to  
subpoena requests for attendance at different sessions typically  
issued during a dispute over intellectual property. At the moment, we  
are planning to print out a copy of the electronically obtained data  
and store it with the regular blue sheets, then keep the source file  
with the rest of our electronic archives.


The data collected consist solely of an individuals full name and  
company/organization affiliation. We are not collecting email address  
information on the e-blue sheets.


Alexa



On Aug 31, 2009, at 2:15 AM, Stephane Bortzmeyer wrote:


On Mon, Aug 24, 2009 at 11:06:31AM +0200,
Stephane Bortzmeyer  wrote
a message of 17 lines which said:


Any statement somewhere explaining what will be done with the data?
Since you talk about "electronic blue sheets", I assume there will
be many sensors, at least one per room so, in theory, the readers
may be able to gather a lot of data about attendees.


OK, the complete lack of answer is in itself a good indication. I will
opt out.



---
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

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

draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Jari Arkko]

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last call 
in June because several IESG members felt uncomfortable with the IESG 
notes being used only in exceptional circumstances. I asked Russ to 
prepare the -07 version. This version allowed notes to be used at the 
IESG's discretion and suggested that the linkage (or lack thereof) to 
IETF work would typically be explained in the note. This version was 
taken to the second last call.


While the number of comments we received was small, after the last call 
was over I determined that the consensus was against this change. As a 
result, I asked Russ to prepare the -08 version. This version goes back 
to the "exceptional" wording from -06, but incorporated a number of 
editorial corrections that had been made in interim. I also took the 
draft back to the IESG telechat last week. The IESG was not extremely 
pleased with the new version, but my understanding is that they were 
willing to accept the changes. However, a new issue was brought up: one 
of the changes that Russ and I felt was editorial highlighted the fact 
that the document makes the IESG notes a recommendation to the RFC 
Editor, not something that would automatically always be applied to the 
published RFC. Some IESG members were concerned about this, and 
preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that is 
always applied to the published RFC. Please reply before the next IESG 
meeting on September 10. Some e-mails on this topic have already been 
sent in the Last Call thread -- I have seen those and there is no need 
to resend.


(For the record my own slight preference is b. But I have to say that I 
think the document has been ready to be shipped from version -06, and 
its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
 wrote:

> I would like to get some further input from the community on
> this draft.
>...
> And now back to the input that I wanted to hear. I would like
> to get a sense from the list whether you prefer (a) that any
> exceptional IESG note is just a recommendation to the RFC
> Editor or (b) something that is always applied to the
> published RFC. Please reply before the next IESG meeting on
> September 10. Some e-mails on this topic have already been
> sent in the Last Call thread -- I have seen those and there is
> no need to resend.

Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.

>...

regards,
  john

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian Rosen]

Following a request to look at this document, and with only a cursory look
at the archives, I'm confused.

The note is always intended to be included in the document itself, right?

Is this change designed to compel, as opposed to request, the RFC Editor to
include the note?

If the answer to those is yes, then I support the change.  The RFC Editor is
not selected to make judgments on whether a note from the IESG should, or
should not be included in a document.  It's not an editorial judgment, it's
is a technical concern.

However, I think some form of appeal is needed, perhaps to the IAB, that
would allow authors some measure of control of what goes in their document.

Brian

 


On 8/31/09 9:29 AM, "Jari Arkko"  wrote:

> I would like to get some further input from the community on this draft.
> 
> But first some background. This draft was brought to a second last call
> in June because several IESG members felt uncomfortable with the IESG
> notes being used only in exceptional circumstances. I asked Russ to
> prepare the -07 version. This version allowed notes to be used at the
> IESG's discretion and suggested that the linkage (or lack thereof) to
> IETF work would typically be explained in the note. This version was
> taken to the second last call.
> 
> While the number of comments we received was small, after the last call
> was over I determined that the consensus was against this change. As a
> result, I asked Russ to prepare the -08 version. This version goes back
> to the "exceptional" wording from -06, but incorporated a number of
> editorial corrections that had been made in interim. I also took the
> draft back to the IESG telechat last week. The IESG was not extremely
> pleased with the new version, but my understanding is that they were
> willing to accept the changes. However, a new issue was brought up: one
> of the changes that Russ and I felt was editorial highlighted the fact
> that the document makes the IESG notes a recommendation to the RFC
> Editor, not something that would automatically always be applied to the
> published RFC. Some IESG members were concerned about this, and
> preferred the latter.
> 
> And now back to the input that I wanted to hear. I would like to get a
> sense from the list whether you prefer (a) that any exceptional IESG
> note is just a recommendation to the RFC Editor or (b) something that is
> always applied to the published RFC. Please reply before the next IESG
> meeting on September 10. Some e-mails on this topic have already been
> sent in the Last Call thread -- I have seen those and there is no need
> to resend.
> 
> (For the record my own slight preference is b. But I have to say that I
> think the document has been ready to be shipped from version -06, and
> its unfortunate that we're not there yet, particularly since this
> document is holding up the implementation of the new headers and
> boilerplates system for independent submissions, IRTF submissions and
> IETF submissions. I will exhaust all possible means of getting this
> approved in the next meeting, as soon as I know what the community
> opinion is.)
> 
> Jari Arkko
> 
> ___
> 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 10:59 -0400 Brian Rosen
 wrote:

> Following a request to look at this document, and with only a
> cursory look at the archives, I'm confused.
> 
> The note is always intended to be included in the document
> itself, right?
> 
> Is this change designed to compel, as opposed to request, the
> RFC Editor to include the note?
> 
> If the answer to those is yes, then I support the change.  The
> RFC Editor is not selected to make judgments on whether a note
> from the IESG should, or should not be included in a document.
> It's not an editorial judgment, it's is a technical concern.

Brian,

Remember that 3932bis applies to the Independent Submission
stream, not to IETF documents of any flavor.  These are, in
general, documents that have not been formally reviewed in the
IETF (although many of them have been extensively discussed).
They are not IETF Stream documents, about which, subject to
push-back from WGs and the community, the IESG can do pretty
much as it likes.

For these documents, there is no IETF Last Call.  If the IESG
creates a note, that note reflects the individual judgments of
the ADs (and presumably IESG review and approval of those
judgments) and not the rough consensus of the IETF community.
Given that, while it may be a "technical concern" (or at least
reflective of a technical preference), it is a concern from (at
most) a group of individuals who happen to be on the IESG; there
is no requirement that it represent a technical concern from the
IETF community.  

In that context, what you are really asking for is that the
preferences or concerns of that group of individuals --
preferences that they could not get the RFC Editor or document
authors to accept through normal review channels -- override the
decision-making process and approval of a non-IETF stream.
Especially since we expect documents in the Independent
Submission stream that would carefully criticize or provide
alternatives to IETF-approved approaches (see RFC 4846), giving
the IESG that much authority, especially without consulting the
IETF Community and determining consensus, does not seem sensible
or consistent to me.  Indeed, it seems like a mechanism for
permitting only authorized dissent.

>...

YMMD.

john

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Robert Sparks]

John, Jari -

I was one of the folks expressing the concern Jari points to below,  
and it's
a small facet of a larger worry I have about a potential (and I think  
likely)
unintended consequence of the header/boilerplate changes. To capture  
that
in this thread (with apologies for walking through old discussions) :  
specifically,
I think we're making it even harder for people who are not deeply  
steeped in

IETF arcana to tell the difference between the output of a working group
(or any other IETF product) and the output of an individual. By  
downplaying
that distinction, we are also making it easier for people with the  
motivation
to champion technologies that compete with IETF products to convince  
those

non IETF-arcana-steeped folks around them to follow.

But, that's water under the headers and boilerplate consensus building  
bridge.


I think it should be more _routine_ than we are making it for _some_  
body

representing IETF consensus to shine a light on that distinction when
necessary. The escalation process you point to is a fairly high bar  
and it
puts providing the required energy on the wrong parties. I'm sensitive  
to

the 'how it has always been' argument, but we are exactly in the process
of changing to a new RFC-editor model.

I've also been asking a few regular contributors and some chairs what
they thought about this, and am very frustrated with how little  
attention

the entire change this small conversation is part of appears to have
received in the greater community. I don't know what to do to improve  
that
beyond what we're doing now (through calls like this and through  
individual

prodding).

RjS

On Aug 31, 2009, at 9:37 AM, John C Klensin wrote:




--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
 wrote:


I would like to get some further input from the community on
this draft.
...
And now back to the input that I wanted to hear. I would like
to get a sense from the list whether you prefer (a) that any
exceptional IESG note is just a recommendation to the RFC
Editor or (b) something that is always applied to the
published RFC. Please reply before the next IESG meeting on
September 10. Some e-mails on this topic have already been
sent in the Last Call thread -- I have seen those and there is
no need to resend.


Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.


...


   regards,
 john



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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

I have a serious concern about the impact of this decision and the 
perception of RFCs by the community that uses the output of the IETF.


The IETF process has a number of very strong safeguards in place to 
ensure that the protocols we publish have certain levels of quality and 
safety built in, and the Internet community at large has grown to 
associate that level of quality with the RFC series.


While the presence of alternate streams of publication doesn't bother 
me, I think they need to be automatically and prominently marked as 
being something other than an IETF document.


In particular, when a user accesses a document at a url of the form 
, there is going to be a strong 
presumption on their part that the document was produced by the IETF. In 
the cases that this presumption is incorrect, it seems tantamount to 
deception to tuck the distinction between IETF and non-IETF documents 
away in an obscure header field.


/a

Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last 
call in June because several IESG members felt uncomfortable with the 
IESG notes being used only in exceptional circumstances. I asked Russ 
to prepare the -07 version. This version allowed notes to be used at 
the IESG's discretion and suggested that the linkage (or lack thereof) 
to IETF work would typically be explained in the note. This version 
was taken to the second last call.


While the number of comments we received was small, after the last 
call was over I determined that the consensus was against this change. 
As a result, I asked Russ to prepare the -08 version. This version 
goes back to the "exceptional" wording from -06, but incorporated a 
number of editorial corrections that had been made in interim. I also 
took the draft back to the IESG telechat last week. The IESG was not 
extremely pleased with the new version, but my understanding is that 
they were willing to accept the changes. However, a new issue was 
brought up: one of the changes that Russ and I felt was editorial 
highlighted the fact that the document makes the IESG notes a 
recommendation to the RFC Editor, not something that would 
automatically always be applied to the published RFC. Some IESG 
members were concerned about this, and preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that 
is always applied to the published RFC. Please reply before the next 
IESG meeting on September 10. Some e-mails on this topic have already 
been sent in the Last Call thread -- I have seen those and there is no 
need to resend.


(For the record my own slight preference is b. But I have to say that 
I think the document has been ready to be shipped from version -06, 
and its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

___
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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

Before commenting on the question, I wish to comment slightly on the 
exposition.  While I understand that some IESG members were surprised 
that the text brought to them treated IESG notes as a recommendation to 
the RFC Editor, such surprise gap in historical information rather than 
a change.  That text was not a change in practice.  The documented rules 
and practice has long been that with regard to Independent Submissions 
the IESG notes are a request / recommendation to the RFC Editor (soon to 
be ISE), not a statement of what will be included in the result.


Based on having seen a number of IESG notes, and reading the resulting 
text and its inherent tone, I would strongly prefer that IESG notes be 
an exception.  Also, I believe that the stream identification and 
associated indications are quite sufficient for the normal case.  Unless 
we wish to deliberately denigrate the Independent Submissions tream, we 
should not be putting extra notes on the front of them.  I consider the 
Independent Stream to be an important source of information and 
commentary that helps the overall internet process, and would be very 
unhappy to see it denigrated.


Thus, I strongly prefer (a).   I prefer that such notes be rare, and 
that they remain recommendations to the ISE.


Even if the IAB were to agree that such notes should be common, I would 
strongly recommend that the tone and content of such notes remain at the 
discretion of the ISE.  Otherwise, there is no true Independent series.


Yours,
Joel M. Halpern

Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last call 
in June because several IESG members felt uncomfortable with the IESG 
notes being used only in exceptional circumstances. I asked Russ to 
prepare the -07 version. This version allowed notes to be used at the 
IESG's discretion and suggested that the linkage (or lack thereof) to 
IETF work would typically be explained in the note. This version was 
taken to the second last call.


While the number of comments we received was small, after the last call 
was over I determined that the consensus was against this change. As a 
result, I asked Russ to prepare the -08 version. This version goes back 
to the "exceptional" wording from -06, but incorporated a number of 
editorial corrections that had been made in interim. I also took the 
draft back to the IESG telechat last week. The IESG was not extremely 
pleased with the new version, but my understanding is that they were 
willing to accept the changes. However, a new issue was brought up: one 
of the changes that Russ and I felt was editorial highlighted the fact 
that the document makes the IESG notes a recommendation to the RFC 
Editor, not something that would automatically always be applied to the 
published RFC. Some IESG members were concerned about this, and 
preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that is 
always applied to the published RFC. Please reply before the next IESG 
meeting on September 10. Some e-mails on this topic have already been 
sent in the Last Call thread -- I have seen those and there is no need 
to resend.


(For the record my own slight preference is b. But I have to say that I 
think the document has been ready to be shipped from version -06, and 
its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

___
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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephen Farrell]

Joel M. Halpern wrote:
> Thus, I strongly prefer (a).   I prefer that such notes be rare, and
> that they remain recommendations to the ISE.

+1 to that,

S.

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

Re: Important Information about IETF 76 Meeting Registration

[Ole Jacobsen]

Stephane,

Chill out, it's an experiment. The details are yet to be worked out, 
but for instance it COULD be used to identify the person at the mike 
which would be good for the minutes and good for the Jabber scribe.
WIDE has used it for such in the past. A *possible* use would be to
automate the blue sheet data collection, but there are NO PLANS AT 
THIS TIME to replace the paper version. This is an EXPERIMENT.

Ole


Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



On Mon, 31 Aug 2009, Stephane Bortzmeyer wrote:

> On Mon, Aug 24, 2009 at 11:06:31AM +0200,
>  Stephane Bortzmeyer  wrote 
>  a message of 17 lines which said:
> 
> > Any statement somewhere explaining what will be done with the data?
> > Since you talk about "electronic blue sheets", I assume there will
> > be many sensors, at least one per room so, in theory, the readers
> > may be able to gather a lot of data about attendees.
> 
> OK, the complete lack of answer is in itself a good indication. I will
> opt out.
> 
> ___
> 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

If I understand your note properly, your primary concern is that folks 
will think that Independent submission are IETF products.

This is a fair concern.
But the same could be said all our experimental and informational RFCs. 
 Should we insist that all experimental and informational RFC, even 
from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD." 
Repeated multiple times to make sure folks do not miss it?

(remember, Independent Submissions are never standards track documents.)

Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.


While it is important to note when experimental or informational 
documents have had community review, and when they haven't, I do not see 
that the distinction, for these documents, warrants denigrating outside 
comment and input.


Remember also that in terms of the text being a recommendation, this is 
not a change in practice.  This is the practice we have had for more 
than the last 15 years.  If, for Independent Submissions, it is that big 
a problem, I would expect ot have heard of it.


Also, to pick up a comment from Robert, and reinforce and answer from 
John, in providing an IESG note for an Independent Submission, the IESG 
is not shining the light of IETF consensus (rough or otherwise) on the 
document.  While I strongly respect the IESG judgment, and want them to 
keep using and applying that judgment, I do not think it fair to 
conflate that with reflecting IETF consensus on something where there no 
source for such consensus.  (For clarity, I do want the IESG to have the 
opportunity to make their recommendation, and I want it taken serious by 
the ISE / RSE.  This is because they do have a view of the IETF activity 
picture, and can provide necessary perspective and judgment about the 
relationships among the moving parts.  But let us not induce confusion 
by assigning that judgment inappropriate grounding.)


Yours,
Joel

Adam Roach wrote:
I have a serious concern about the impact of this decision and the 
perception of RFCs by the community that uses the output of the IETF.


The IETF process has a number of very strong safeguards in place to 
ensure that the protocols we publish have certain levels of quality and 
safety built in, and the Internet community at large has grown to 
associate that level of quality with the RFC series.


While the presence of alternate streams of publication doesn't bother 
me, I think they need to be automatically and prominently marked as 
being something other than an IETF document.


In particular, when a user accesses a document at a url of the form 
, there is going to be a strong 
presumption on their part that the document was produced by the IETF. In 
the cases that this presumption is incorrect, it seems tantamount to 
deception to tuck the distinction between IETF and non-IETF documents 
away in an obscure header field.


/a

Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last 
call in June because several IESG members felt uncomfortable with the 
IESG notes being used only in exceptional circumstances. I asked Russ 
to prepare the -07 version. This version allowed notes to be used at 
the IESG's discretion and suggested that the linkage (or lack thereof) 
to IETF work would typically be explained in the note. This version 
was taken to the second last call.


While the number of comments we received was small, after the last 
call was over I determined that the consensus was against this change. 
As a result, I asked Russ to prepare the -08 version. This version 
goes back to the "exceptional" wording from -06, but incorporated a 
number of editorial corrections that had been made in interim. I also 
took the draft back to the IESG telechat last week. The IESG was not 
extremely pleased with the new version, but my understanding is that 
they were willing to accept the changes. However, a new issue was 
brought up: one of the changes that Russ and I felt was editorial 
highlighted the fact that the document makes the IESG notes a 
recommendation to the RFC Editor, not something that would 
automatically always be applied to the published RFC. Some IESG 
members were concerned about this, and preferred the latter.


And now back to the input that I wanted to hear. I would like to get a 
sense from the list whether you prefer (a) that any exceptional IESG 
note is just a recommendation to the RFC Editor or (b) something that 
is always applied to the published RFC. Please reply before the next 
IESG meeting on September 10. Some e-mails on this topic have already 
been sent in the Last Call thread -- I have seen those and there is no 
need to resend.


(For the record my own slight preference is b. But I have to 

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Joel M. Halpern wrote:
The documented rules 
and practice has long been that with regard to Independent Submissions 
the IESG notes are a request / recommendation to the RFC Editor (soon to 
be ISE), not a statement of what will be included in the result.

...
Based on having seen a number of IESG notes, and reading the resulting 
text and its inherent tone, I would strongly prefer that IESG notes be 
an exception.  

...


Thus, I strongly prefer (a).   I prefer that such notes be rare, and 
that they remain recommendations to the ISE.



+1.

It might help folks to understand the independent relationship, between the 
IETF/IESG and these other RFC streams, if the title of this draft were changed 
from "Handling of" to "Assisting with".


d/

--

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

Re: Important Information about IETF 76 Meeting Registration

[Paul Hoffman]

At 5:55 AM -0700 8/31/09, Alexa Morris wrote:
>The data collected consist solely of an individuals full name and 
>company/organization affiliation. We are not collecting email address 
>information on the e-blue sheets.

Please note that you are now also collecting information that *is not* on the 
current blue sheets, namely "company/organization affiliation". I have noted 
that some people I know who have signed a blue sheet before me have used 
personal email addresses while (I assume) their badge lists their actual 
"company/organization affiliation". As a person with multiple 
company/organization affiliations, I sometimes change the email address I put 
on the blue sheets to be the one most appropriate to the topic of the WG.

It is a bad idea to have this experiment create combined blue sheets that have 
data that differs depending on the collection method. There are probably a 
dozen WGs in the IETF who have had this problem come back and bite them on 
their collective backsides during protocol development or, unfortunately, after 
their protocols have deployed.

Please strongly consider having the readers record exactly what the current 
blue sheets record, or change the blue sheets to record what the readers are 
recording for this meeting. The first of these two will most likely cause less 
revolt.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian Rosen]

Yes, I understand, this only applies to the Independent Submission stream.

We ask the IESG to review these documents, and that review is technical.

I don't think it is appropriate for an editor to make a judgment of whether
a technical note is, or is not appropriate to be included in a document.  I
think the presumption should be that it is appropriate, and the authors have
a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their ability to
make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF consensus call.

Brian

On 8/31/09 11:25 AM, "John C Klensin"  wrote:

> 
> Brian,
> 
> Remember that 3932bis applies to the Independent Submission
> stream, not to IETF documents of any flavor.  These are, in
> general, documents that have not been formally reviewed in the
> IETF (although many of them have been extensively discussed).
> They are not IETF Stream documents, about which, subject to
> push-back from WGs and the community, the IESG can do pretty
> much as it likes.
> 
> For these documents, there is no IETF Last Call.  If the IESG
> creates a note, that note reflects the individual judgments of
> the ADs (and presumably IESG review and approval of those
> judgments) and not the rough consensus of the IETF community.
> Given that, while it may be a "technical concern" (or at least
> reflective of a technical preference), it is a concern from (at
> most) a group of individuals who happen to be on the IESG; there
> is no requirement that it represent a technical concern from the
> IETF community.  
> 
> In that context, what you are really asking for is that the
> preferences or concerns of that group of individuals --
> preferences that they could not get the RFC Editor or document
> authors to accept through normal review channels -- override the
> decision-making process and approval of a non-IETF stream.
> Especially since we expect documents in the Independent
> Submission stream that would carefully criticize or provide
> alternatives to IETF-approved approaches (see RFC 4846), giving
> the IESG that much authority, especially without consulting the
> IETF Community and determining consensus, does not seem sensible
> or consistent to me.  Indeed, it seems like a mechanism for
> permitting only authorized dissent.
> 
>> ...
> 
> YMMD.
> 
> john
> 


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

Re: Important Information about IETF 76 Meeting Registration

[Steve Crocker]

I won't be in Hiroshima and won't be able to participate nor will I be  
able to opt-out, so I don't have a personal stake in this and am  
commenting only as an interested observer.


As has been noted, this won't be an absolutely clean, seamless  
replacement of the blue sheets.  The list of possible downsides is  
already growing, e.g. privacy issues, inflexibility in choosing which  
email address to use for each working group, and I won't be surprised  
if the list grows a bit.  At the same time, the list of possible new  
capabilities is also growing, e.g. identifying the speaking at the  
microphone.


This sort of discussion is similar to other settings that are  
introducing electronic versions of previously manual processes, e.g.  
in the health care industry.  Let me offer a point of view and a  
suggestion.


Point of view: Rather than thinking of the RFID chips as serving to be  
simply a direct replacement of the blue sheets, take as a given that  
this will be a new and somewhat different technical foundation with  
some positives and some negatives.  The blue sheets also had positives  
and negatives, e.g. the cost and pain of storing them, the difficulty  
and cost of reading them, their legal status and retention policy,  
etc.  Look at the RFID chips from a fresh perspective, not solely as  
an automation of the blue sheets.


Suggestion: As noted above, similar issues apply in other settings.   
This community has an opportunity to tackle the interplay of  
technology and social policy issues that affect itself far more  
cogently and efficiently than most communities do.  Let's grasp the  
nettles and see if we can work through the issues in a sensible and  
rational way.  Do we need a privacy policy regarding the information  
collected?  If so, let's create one.  Do we need access controls on  
the information?  If so, let's create them.  Do we need an ability to  
edit information that's been collected if it's inaccurate?  If so,  
let's build it.  Do we need more flexibility in the information stored  
in the record, e.g. a distinct email address for each working group?   
If so, let's add it.


Steve







On Aug 31, 2009, at 12:27 PM, Paul Hoffman wrote:


At 5:55 AM -0700 8/31/09, Alexa Morris wrote:
The data collected consist solely of an individuals full name and  
company/organization affiliation. We are not collecting email  
address information on the e-blue sheets.


Please note that you are now also collecting information that *is  
not* on the current blue sheets, namely "company/organization  
affiliation". I have noted that some people I know who have signed a  
blue sheet before me have used personal email addresses while (I  
assume) their badge lists their actual "company/organization  
affiliation". As a person with multiple company/organization  
affiliations, I sometimes change the email address I put on the blue  
sheets to be the one most appropriate to the topic of the WG.


It is a bad idea to have this experiment create combined blue sheets  
that have data that differs depending on the collection method.  
There are probably a dozen WGs in the IETF who have had this problem  
come back and bite them on their collective backsides during  
protocol development or, unfortunately, after their protocols have  
deployed.


Please strongly consider having the readers record exactly what the  
current blue sheets record, or change the blue sheets to record what  
the readers are recording for this meeting. The first of these two  
will most likely cause less revolt.


--Paul Hoffman, Director
--VPN Consortium
___
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: Important Information about IETF 76 Meeting Registration

[Ole Jacobsen]

Paul,

The reason this is an EXPERIMENT is exactly to find out 
what/how/where/when information needs to be collected to
be useful for the IETF.

So, I can well imagine that we could have a "alias" or "identity" 
field that would represent exactly what you put on the bluesheet
and THIS is the information that would be collected. It might get
complicated if you have numerous aliases that you use for different 
working groups etc, but anyway, all of this is a matter of 
programming. I am going to assume (without having looked at the 
details) that the RFID card can hold a lot of information.

I am going to suggest that we, with the help of WIDE, start a 
discussion list where some of these details can be ironed out.

Cheers,

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: o...@cisco.com  URL: http://www.cisco.com/ipj



On Mon, 31 Aug 2009, Paul Hoffman wrote:

> At 5:55 AM -0700 8/31/09, Alexa Morris wrote:
> >The data collected consist solely of an individuals full name and 
> >company/organization affiliation. We are not collecting email 
> >address information on the e-blue sheets.
> 
> Please note that you are now also collecting information that *is 
> not* on the current blue sheets, namely "company/organization 
> affiliation". I have noted that some people I know who have signed a 
> blue sheet before me have used personal email addresses while (I 
> assume) their badge lists their actual "company/organization 
> affiliation". As a person with multiple company/organization 
> affiliations, I sometimes change the email address I put on the blue 
> sheets to be the one most appropriate to the topic of the WG.
> 
> It is a bad idea to have this experiment create combined blue sheets 
> that have data that differs depending on the collection method. 
> There are probably a dozen WGs in the IETF who have had this problem 
> come back and bite them on their collective backsides during 
> protocol development or, unfortunately, after their protocols have 
> deployed.
> 
> Please strongly consider having the readers record exactly what the 
> current blue sheets record, or change the blue sheets to record what 
> the readers are recording for this meeting. The first of these two 
> will most likely cause less revolt.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> ___
> 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: Important Information about IETF 76 Meeting Registration

[Lawrence Rosen]

Paul Hoffman wrote:
> There are probably a dozen WGs in the IETF who have had this problem come 
> back and bite them on their collective backsides during protocol
development 
> or, unfortunately, after their protocols have deployed.

Can you give examples of how providing "company/organization affiliation"
has caused bites to the backside during protocol development/deployment?
Were the bites well-deserved?

/Larry





-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Paul
Hoffman
Sent: Monday, August 31, 2009 9:28 AM
To: Alexa Morris
Cc: IETF-Discussion
Subject: Re: Important Information about IETF 76 Meeting Registration

At 5:55 AM -0700 8/31/09, Alexa Morris wrote:
>The data collected consist solely of an individuals full name and
company/organization affiliation. We are not collecting email address
information on the e-blue sheets.

Please note that you are now also collecting information that *is not* on
the current blue sheets, namely "company/organization affiliation". I have
noted that some people I know who have signed a blue sheet before me have
used personal email addresses while (I assume) their badge lists their
actual "company/organization affiliation". As a person with multiple
company/organization affiliations, I sometimes change the email address I
put on the blue sheets to be the one most appropriate to the topic of the
WG.

It is a bad idea to have this experiment create combined blue sheets that
have data that differs depending on the collection method. There are
probably a dozen WGs in the IETF who have had this problem come back and
bite them on their collective backsides during protocol development or,
unfortunately, after their protocols have deployed.

Please strongly consider having the readers record exactly what the current
blue sheets record, or change the blue sheets to record what the readers are
recording for this meeting. The first of these two will most likely cause
less revolt.

--Paul Hoffman, Director
--VPN Consortium
___
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: Important Information about IETF 76 Meeting Registration

[Brian Rosen]

I like this thought quite a bit.

I see the RFID thing as being a good idea in concept, and we need to work
through how to use it most effectively.

In this specific case, I think we treat the tag as an identifier, and allow
the user to decide what the data associated with this identifier should be.

After all, you can write whatever you please on the blue sheets.

I personally would not have a problem if the name was immutable, but I could
see giving up on that.

Suppose there was a website where you could, either before, during, or after
the event, indicate, per session, what you want on the electronic blue
sheet.  The swipe was the token that enabled the content of the website data
to be copied.  Establish a time limit (5 days after the session maybe) to
freeze the content, do the mapping, and delete the website data.

Brian



On 8/31/09 12:56 PM, "Steve Crocker"  wrote:

> I won't be in Hiroshima and won't be able to participate nor will I be
> able to opt-out, so I don't have a personal stake in this and am
> commenting only as an interested observer.
> 
> As has been noted, this won't be an absolutely clean, seamless
> replacement of the blue sheets.  The list of possible downsides is
> already growing, e.g. privacy issues, inflexibility in choosing which
> email address to use for each working group, and I won't be surprised
> if the list grows a bit.  At the same time, the list of possible new
> capabilities is also growing, e.g. identifying the speaking at the
> microphone.
> 
> This sort of discussion is similar to other settings that are
> introducing electronic versions of previously manual processes, e.g.
> in the health care industry.  Let me offer a point of view and a
> suggestion.
> 
> Point of view: Rather than thinking of the RFID chips as serving to be
> simply a direct replacement of the blue sheets, take as a given that
> this will be a new and somewhat different technical foundation with
> some positives and some negatives.  The blue sheets also had positives
> and negatives, e.g. the cost and pain of storing them, the difficulty
> and cost of reading them, their legal status and retention policy,
> etc.  Look at the RFID chips from a fresh perspective, not solely as
> an automation of the blue sheets.
> 
> Suggestion: As noted above, similar issues apply in other settings.
> This community has an opportunity to tackle the interplay of
> technology and social policy issues that affect itself far more
> cogently and efficiently than most communities do.  Let's grasp the
> nettles and see if we can work through the issues in a sensible and
> rational way.  Do we need a privacy policy regarding the information
> collected?  If so, let's create one.  Do we need access controls on
> the information?  If so, let's create them.  Do we need an ability to
> edit information that's been collected if it's inaccurate?  If so,
> let's build it.  Do we need more flexibility in the information stored
> in the record, e.g. a distinct email address for each working group?
> If so, let's add it.
> 
> Steve
> 
> 
> 
> 
> 
> 
> 
> On Aug 31, 2009, at 12:27 PM, Paul Hoffman wrote:
> 
>> At 5:55 AM -0700 8/31/09, Alexa Morris wrote:
>>> The data collected consist solely of an individuals full name and
>>> company/organization affiliation. We are not collecting email
>>> address information on the e-blue sheets.
>> 
>> Please note that you are now also collecting information that *is
>> not* on the current blue sheets, namely "company/organization
>> affiliation". I have noted that some people I know who have signed a
>> blue sheet before me have used personal email addresses while (I
>> assume) their badge lists their actual "company/organization
>> affiliation". As a person with multiple company/organization
>> affiliations, I sometimes change the email address I put on the blue
>> sheets to be the one most appropriate to the topic of the WG.
>> 
>> It is a bad idea to have this experiment create combined blue sheets
>> that have data that differs depending on the collection method.
>> There are probably a dozen WGs in the IETF who have had this problem
>> come back and bite them on their collective backsides during
>> protocol development or, unfortunately, after their protocols have
>> deployed.
>> 
>> Please strongly consider having the readers record exactly what the
>> current blue sheets record, or change the blue sheets to record what
>> the readers are recording for this meeting. The first of these two
>> will most likely cause less revolt.
>> 
>> --Paul Hoffman, Director
>> --VPN Consortium
>> ___
>> 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


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

Re: Important Information about IETF 76 Meeting Registration

[Dave CROCKER]

Ole Jacobsen wrote:
The reason this is an EXPERIMENT is exactly to find out 
what/how/where/when information needs to be collected to

be useful for the IETF.



a reasonable goal.

nothing has been offered to indicate that this will do that.

there is a tendency in the IETF to confuse data with information.

merely doing something differently doesn't mean that it teaches anything useful.

this will produce some data -- and it's not entirely clear even what that will 
be -- but no indication of what analyses can be done with it to tell us anything 
useful.


d/
--

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Bob Braden]

Brian Rosen wrote:

Yes, I understand, this only applies to the Independent Submission stream.

We ask the IESG to review these documents, and that review is technical.


  
It seems important to begin a discussion with true facts, and the 
statement immediately above is false.

To quote Harald's words from RFC 3932:

  In March 2004, the IESG decided to make a major change in this review
  model.  The new review model will have the IESG take responsibility
  ONLY for checking for conflicts between the work of the IETF and the
  documents submitted; soliciting technical review is deemed to be the
  responsibility of the RFC Editor.  If an individual IESG member
  chooses to review the technical content of the document and finds
  issues, that member will communicate these issues to the RFC Editor,
  and they will be treated the same way as comments on the documents
  from other sources.

Sigh. I suppose this message is a derivative work.

Bob Braden'



___
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: Important Information about IETF 76 Meeting Registration

[Dave CROCKER]

Steve Crocker wrote:
Point of view: Rather than thinking of the RFID chips as serving to be 
simply a direct replacement of the blue sheets, take as a given that 
this will be a new and somewhat different technical foundation with some 
positives and some negatives.  The blue sheets also had positives and 
negatives, e.g. the cost and pain of storing them, the difficulty and 
cost of reading them, their legal status and retention policy, etc.  
Look at the RFID chips from a fresh perspective, not solely as an 
automation of the blue sheets.



The blue sheets have an established legal role.  There's no indication that 
there is a problem with the information that is obtained, for this role.


They are to be replaced by something that does not provide the same information.

What is the basis for believing they will satisfy the established job for the 
blue sheet?


What do we do if we find that they fail in this primary use?

d/
--

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

RE: Important Information about IETF 76 Meeting Registration

[Lawrence Rosen]

Paul Hoffman wrote:
> Sorry, I hope that others reading my message understood it better.

Paul, I still don't understand. The first sentence in your original email
was:

> Please note that you are now also collecting information that
> *is not* on the current blue sheets, namely 
> "company/organization affiliation".

I thought that was the "problem" to which you were alluding. And my question
remains: Is there any evidence that participants in IETF should not provide
their company/organization affiliation when they participate? Is there
something to hide?

I appreciate and respect the following comment, also in your email:

> As a person with multiple company/organization affiliations, I sometimes 
> change the email address I put on the blue sheets to be the one most 
> appropriate to the topic of the WG.

But that is not an excuse to provide no affiliation whatsoever, if you have
one (or many). 

Also, what is the "revolt" you are expecting in your email? I've reread this
entire thread about "IETF  76 Meeting Registration"  and can't figure out
who or what you find revolting about meeting registration data being
collected by IETF?

I'm sorry if I'm just being dense.

/Larry




-Original Message-
From: Paul Hoffman [mailto:paul.hoff...@vpnc.org] 
Sent: Monday, August 31, 2009 10:18 AM
To: Lawrence Rosen; 'Alexa Morris'
Cc: 'IETF-Discussion'
Subject: RE: Important Information about IETF 76 Meeting Registration

At 10:08 AM -0700 8/31/09, Lawrence Rosen wrote:
>Paul Hoffman wrote:
>> There are probably a dozen WGs in the IETF who have had this problem come
>> back and bite them on their collective backsides during protocol
>development
>> or, unfortunately, after their protocols have deployed.
>
>Can you give examples of how providing "company/organization affiliation"
>has caused bites to the backside during protocol development/deployment?
>Were the bites well-deserved?

Sorry, I hope that others reading my message understood it better. By "this
problem" I meant the bit just before what you quoted: "data that differs
depending on the collection method". A few examples would be IDNs collected
from DNS responses vs. user input, MIME headers that get "fixed" in various
transports, IP addresses that differ depending on which side of the NAT you
collect them, and so on.

--Paul Hoffman, Director
--VPN Consortium



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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:

Yes, I understand, this only applies to the Independent Submission  
stream.


We ask the IESG to review these documents, and that review is  
technical.


I don't think it is appropriate for an editor to make a judgment of  
whether
a technical note is, or is not appropriate to be included in a  
document.  I
think the presumption should be that it is appropriate, and the  
authors have

a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their  
ability to

make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF  
consensus call.




+1 , including the "IETF consensus call" part.


(...and to venture into the water under the consensus bridge part of  
the discussion...)


Joel wrote:

If I understand your note properly, your primary concern is that  
folks will think that Independent submission are IETF products.

This is a fair concern.
But the same could be said all our experimental and informational  
RFCs.  Should we insist that all experimental and informational RFC,  
even from IETF WGs, carry big warnings "THIS IS NOT AN IETF  
STANDARD." Repeated multiple times to make sure folks do not miss it?
(remember, Independent Submissions are never standards track  
documents.)


Wed try very hard to make it clear to folks that there is a  
difference between standards track documents and non-standards track  
documents. Independent Stream documents are not standards track  
documents.


And we fail miserably in those cases too.

Since I first started contributing in the IETF, I have on countless  
occasions had to explain to people who don't participate that some  
given RFC is not a standard. To most of the world, RFC==standard.  
Maybe putting "THIS IS NOT AN IETF STANDARD" all over the place would  
help, but I'm not sure about even that. Even worse, I have personally  
seen multiple instances of marketing people intentionally introducing  
FUD by talking about compliancy to some non standards-track RFC. (or  
even an ID that had been actively deprecated by the relevant working  
group.) Personally, I think our first mistake was using the same  
document name prefix for the different streams.


I am most particularly concerned about the case where a draft that was  
presented to a work group that selected not to publish it, and then  
later gets published in the independent stream. 
___

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

Re: Important Information about IETF 76 Meeting Registration

[Ole Jacobsen]

On Mon, 31 Aug 2009, Dave CROCKER wrote:

> 
> 
> Ole Jacobsen wrote:
> > The reason this is an EXPERIMENT is exactly to find out what/how/where/when
> > information needs to be collected to
> > be useful for the IETF.
> 
> 
> a reasonable goal.
> 
> nothing has been offered to indicate that this will do that.

Right, but of of course this hasn't stopped anyone from jumping on 
this and saying it's a bad idea etc.

> 
> there is a tendency in the IETF to confuse data with information.

This is a technology that is being offered by our HOST. The original 
idea expanded beyond the meeting, the card would work on trams, buses
and subways. For various reasons that isn't going to happen, but I 
think you will find a lot of "cool stuff" being demonstrated here,
let's just leave it at that for now.


> 
> merely doing something differently doesn't mean that it teaches anything
> useful.

There is no obligation to participate in the experiment or observe the 
cool use of the technology.

> 
> this will produce some data -- and it's not entirely clear even what that will
> be -- but no indication of what analyses can be done with it to tell us
> anything useful.

This isn't something the IAOC came up with as a policy or a bluesheet 
replacement, it is merely a technology demonstration. If all it leads 
to is some DISCUSSION about what/how we might use it in the future, 
then it will have achieved something.


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

Re: Important Information about IETF 76 Meeting Registration

[Ole Jacobsen]

> 
> The blue sheets have an established legal role.  There's no indication that
> there is a problem with the information that is obtained, for this role.
> 
> They are to be replaced by something that does not provide the same
> information.

NO, NO, and NO again. They aren't being replaced by anything, we are 
running an EXPERIMENT.

> 
> What is the basis for believing they will satisfy the established job for the
> blue sheet?

Nobody is talking about replacing the bluesheets with RFID cards.

> 
> What do we do if we find that they fail in this primary use?

Maybe I should get some sleep before I flame you for such blatant 
mis-information :-)


> 
> d/
> -- 
> 
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
> ___
> 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: Important Information about IETF 76 Meeting Registration

[Paul Hoffman]

At 9:59 AM -0700 8/31/09, Ole Jacobsen wrote:
>The reason this is an EXPERIMENT is exactly to find out
>what/how/where/when information needs to be collected to
>be useful for the IETF.

No need to go all-caps on me, dude. :-) I used that word in my response in the 
way it was intended.

>I am going to suggest that we, with the help of WIDE, start a
>discussion list where some of these details can be ironed out.

Excellent!

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

Joel M. Halpern wrote:
And given that these are Independent Submissions, they aren't supposed 
to be subject to community review.


Given this fact, why is there pushback on the idea that we would 
prominently mark the documents to indicate that they have not been 
subjected to community review? It seems like the kind of thing that is 
of extreme relevance to the reader.


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 10:30 -0700 Bob Braden
 wrote:

> Your argument seems to me to be the latest version of the
> 30-year old discussion about whether all RFCs are standards.
>...

Not quite 30 years, because it took us a while to start using
terms like "standard", and even longer to get the IETF into
existence into existence.  But, as part of that long argument it
is worth reminding those those think that non-standards RFCs
should be published in a different series that the IETF, after
it was created, decided to publish its standards-track documents
in the RFC Series.  It isn't as if the other documents were
somehow grafted on -- it is the IETF standards-track materials
that were grafted on to what was previously an
almost-all-independent-submissions situation (there were a few
IANA and IAB documents in the series too).   I know you know
that, but others seem to forget, and to do so fairly regularly.

The Headers & Boilerplate document is supposed to help with the
identification situation by explicitly identifying the streams
and the role of each.  If those warnings are not sufficient, it
is not clear to me that boilerplate notes, of the variety that
RFC 3932 has been read as calling for, will help much.

>...
> And even documents in the
> IETF stream (which includes
> individual submission, by the way) very considerably in
> quality and safety.

Hmm.  I have a counter-proposal to those IESG members who
believe in their right to include negative-sounding comments
about independent submission documents without explaining the
reasons for their objections (or, often, even the objections
themselves) or taking responsibility for those objections by
signing  their names or at least putting explicit information
into the tracker.  

The current RFC Editorial Board contains significant expertise
and does review the Independent Submission documents for
technical adequacy.  If IESG membership is a special
qualification, it is worth noting that the Editorial Board's
membership includes several former ADs and even two former IETF
Chairs.  

How about we start Editorial Board review of all IETF Stream
documents arriving from the IESG and, where the Editorial Board
deems it appropriate, attaches notes that reflect on the quality
and/or safety of the ideas suggested.   I imagine that the
Editorial Board would at least be willing to be specific about
objections and to sign specific notes, unlike, at times, the
IESG.

Let the second-guessing begin!

No, not really it is a terrible idea and I can't imagine
most Editorial Board members having time, but perhaps it makes
the point.

john



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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

Joel M. Halpern wrote:
Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.


And I agree that there is an issue of the community not distinguishing 
among standards-track, informational, and experimental documents. But 
that's a separable problem that is, in my opinion, of much smaller 
consequence.


I assert that the distinction between these classes of documents is 
much, much smaller than the distinction between IETF-reviewed documents 
and independent stream documents.



Remember also that in terms of the text being a recommendation, this 
is not a change in practice.  This is the practice we have had for 
more than the last 15 years.  If, for Independent Submissions, it is 
that big a problem, I would expect ot have heard of it.


Perhaps I'm just unclear on the frequency of independent submissions -- 
but can you find me an RFC that came from a source other than the IETF 
that does not include a prominent note indicating that fact?


I'm under the distinct impression that historical practice tagged all 
(or almost all) such documents with a prominent note. The proposed 
procedure tries to make this an extreme exception, not the norm.


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

If every document needs this marking, then that is a matter for headers 
and boilerplates.  I can understand arguing about how we mark documents.
If our headers and boilerplate are not sufficient, then we should 
renegotiate them.  I personally think that they are about as good as we 
can get.


But the IESG review is for checking for conflicts with IETF work.  It is 
for reporting such conflicts.  It is not a general review for "does the 
IETF like this work."


Yours,
Joel

Adam Roach wrote:

Joel M. Halpern wrote:
And given that these are Independent Submissions, they aren't supposed 
to be subject to community review.


Given this fact, why is there pushback on the idea that we would 
prominently mark the documents to indicate that they have not been 
subjected to community review? It seems like the kind of thing that is 
of extreme relevance to the reader.


/a


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 13:20 -0500 Adam Roach
 wrote:

> Joel M. Halpern wrote:
>> And given that these are Independent Submissions, they aren't
>> supposed  to be subject to community review.
> 
> Given this fact, why is there pushback on the idea that we
> would prominently mark the documents to indicate that they
> have not been subjected to community review? It seems like the
> kind of thing that is of extreme relevance to the reader.

Because the statement "this has not been subjected to community
review" is often factually incorrect and because there are
multiple communities out there.  Some of these documents are
actually more intensively reviewed, by more experts, than some
things the IETF puts on the standards track.

If the IESG were inclined to quiz the RFC Editor as to what
review had occurred and then jointly identify each document,
including IETF Stream documents, with the precise type of review
that had occurred, we would be having a different discussion.
Headers and Boilerplates provides for some of that type of
annotation without requiring any IESG notes.

Alternately, if the IESG wanted to subject every Independent
Submission document to IETF Last Call, review the results of
that Last Call, and on that basis, sometimes generate a note and
subject it to IETF Last Call, I'd have no problem at all
introducing a section into Independent Submission Track RFCs
containing the IETF's opinion of the document, identified as
such.  For lots of good reasons, I don't expect that to happen
and do not consider vague text that may be false (e.g., claiming
that no review within the IETF community occurred when, in fact,
it might have) to be helpful in this regard.  I also believe
that having the IESG tell lies that can easily be tested and
exposed as such does not contribute positively to the reputation
of the IETF.

john

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

Re: Important Information about IETF 76 Meeting Registration

[Dave CROCKER]

Ole Jacobsen wrote:
This isn't something the IAOC came up with as a policy or a bluesheet 
replacement, it is merely a technology demonstration. If all it leads 
to is some DISCUSSION about what/how we might use it in the future, 
then it will have achieved something.



oh.  we'll still have the blue sheets?

as a parallel exercise, it sounds dandy.

d/

--

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

If we really feel that the current approach does not make non-standards 
clear enough, then we should address that for all experimental or 
informational documents.  It is basically unrelated to the Independent 
Stream issue.



With regard to documents that are alternatives to existing IETF work, 
the RFC Editor has always required, as is appropriate for any academic 
work, a description of the relationship to existing work.  Reviewers who 
know the area and work are selected.  Thus, the document, in its text, 
is expected to explain why it is different from the standard.  Which 
also requires it to be clear that it is different from the standard.


Handling such discrepancies in the document is both clearer, more 
effective, and fairer to the authors than trying to solve the problem by 
slapping a note on the front of the document.


And before someone says "but the ISE is not requrie to do that", note 
that the ISE is required to maintain the quality of the stream.  That 
includes ensuring that there is suitable description of the relationship 
to existing work.  So not only is this the current practice, but it is 
part of what we can reasonably expect.


I guess this relates to a lot of my problem with this whole "mandatory 
IESG notes" approach.  If there is a real problem with the document, 
then the document should address the problem.  If the IESG does not like 
the light the document puts the IETF into, then we probably made a 
mistake earlier, and this is not the place to fix it.
And given that these are Independent Submissions, they aren't supposed 
to be subject to community review.


Yours,
Joel

Ben Campbell wrote:


On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:

Yes, I understand, this only applies to the Independent Submission 
stream.


We ask the IESG to review these documents, and that review is technical.

I don't think it is appropriate for an editor to make a judgment of 
whether
a technical note is, or is not appropriate to be included in a 
document.  I
think the presumption should be that it is appropriate, and the 
authors have

a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their ability to
make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF consensus 
call.




+1 , including the "IETF consensus call" part.


(...and to venture into the water under the consensus bridge part of the 
discussion...)


Joel wrote:

If I understand your note properly, your primary concern is that folks 
will think that Independent submission are IETF products.

This is a fair concern.
But the same could be said all our experimental and informational 
RFCs.  Should we insist that all experimental and informational RFC, 
even from IETF WGs, carry big warnings "THIS IS NOT AN IETF STANDARD." 
Repeated multiple times to make sure folks do not miss it?

(remember, Independent Submissions are never standards track documents.)

Wed try very hard to make it clear to folks that there is a difference 
between standards track documents and non-standards track documents. 
Independent Stream documents are not standards track documents.


And we fail miserably in those cases too.

Since I first started contributing in the IETF, I have on countless 
occasions had to explain to people who don't participate that some given 
RFC is not a standard. To most of the world, RFC==standard. Maybe 
putting "THIS IS NOT AN IETF STANDARD" all over the place would help, 
but I'm not sure about even that. Even worse, I have personally seen 
multiple instances of marketing people intentionally introducing FUD by 
talking about compliancy to some non standards-track RFC. (or even an ID 
that had been actively deprecated by the relevant working group.) 
Personally, I think our first mistake was using the same document name 
prefix for the different streams.


I am most particularly concerned about the case where a draft that was 
presented to a work group that selected not to publish it, and then 
later gets published in the independent 
stream.___

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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Bob Braden]

Adam Roach wrote:



While the presence of alternate streams of publication doesn't bother 
me, I think they need to be automatically and prominently marked as 
being something other than an IETF document.


In particular, when a user accesses a document at a url of the form 
, there is going to be a strong 
presumption on their part that the document was produced by the IETF. 
In the cases that this presumption is incorrect, it seems tantamount 
to deception to tuck the distinction between IETF and non-IETF 
documents away in an obscure header field.


/a


Your argument seems to me to be the latest version of the 30-year old 
discussion about whether all
RFCs are standards.   They are not.  And even documents in the IETF 
stream (which includes

individual submission, by the way) very considerably in quality and safety.

Bob Braden



Jari Arkko wrote:

I would like to get some further input from the community on this draft.

But first some background. This draft was brought to a second last 
call in June because several IESG members felt uncomfortable with the 
IESG notes being used only in exceptional circumstances. I asked Russ 
to prepare the -07 version. This version allowed notes to be used at 
the IESG's discretion and suggested that the linkage (or lack 
thereof) to IETF work would typically be explained in the note. This 
version was taken to the second last call.


While the number of comments we received was small, after the last 
call was over I determined that the consensus was against this 
change. As a result, I asked Russ to prepare the -08 version. This 
version goes back to the "exceptional" wording from -06, but 
incorporated a number of editorial corrections that had been made in 
interim. I also took the draft back to the IESG telechat last week. 
The IESG was not extremely pleased with the new version, but my 
understanding is that they were willing to accept the changes. 
However, a new issue was brought up: one of the changes that Russ and 
I felt was editorial highlighted the fact that the document makes the 
IESG notes a recommendation to the RFC Editor, not something that 
would automatically always be applied to the published RFC. Some IESG 
members were concerned about this, and preferred the latter.


And now back to the input that I wanted to hear. I would like to get 
a sense from the list whether you prefer (a) that any exceptional 
IESG note is just a recommendation to the RFC Editor or (b) something 
that is always applied to the published RFC. Please reply before the 
next IESG meeting on September 10. Some e-mails on this topic have 
already been sent in the Last Call thread -- I have seen those and 
there is no need to resend.


(For the record my own slight preference is b. But I have to say that 
I think the document has been ready to be shipped from version -06, 
and its unfortunate that we're not there yet, particularly since this 
document is holding up the implementation of the new headers and 
boilerplates system for independent submissions, IRTF submissions and 
IETF submissions. I will exhaust all possible means of getting this 
approved in the next meeting, as soon as I know what the community 
opinion is.)


Jari Arkko

___
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



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

RE: Important Information about IETF 76 Meeting Registration

[Paul Hoffman]

At 10:08 AM -0700 8/31/09, Lawrence Rosen wrote:
>Paul Hoffman wrote:
>> There are probably a dozen WGs in the IETF who have had this problem come
>> back and bite them on their collective backsides during protocol
>development
>> or, unfortunately, after their protocols have deployed.
>
>Can you give examples of how providing "company/organization affiliation"
>has caused bites to the backside during protocol development/deployment?
>Were the bites well-deserved?

Sorry, I hope that others reading my message understood it better. By "this 
problem" I meant the bit just before what you quoted: "data that differs 
depending on the collection method". A few examples would be IDNs collected 
from DNS responses vs. user input, MIME headers that get "fixed" in various 
transports, IP addresses that differ depending on which side of the NAT you 
collect them, and so on.

--Paul Hoffman, Director
--VPN Consortium
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Dave CROCKER]

Joel M. Halpern wrote:

If every document needs this marking, ...



If this line of discussion needs to happen, it needs to happen on a separate
thread, because I believe it has nothing to do with the current text, proposal, 
or concern.


As noted, it is opening a very old -- and I believe very different -- basic 
concern.

The current question is about IESG Notes.  We ought to restrict postings on this 
thread to that question.


d/

--

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Jari Arkko]

Dave,

The current question is about IESG Notes.  We ought to restrict 
postings on this thread to that question.


Yes.

As always, before a draft is actually approved we appreciate getting all 
kinds of feedback on it. Particularly if there's a serious problem 
somewhere. Of course, when a Last Call period is over, we do not re-open 
a document lightly even if it hasn't been approved yet.


However, in this case: if you have a general comment on 3932bis, please 
post to the Last Call thread. If you want to answer my specific question 
about the optional/mandatory nature of the IESG note, please respond to 
this thread. My current plan is NOT to reopen other aspects of the 
document, though I understand that some of them may have to be discussed 
to provide context for the specific question.


Jari

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Adam Roach]

Jari Arkko wrote:
However, in this case: if you have a general comment on 3932bis, 
please post to the Last Call thread. If you want to answer my specific 
question about the optional/mandatory nature of the IESG note, please 
respond to this thread.


So, to be clear, the question you have raised has to do with the 
difference between:


   "The IESG may choose to add an IESG note to an Independent
   Submission..."


and:

   "The IESG may choose to request the addition of an IESG note to an
   Independent Submission..."



Right? This has nothing to do with the text:

   "In exceptional cases, when the relationship of the document to the
   IETF standards process might be unclear..." ?



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

Re: Important Information about IETF 76 Meeting Registration

[SM]

At 09:56 31-08-2009, Steve Crocker wrote:

This sort of discussion is similar to other settings that are
introducing electronic versions of previously manual processes, e.g.
in the health care industry.  Let me offer a point of view and a
suggestion.


[snip]


Suggestion: As noted above, similar issues apply in other settings.
This community has an opportunity to tackle the interplay of
technology and social policy issues that affect itself far more
cogently and efficiently than most communities do.  Let's grasp the
nettles and see if we can work through the issues in a sensible and
rational way.  Do we need a privacy policy regarding the information
collected?  If so, let's create one.  Do we need access controls on
the information?  If so, let's create them.  Do we need an ability to
edit information that's been collected if it's inaccurate?  If so,
let's build it.  Do we need more flexibility in the information stored
in the record, e.g. a distinct email address for each working group?
If so, let's add it.


I think that the above covers the larger issue.  This is not the 
usual IETF experiment.  It is a social experiment.


There was a time when the IETF was a trend-setter.  We can take the 
view where the IETF only "publishes" technical specifications and it 
cannot influence how the technology is used.  Or we can take this 
opportunity to understand the social impact of the technologies.  We 
have all heard the argument "it's only the 'bad' people who should 
have something to fear about".


The bluesheet is a piece of paper which is used as an attendance 
sheet for Working Group sessions.  It would take some work and time 
to aggregate the information or do data mining on it.  That's one 
advantage (or disadvantage) of paper records.  With the advent of 
information technology, it takes less time to aggregate information 
stored in digital form.  The e-bluesheet system uses a "tag-reader" 
where we still have a manual process to "sign" (or avoid signing) the 
attendance sheet.


The following is unrelated to the existing e-bluesheet experiment.

Let's go one step further.  Imagine the entire floor space 
criss-crossed by scanners that can pick a RFID tag 
automatically.  That is, we can pinpoint the participants in a room 
or hallway and collect information about "social clusters" within the 
different areas.  We could identify where the I* bodies are and who 
are interacting with these people.  This is not your usual (Web 2.0) 
social network where you list your friends.  It's more than that as 
we do not have to ask you to list your interests.  We can get that 
information from our "tracking" system.  We can determine who is 
talking to NomCom.


If you want to create the above as an experiment, separate the "tag" 
IDs from the personal information about the participant.  Correlate 
the information in real-time to show the participants what can be 
done and destroy the "mapping" immediately after the end of the 
meeting.  I don't have to tell you not to use the Internet to publish 
the real-time information as you already know what will happen.


We tend to use the anonymity of the crowd as a protection.  That is 
no longer true with the technologies that are available nowadays.  We 
can identify "individuals of interest" and access information about 
them easily.


Regards,
-sm 


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Andrew G. Malis]

+1 to Dave's suggestion below regarding the name of the draft, as well
as Joel's and John's responses to Jari's original question (i.e.,
retain existing practice regarding IESG notes).

Cheers,
Andy

On Mon, Aug 31, 2009 at 12:27 PM, Dave CROCKER wrote:
>
>
> Joel M. Halpern wrote:
>>
>>    The documented rules and practice has long been that with regard to
>> Independent Submissions the IESG notes are a request / recommendation to the
>> RFC Editor (soon to be ISE), not a statement of what will be included in the
>> result.
>
> ...
>>
>> Based on having seen a number of IESG notes, and reading the resulting
>> text and its inherent tone, I would strongly prefer that IESG notes be an
>> exception.
>
> ...
>>
>> Thus, I strongly prefer (a).   I prefer that such notes be rare, and that
>> they remain recommendations to the ISE.
>
>
> +1.
>
> It might help folks to understand the independent relationship, between the
> IETF/IESG and these other RFC streams, if the title of this draft were
> changed from "Handling of" to "Assisting with".
>
> d/
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Important Information about IETF 76 Meeting Registration

[Joel Jaeggli]

SM wrote:

> I think that the above covers the larger issue.  This is not the usual
> IETF experiment.  It is a social experiment.

I'm not sure what you'd call the ipv6 hour other than a social experiment...

> There was a time when the IETF was a trend-setter.

The ietf is an organizational framework through which work is organized
and documents are published. The attendees bring the ideas and do the work.

>  We can take the view
> where the IETF only "publishes" technical specifications and it cannot
> influence how the technology is used. 

If I bring work to the IETF, it's either because I intend to benefit
from it or I intend that someone else benefit from it, while there are
other probably less noble intentions that are played out here I don't
believe that there are many people that would dispute that proposition.

> Or we can take this opportunity
> to understand the social impact of the technologies. 

There's an epistemological fallacy here since the social impact can be
know a posteri but can only be speculated on by those of us who live in
the present.

I for one am more interested some simple questions:

will it work?

what is the workflow like?

Can it be integrated into the remote/realtime participation technologies
  in fashion that has some utility?


> ___
> 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[SM]

Hi Jari,
At 06:29 31-08-2009, Jari Arkko wrote:
And now back to the input that I wanted to hear. I would like to get 
a sense from the list whether you prefer (a) that any exceptional 
IESG note is just a recommendation to the RFC Editor or (b) 
something that is always applied to the published RFC. Please reply 
before the next IESG meeting on September 10. Some e-mails on this 
topic have already been sent in the Last Call thread -- I have seen 
those and there is no need to resend.


I prefer option (a); the IESG note is just a recommendation to the RFC Editor.

If the IESG wants the IESG Note to always be applied, it is 
determining the RFC Editor policy and that's the role of the IAB 
according to Section 5.


Regards,
-sm 


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

RE: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

[Ahmad Muhanna]

Hi, Ben,
Sorry for the late reply, hope to close on all comments; please see
inline.

> -Original Message-
> 
> [...]
> 
> > [PART-II]
> >>
> >> Nits/editorial comments:
> >>
> >> -- General: 
> 
> I understand that, and I hope I didn't come off too critical. 
> I know that it is very hard to make a draft that is both 
> readable and correct, particularly when you have so many use 
> cases that require different application behavior.
[Ahmad]
Not at all. I thank you much for the thorough review and comments!

> 
> >>
> >> -- Same paragraph, last sentence:
> >>
> >> Do you mean "user" or "mobile node"?
> >
> > [Ahmad]
> > I meant the user, because if the reason, administrative, then it 
> > probably requires the user intervention.
> 
> Interesting. I assume there are cases where a typical mobile 
> node would just quietly reestablish the binding. I gather you 
> expect cases where it can't do so without some (possibly 
> reconfiguration) effort on the user's part, right? It's worth 
> thinking about whether there is some guidance you can give to 
> implementors here. (I'm not sure there is--just something to 
> think about.)
[Ahmad]
Probably we can allow it to be applicable to the user and mobile node.
What about if we just state "This mechanism enables the user or the
mobile node to react .. "
 
> >
> >>
> >> -- S3.4.1, first paragraph, first sentence:
> >>
> >> Unclear sentence: What is doing the "hosting"? The LMA, 
> the MAG, or 
> >> the BRI message? I think you mean the MAG, but the 
> sentence structure 
> >> is ambiguous.
> > [Ahmad]
> > What about the following?
> >
> > "
> >   The local mobility anchor may send a Binding Revocation Indication
> >   message with the appropriate revocation trigger value to 
> the mobile
> >   access gateway which hosts a specific PMIPv6 binding to indicate 
> > that
> >   the mobile node binding has been terminated and the mobile access 
> > gateway
> >   can clean up the applicable resources.
> 
> s/which/that, but otherwise I think it works.

[Ahmad]
Ok.

> 
> >
> >>
> >> -S 7.1, first paragraph: "node, initiator, constructs"
> >>
> >> Confusing sentence structure. Is "initiator" a name for 
> the sending 
> >> mobility node? If so, it would help to use it later
> > [Ahmad]
> > Sure. Will remove it.
> 
> Actually, I meant to propose you keep it, so that you could 
> simplify later sentences. For example, you could substitute 
> "The initiatior"  
> for "The mobility node that sends a Binding Revocation 
> Indication message".
[Ahmad]
Ok.

> 
> >
> >> (the next paragraph uses the same structure again.)
> >>
> >> -- 2nd paragraph: "In the BRI message, the initiator MUST set the 
> >> Sequence Number field to the next sequence number available for 
> >> Binding Revocation"
> >>
> >> Does this conflict with the section 6.1 statement that it 
> "could be 
> >> random"
> > [Ahmad]
> > I do not see a conflict with sec 6.1. If the sequence random is set 
> > using a random generator, then the next sequence number is 
> random too.
> 
> I think there is some danger that an implementor will be 
> confused by the words "sequence" and "next" for something 
> that is not necessarily sequential. I gather you don't care 
> how the implementation selects this number as long as there 
> are no collisions, right? 
[Ahmad]
Yes.

> It might be helpful to have a 
> sentence or two that say that--as "it could be random" 
> doesn't fully explain that you expect this to be local policy.

[Ahmad]
Sure.

> 
> More importantly, this implies a requirement that the 
> responder MUST NOT attempt to infer meaning from the sequence 
> numbers--for example, out-of-sequence numbers are 
> meaningless. 
[Ahmad]
True. The use of the sequence number is to enable the initiator to match
the BRA with the outstanding associated BRI. Since the chance of having
more than one outstanding BRI, we MUST make sure that there is no
collision.

> Also, if an implementation chose to use 
> sequential values, does it have to worry about rollovers? 
[Ahmad]
No.
 
> Does the potential guess-ability of a sequence number have 
> security implications?

[Ahmad]
Not at all. Packet must pass IPsec authentication first.
> 
> >
> >>
> >> -- Same Paragraph: "Since sending Binding Revocation Indication 
> >> message is not done on a regular basis, a 16 bit sequence number 
> >> field is large enough to allow the initiator to match the Binding 
> >> Revocation Acknowledgement to the outstanding Binding Revocation 
> >> Indication with Acknowledge
> >> (A) bit set using the sequence number field only."
> >>
> >> Sentence is hard to follow. I suggest separating the idea that you 
> >> can match BRAs to BRIs with a 16 bit sequence number from the idea 
> >> that you only get a BRA if the BRI had it's A bit set.
> >>
> > [Ahmad]
> > Sure. What about the following:
> >
> > "Since sending Binding Revocation Indication message is not 
> done on a 
> > regular basis, a 16 bit sequence number field is large 
> enough to allo

RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10

[Ahmad Muhanna]

Hi Ben,
Will address and comment on open ones. Please see inline.

Regards,
Ahmad

> -Original Message-
>
> Subject: Re: [PART-I] Gen-ART LC and Telechat Review of 
> draft-ietf-mext-binding-revocation-10
> 
> Hi Ahmad,
> 
> Let me comment on the security issues at a high level up 
> front, since I think I can tie together responses to several 
> of your comments below. More specific comments imbedded:
> 
> I think the email from Jari helped clarify things for me to a 
> point that I can make my concerns a little more precise. You 
> clarify further down that mobile nodes are _never_ allowed to 
> revoke bindings that weren't associated with them in the 
> first place. This actually addresses a lot of my concerns, 
> and I think it is fundamental enough to be reiterated in the 
> SecCons section.
[Ahmad]
Sure, we can make that clear.

> 
> I still have concerns about the use of IPSec, though, as 
> without IPSec of some other form of authentication, an 
> attacker could conceivably impersonate the node that bindings 
> were associated with. This is particularly bothersome in use 
> cases that allow a node to revoke bindings without having to 
> know the details of each individual binding, such as the 
> G-bit, or an included NAI of the form "@example.com".
> 
> I'm not saying that this draft needs to make IPSec into a 
> MUST. 
[Ahmad]
If it comes to me, I am comfortably fine with that:)

> But it is appropriate for it to point out that if you 
> _don't_ use it, bad things could happen. (See my comment on 
> that point further down.)
> 
> It may be that using MIPv6 without IPSec is just as bad 
> without BRI as with it--in which case it's fair to say that 
> any attacks enabled by not using IPSec with BRI are no worse 
> than using the base technologies without BRI. (Such 
> statements are easier to believe with some discussion to 
> support them, though :-) )

[Ahmad]
When IPsec is used, the only issue that we identified that needs special
attention was the Global Revocation with Revocation Trigger value
"Per-Peer Policy" when sent from the MAG [because it deletes all
sessions between the two peers]. Although, some people still disagreed
that there is no great risk in there and no special treatment should
take place. At any rate, since this message coming from a peer in the
visited network, we wanted the home network to have the upper hand and
be able to give specific privileges to peers in the different visited
networks, i.e., MAGs. What this means? the ability to establish an IPsec
SA between the MAG and the LMA does not give the MAG the automatic
privilege to use Global Revocation with Revocation Trigger value of
"per-Peer Policy". That why we required authorization.

> 
> More inline:
> 
> On Aug 27, 2009, at 1:32 PM, Ahmad Muhanna wrote:
> 
> > Hi, Ben,
> >
> >>>
>  -Original Message-
> 
>  Summary: This draft is on the right track, but there are
> >> open issues.
>  Additionally, I have a number of editorial comments.
> 
>  Major issues:
> 
>  -- I think the security considerations need quite a bit of
> >> work. In
>  particular, there is very little guidance on authorization for 
>  sending BRI messages. This seem to me have utility for DoS
> >> attacks,
>  particularly with the G bit set.
>  There is mention of reusing existing security associations
> >> if IPSec
>  is used--but no mention of what to do if IPSec is not used.
> >>> [Ahmad]
> >>> Binding Revocation is used between two peers to 
> revoke/terminate a 
> >>> mobility session(s) that have been created using an IPv6 mobility 
> >>> protocol signaling (Client Mobile IPv6 or Proxy MIP6). 
> RFC3775 and 
> >>> RFC5213, which are the main protocols targeted by this
> >> specification,
> >>> specify that "IPsec SHOULD" be used. On the other hand, 
> there is NO 
> >>> other standard track specification which specify other security 
> >>> mechanisms to secure the IPv6 mobility signaling.
> >> Therefore, Binding
> >>> Revocation specification assumes the use of whatever security 
> >>> mechanism that currently available to secure the IPv6 mobility 
> >>> signaling.
> >>
> >> I think there are still a couple of issues here. First, Since the 
> >> underlying RFCs only specify IPSec at SHOULD strength, this draft 
> >> needs to discuss the consequences of not using it for BRI. 
> Depending 
> >> on those consequences, it might be enough to just warn 
> implementors 
> >> that, if you don't use IPSec, certain bad things can happen.
> > [Ahmad]
> > It is NOT expected that BRI/BRA will use a different security 
> > mechanism than what is being used for securing IPv6 mobility 
> > signaling.
> > Therefore,
> > in order to alert implementors of the danger if IPsec is NOT used, 
> > IMO, that needs to be discussed in related IPv6 mobility 
> > specifications, e.g., RFC3775 and RFC5213, which is already 
> there. On 
> > the other hand, it is very difficult to anticipate the criteria of 

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[John C Klensin]

--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
 wrote:

> I would like to get some further input from the community on
> this draft.
>...
> And now back to the input that I wanted to hear. I would like
> to get a sense from the list whether you prefer (a) that any
> exceptional IESG note is just a recommendation to the RFC
> Editor or (b) something that is always applied to the
> published RFC. Please reply before the next IESG meeting on
> September 10. Some e-mails on this topic have already been
> sent in the Last Call thread -- I have seen those and there is
> no need to resend.

Jari,

I've said this before, but not during the recent Last Call, so,
to get a note on the record...

Any IESG note or comment, exceptional or otherwise, has always
("always" == "since the IESG was created and long before it
started writing notes") been an recommendation to the RFC
Editor.  That position is reflected in long-term precedent, in
RFC 4844, and in the new RFC Editor Model document.   Under the
new model, should the RFC Editor decide to not accept a proposed
IESG note, the IESG can raise the issue with the RSE and, if
necessary, with the IAB, presumably causing a wider community
review of the proposed note itself.  That level of protection
(which goes beyond that historically available) should be both
necessary and sufficient for the IESG's purposes.

Procedurally, should the IESG wish to change that position, I
believe it would require the approval of the IAB (because it
changes the RFC Editor role and relationship) and a review of
the Headers and Boilerplates document, the RFC Editor Model
document, and perhaps some of the statements of work associated
with the new RFC Editor contracts and appointments.  I have
reason to believe that the IAB would insist on community review
before granting such approval, so trying to change things in
this area at this late date is not consistent with rapid
progress and may be inconsistent with having a fully-functional
RFC Editor function in place at the beginning of January.

More broadly, as the community has discussed extensively, the
IESG should not have the right to deprecate or denigrate the
contents of any document from another stream without broad
community consensus.  Nothing in any community-approved IETF
procedural document from RFC 2026 forward gives the IESG such
authority (or authority for doing much of anything else other
than steering/managing) without community approval and
consensus.   Even the claim in the original version of 3932 that
a document has not been reviewed in the IETF is inappropriate
unless such review has actually not occurred (whether or not
consensus was reached).

So I believe that your clarifying change was, in fact, editorial
and that it should remain.

>...

regards,
  john

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

RE: Important Information about IETF 76 Meeting Registration

[Tony Hain]

I agree with Steve that we should look at the issues that arise, then deal
with each in turn. Let me say up front that I am sure our hosts are offering
this technology demo with an honorable intent, so we should in turn have a
respectful discussion of the issues. 

I suspect the announced placement and handling of readers will have a
significant impact on the participation rate. I was a speaker at an event a
few years back that used an rfid reader system, where the readers tracked
entry and exit times from each meeting room, as well as harvesting the badge
proximity sensors which tracked each other and relative position in the
building. I am not suggesting the offered demo has these capabilities, just
noting that they do exist. While the announced functionality of the old
non-IETF demo was to act as an e-business card for information sharing
between the participants, as well as verification of payment for access to
each session, the organizer had a much different data mining intent which
was clear to those who knew of his other sleazy dealings. Somehow my reader
was always forgotten in my room, but since I was a speaker they had to let
me in anyway. At the end of the day, knowing the distance between people
along with the period of time and where in the facility they were provides a
lot of information to people with nefarious intent. 

Clearly from the discussion about aiding remote participation there is an
intent to have a reader at each mic, and something related to the bluesheet
clipboard. If it is clear that those are the only readers, and the badges
don't track each other there is likely to be a higher level of participation
than there would be for an unstated set, or a full mesh tracking system. One
issue that comes to mind is the distance between the reader and badge for
this to work. Physical contact or a swipe would make the mic line awkward
and highlight who was participating and not, while anything more than about
25cm would unintentionally register the person who stepped in the door to
look for someone just as the clipboard passed by. I don't know how much
control they have over reader sensitivity, but the placement issue should be
resolved and announced well in advance of the meeting.

As far as data & retention policy, I would suggest that the only data
associated directly with the tag be the name, then use an out-of-band means
to allow each person to provide whatever other information they are willing
to share, including email aliases for each working group. If one use is
bluesheet emulation, then the backend can do the correlation to create the
logical equivalent. If another use is real-time mic announcement, the data
associated with that should be destroyed as soon as the wg minute taker has
published. I am sure other functionality is possible, but each should be
considered in terms of data retention and possible misuse when the access
controls break down (as they will at some point).

Tony


Steve Crocker wrote:
> I won't be in Hiroshima and won't be able to participate nor will I be
> able to opt-out, so I don't have a personal stake in this and am
> commenting only as an interested observer.
> 
> As has been noted, this won't be an absolutely clean, seamless
> replacement of the blue sheets.  The list of possible downsides is
> already growing, e.g. privacy issues, inflexibility in choosing which
> email address to use for each working group, and I won't be surprised
> if the list grows a bit.  At the same time, the list of possible new
> capabilities is also growing, e.g. identifying the speaking at the
> microphone.
> 
> This sort of discussion is similar to other settings that are
> introducing electronic versions of previously manual processes, e.g.
> in the health care industry.  Let me offer a point of view and a
> suggestion.
> 
> Point of view: Rather than thinking of the RFID chips as serving to be
> simply a direct replacement of the blue sheets, take as a given that
> this will be a new and somewhat different technical foundation with
> some positives and some negatives.  The blue sheets also had positives
> and negatives, e.g. the cost and pain of storing them, the difficulty
> and cost of reading them, their legal status and retention policy,
> etc.  Look at the RFID chips from a fresh perspective, not solely as
> an automation of the blue sheets.
> 
> Suggestion: As noted above, similar issues apply in other settings.
> This community has an opportunity to tackle the interplay of
> technology and social policy issues that affect itself far more
> cogently and efficiently than most communities do.  Let's grasp the
> nettles and see if we can work through the issues in a sensible and
> rational way.  Do we need a privacy policy regarding the information
> collected?  If so, let's create one.  Do we need access controls on
> the information?  If so, let's create them.  Do we need an ability to
> edit information that's been collected if it's inaccurate?  If so,
> let's build

Nomcom 2009-10: Reminder Call for Nominations, Local Office hours, Nominee Questionnaires available

[Mary Barnes]

Hi all,

This email covers 3 topics:
1) Reminder: Call for Nominations
2) New: Local Office Hours
3) New: Questionnaires available for nominees 

Best Regards, 
Mary Barnes
nomcom-ch...@ietf.org
mary.h.bar...@gmail.com
mary.bar...@nortel.com


===
1) Call for Nominations

The nomination period ends in less than 3 weeks on Sept. 18th, 2009. We
appreciate the folks that have taken the time to make nominations thus
far. But, we do need more nominations. Please use the online tool to
nominate - it's easy and secure:
https://wiki.tools.ietf.org/group/nomcom/09/nominate

Details on the open positions, as well as other details and options for
making nominations are available on the Nomcom homepage:
https://wiki.tools.ietf.org/group/nomcom/09/

Please consider that the sooner you make the nominations, the more time
your nominee(s) will have to complete the necessary questionnaire (item 3
below).  As well, please consider nominating more than one person for a
particular position. You will have the opportunity to provide additional
feedback later and it's important to consider that not all nominees will
be able to accept the nomination. 


2) Local office hours
---

In order to facilitate additional feedback, the Nomcom is planning to
make themselves available for office areas at various geographic locations
for 3 weeks in September, starting on the 8th. 

Below please find the list of locations where Nomcom members will be
available for these f2f meetings . Unless dates are identified below, the
Nomcom member is generally available for part of the day during the weeks
of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than
English in which the Nomcom member is fluent are identfied.  

Please contact a Nomcom member in a specific geographic location to
arrange a convenient meeting time and place. Most Nomcom members are
flexible as to meeting locations - i.e., we can travel to your office,
meet at our offices or somewhere in between.  

As a reminder folks can always contact any Nomcom member to provide
feedback at anytime - i.e., you don't need to participate in these f2f
sessions to provide feedback. 


Belgium: 
 Dimitri Papadimitriou - dimitri.papadimitr...@alcatel-lucent.be (Sept
21-25) (Languages: French) 

Boston, Mass, USA:  
 Stephen Kent - k...@bbn.com  (Sept 16-18) 

Boulder, CO, USA: 
 Wassim Haddad - wmhad...@gmail.com (Sept 14-18)

Dallas/Ft. Worth, TX, USA:  
 Mary Barnes  - mary.h.bar...@gmail.com 
 Lucy Yong - lucyy...@huawei.com  (Languages: Chinese) 

Helsinki, Finland: 
  Simo Veikkolainen - simo.veikkolai...@nokia.com (Languages: Finnish)
 

Ithaca, NY, USA: 
  Scott Brim - scott.b...@gmail.com

Montevideo, Uruguay: 
  Roque Gagliano - ro...@lacnic.net (Sept 14-18, 21-25) (Languages:
Spanish, Portuguese) 

Montreal, Quebec, Canada 
 Wassim Haddad - wmhad...@gmail.com (Sept 8-11)
 -- Can also be available in Ottawa if folks are interested 

Paris, France: 
  Dimitri Papadimitriou - dimitri.papadimitr...@alcatel-lucent.be
(Sept 15-18)  (Languages: French)

San Diego, CA, USA: 
  Randall Gellens - rg+i...@qualcomm.com   
  Dave Crocker - dcroc...@bbiw.net  (Sept 16-18)

Silicon Valley/SF Bay,  CA, USA: 
  Dave Crocker - dcroc...@bbiw.net  (Sept 8-11, Sept 14-15, Sept
21-25)   
  Dorothy Gellert - dorothy.gell...@gmail.com

3) Questionnaires available for nominees: 

For folks that have been notified that they have been nominated for any
of the positions, the questionnaires are now available on the Nomcom09
tools website:
https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire
https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire
https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire

If you have any questions, please let me know. I will be contacting
everyone individually, as well as sending reminders before the deadline. 


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

New major release of NroffEdit

[Stefan Santesson]

For your information:

A new major release of NroffEdit is available from:
http://aaa-sec.com/nroffedit/index.html

This version provides several features requested by the RFC editor as well
as other IETF:ers. This includes:

- Added background spellchecker
- Color and style formats added to Nroff editing
- Added support for the .tl directive for both nroff->text and
  text-> nroff conversion
- Added search and replace feature
- Function for updating all issue and expiration dates

/Stefan


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian E Carpenter]

On 2009-09-01 05:56, Ben Campbell wrote:
> 
> On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:
> 
>> Yes, I understand, this only applies to the Independent Submission
>> stream.
>>
>> We ask the IESG to review these documents, and that review is technical.
>>
>> I don't think it is appropriate for an editor to make a judgment of
>> whether
>> a technical note is, or is not appropriate to be included in a
>> document.  I
>> think the presumption should be that it is appropriate, and the
>> authors have
>> a way to object.  While I understand the role of the ISE is somewhat
>> different from the RFC Editor, I understand the role to be primarily
>> editorial and we are not choosing the ISE with regard to their ability to
>> make judgments like whether the IESG note is appropriate or not.
>>
>> I think it would be okay to have the note go through an IETF consensus
>> call.
>>
> 
> +1 , including the "IETF consensus call" part.

I don't understand how IETF consensus is relevant to a non-IETF document.

In fact the answer to Jari's question appears to be a matter of logic,
not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.

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

Re: New major release of NroffEdit

[Stefan Santesson]

Resending as original mail got lost.
Sorry for double posing in case it turns up...

On 09-08-31 7:21 PM, "Stefan Santesson"  wrote:

> For your information:
> 
> A new major release of NroffEdit is available from:
> http://aaa-sec.com/nroffedit/index.html
> 
> This version provides several features requested by the RFC editor as well as
> other IETF:ers. This includes:
> 
> - Added background spellchecker
> - Color and style formats added to Nroff editing
> - Added support for the .tl directive for both nroff->text and
>   text-> nroff conversion
> - Added search and replace feature
> - Function for updating all issue and expiration dates
> 
> /Stefan


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Stephen Kent]

Joel,

I agree that IESG notes should be rare, but primarily because 
independent stream submissions should be rare :-).


Long ago, when I served on the IAB, we grappled with this problem, 
and failed to find a good solution. Despite what we say about RFC 
status and origin markings, the public sees RFCs as carrying the 
imprimatur of the IETF (not just that of the RFC Editor). When Jon 
Postel was the RFC editor, we were pretty comfortable with his 
judgement on these matters, this was less of an issue. However, time 
have changed and I would be happy to see inclusion of an IESG note be 
mandatory, contrary to historical practice.


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote:


On 2009-09-01 05:56, Ben Campbell wrote:


On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:


Yes, I understand, this only applies to the Independent Submission
stream.

We ask the IESG to review these documents, and that review is  
technical.


I don't think it is appropriate for an editor to make a judgment of
whether
a technical note is, or is not appropriate to be included in a
document.  I
think the presumption should be that it is appropriate, and the
authors have
a way to object.  While I understand the role of the ISE is somewhat
different from the RFC Editor, I understand the role to be primarily
editorial and we are not choosing the ISE with regard to their  
ability to

make judgments like whether the IESG note is appropriate or not.

I think it would be okay to have the note go through an IETF  
consensus

call.



+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF  
document.


Can't the IETF can have a consensus that a non-IETF document relates  
to other IETF work in some way?




In fact the answer to Jari's question appears to be a matter of logic,
not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under  
what circumstances would it be reasonable to refuse to include it?




Brian


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Brian E Carpenter]

On 2009-09-01 13:14, Ben Campbell wrote:
> 
> On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote:
> 
>> On 2009-09-01 05:56, Ben Campbell wrote:
>>>
>>> On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:
>>>
 Yes, I understand, this only applies to the Independent Submission
 stream.

 We ask the IESG to review these documents, and that review is
 technical.

 I don't think it is appropriate for an editor to make a judgment of
 whether
 a technical note is, or is not appropriate to be included in a
 document.  I
 think the presumption should be that it is appropriate, and the
 authors have
 a way to object.  While I understand the role of the ISE is somewhat
 different from the RFC Editor, I understand the role to be primarily
 editorial and we are not choosing the ISE with regard to their
 ability to
 make judgments like whether the IESG note is appropriate or not.

 I think it would be okay to have the note go through an IETF consensus
 call.

>>>
>>> +1 , including the "IETF consensus call" part.
>>
>> I don't understand how IETF consensus is relevant to a non-IETF document.
> 
> Can't the IETF can have a consensus that a non-IETF document relates to
> other IETF work in some way?

Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a problem,
and I didn't think Jari was reopening that aspect.

> 
>>
>> In fact the answer to Jari's question appears to be a matter of logic,
>> not of opinion. The IESG, which acts for the IETF, logically cannot
>> determine anything about the contents of a non-IETF document. So the
>> inclusion of an IESG note can only be a request.
> 
> How would you expect the RFC editor to evaluate such a request? Under
> what circumstances would it be reasonable to refuse to include it?

Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect that
in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the IESG was
showing unreasonable bias.

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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:

[...]





+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF  
document.


Can't the IETF can have a consensus that a non-IETF document  
relates to

other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a  
problem,

and I didn't think Jari was reopening that aspect.



Ah, sorry, I was agreeing with Brian Rosen statement that  a concensus  
call was okay. I didn't mean (and I doubt he did, but he can speak for  
himself) that I think we _needed_ one, only that if that were the only  
way we could make an IESG request "binding", then it was okay. If we  
feel we can trust the IESG on this, I'm okay with it :-)







In fact the answer to Jari's question appears to be a matter of  
logic,

not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under
what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect  
that

in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the  
IESG was

showing unreasonable bias.


I assume an ISE could also who bias.

It seems to me this all converges on deciding who has to appeal in a  
dispute.




   Brian


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

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

Making the IESG note mandatory, even if that required IETF agreement, 
would essentially give the IETf veto over the Independent stream.  The 
IESG would simply propose a note so extreme that no author would accept 
it on their document.  Given that I have seen proposed notes almost that 
bad in the past, I see no reason to believe it will not happen in the 
future.


Unless we wish to gut the Independent Stream of its right and important 
role of providing critical review of ongoing ideas, I would strongly 
recommend that the IAB not accept any procedure by which this would occur.


Remember, the IETF did not create the Independent Stream.  It arguably 
predates the existence of standards track documents.


Yours,
Joel

Ben Campbell wrote:


On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:

[...]





+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF 
document.


Can't the IETF can have a consensus that a non-IETF document relates to
other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a problem,
and I didn't think Jari was reopening that aspect.



Ah, sorry, I was agreeing with Brian Rosen statement that  a concensus 
call was okay. I didn't mean (and I doubt he did, but he can speak for 
himself) that I think we _needed_ one, only that if that were the only 
way we could make an IESG request "binding", then it was okay. If we 
feel we can trust the IESG on this, I'm okay with it :-)







In fact the answer to Jari's question appears to be a matter of logic,
not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under
what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect that
in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the IESG was
showing unreasonable bias.


I assume an ISE could also who bias.

It seems to me this all converges on deciding who has to appeal in a 
dispute.




   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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Ben Campbell]

On Aug 31, 2009, at 9:04 PM, Joel M. Halpern wrote:

Making the IESG note mandatory, even if that required IETF  
agreement, would essentially give the IETf veto over the Independent  
stream.  The IESG would simply propose a note so extreme that no  
author would accept it on their document.  Given that I have seen  
proposed notes almost that bad in the past, I see no reason to  
believe it will not happen in the future.


Unless we wish to gut the Independent Stream of its right and  
important role of providing critical review of ongoing ideas, I  
would strongly recommend that the IAB not accept any procedure by  
which this would occur.


Remember, the IETF did not create the Independent Stream.  It  
arguably predates the existence of standards track documents.




So can the mandate be scoped? It seems like a little word smithing  
could distinguish between "notes to clarify relationship with  
standards work" vs "commentary on the quality of the work".



Yours,
Joel

Ben Campbell wrote:

On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:
[...]




+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF  
document.


Can't the IETF can have a consensus that a non-IETF document  
relates to

other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a  
problem,

and I didn't think Jari was reopening that aspect.

Ah, sorry, I was agreeing with Brian Rosen statement that  a  
concensus call was okay. I didn't mean (and I doubt he did, but he  
can speak for himself) that I think we _needed_ one, only that if  
that were the only way we could make an IESG request "binding",  
then it was okay. If we feel we can trust the IESG on this, I'm  
okay with it :-)




In fact the answer to Jari's question appears to be a matter of  
logic,
not of opinion. The IESG, which acts for the IETF, logically  
cannot
determine anything about the contents of a non-IETF document. So  
the

inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request?  
Under

what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I  
would

expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect  
that

in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the  
IESG was

showing unreasonable bias.

I assume an ISE could also who bias.
It seems to me this all converges on deciding who has to appeal in  
a dispute.


  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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

[Joel M. Halpern]

The scope already says that the IESG is only supposed to comment on the 
relationship to existing work.  When the comments are on that topic, 
there has rarely been an issue.  (The one related difficulty is when the 
IESG has asked for reasonable delays, to let a working group get its 
product out, and then the WG has taken much longer than expected to 
deliver.)
However, even then the editor has needed to edit the words provided.  Of 
course, such editing has to be negotiated with the IESG.  (The edit can 
edit, but he can't put words in someone elses mouth.)



Part of the problem I face is that there is significant evidence that 
the IESG has unintentionally produced very biased and inappropriate 
text.  The ISE (RSE) needs to have a strong position from which to 
discuss such things.


I will grant that an unreasonable ISE can do unreasonable things.
There is no history of difficulties in the converse.

If the ISE / RSE is unreasonable, the IAB will slap the editor and say 
"stop doing that."  There is no equivalent process if we reverse the 
structure.


Yours,
Joel M. Halpern

Ben Campbell wrote:


On Aug 31, 2009, at 9:04 PM, Joel M. Halpern wrote:

Making the IESG note mandatory, even if that required IETF agreement, 
would essentially give the IETf veto over the Independent stream.  The 
IESG would simply propose a note so extreme that no author would 
accept it on their document.  Given that I have seen proposed notes 
almost that bad in the past, I see no reason to believe it will not 
happen in the future.


Unless we wish to gut the Independent Stream of its right and 
important role of providing critical review of ongoing ideas, I would 
strongly recommend that the IAB not accept any procedure by which this 
would occur.


Remember, the IETF did not create the Independent Stream.  It arguably 
predates the existence of standards track documents.




So can the mandate be scoped? It seems like a little word smithing could 
distinguish between "notes to clarify relationship with standards work" 
vs "commentary on the quality of the work".



Yours,
Joel

Ben Campbell wrote:

On Aug 31, 2009, at 8:38 PM, Brian E Carpenter wrote:
[...]




+1 , including the "IETF consensus call" part.


I don't understand how IETF consensus is relevant to a non-IETF 
document.


Can't the IETF can have a consensus that a non-IETF document 
relates to

other IETF work in some way?


Well, yes, but that's a decision we have historically chosen to
trust the IESG to take. I see no evidence that that has been a problem,
and I didn't think Jari was reopening that aspect.

Ah, sorry, I was agreeing with Brian Rosen statement that  a 
concensus call was okay. I didn't mean (and I doubt he did, but he 
can speak for himself) that I think we _needed_ one, only that if 
that were the only way we could make an IESG request "binding", then 
it was okay. If we feel we can trust the IESG on this, I'm okay with 
it :-)




In fact the answer to Jari's question appears to be a matter of 
logic,

not of opinion. The IESG, which acts for the IETF, logically cannot
determine anything about the contents of a non-IETF document. So the
inclusion of an IESG note can only be a request.


How would you expect the RFC editor to evaluate such a request? Under
what circumstances would it be reasonable to refuse to include it?


Well, in the future it will be the Independent Series Editor. I would
expect him/her to take such a decision just like an academic journal
editor would decide how to deal with a critical review. I'd expect that
in the large majority of cases, the ISE would agree to the request,
and would only consider refusing it if he/she concluded that the 
IESG was

showing unreasonable bias.

I assume an ISE could also who bias.
It seems to me this all converges on deciding who has to appeal in a 
dispute.


  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: Important Information about IETF 76 Meeting Registration

[Doug Ewell]

Lawrence Rosen  wrote:

Please note that you are now also collecting information that *is 
not* on the current blue sheets, namely "company/organization 
affiliation".


I thought that was the "problem" to which you were alluding. And my 
question remains: Is there any evidence that participants in IETF 
should not provide their company/organization affiliation when they 
participate? Is there something to hide?


Speaking only as an RFC author and WG participant, not as an IETF 
conference attendee, either in the past or in the foreseeable future...


I declined to state either my previous or current employer as my 
"affiliation" for either RFC 4645 or draft-4645bis, and instead listed 
myself as "Consultant," for two reasons: (1) neither employer has ever 
provided any support for my activities in the LTRU WG, and (2) a certain 
particularly ill-willed participant in LTRU had already used another 
participant's "affiliation" against him, writing to the legal department 
of that person's employer and demanding that he be professionally 
disciplined, something I didn't feel like risking for myself.


--
Doug Ewell  *  Thornton, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

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

Re: Important Information about IETF 76 Meeting Registration

[Fred Baker]

Good grief.

Before we do anything specific depending on the RFID tags, we'd like  
to know whether they are useful for the stated purpose. If they don't  
give us the information we need (if they can't be relied on to be read  
correctly by the RFID reader, which records the RFID tag, which can  
later be associated with a database entry containing the information  
you gave when you registered), they can't replace the blue sheets or  
do anything else that is useful. If they are functional, we can go on  
to rehash a discussion that has happened on this list many times -  
replace the blue sheet, or do other things with it.


We're not selling your souls. We're not taking pictures of you with a  
view to putting you under a spell. We're not selling your passport  
data to witch doctors. We're not doing a whole long list of things.  
We're seeing if the RFID system in question works. Nothing more,  
nothing less.


And BTW, the blue sheet gave a key (your email address) that could be  
associated with the information you gave when you registered, or could  
be looked up in google to find other interesting things about you.


Chill Out.

Go ahead and opt out. PLEASE opt out if you you can't deal with  
technology that might change - as all IETF technology does over time.  
Leave Alexa out of this.


On Aug 31, 2009, at 2:15 AM, Stephane Bortzmeyer wrote:


On Mon, Aug 24, 2009 at 11:06:31AM +0200,
Stephane Bortzmeyer  wrote
a message of 17 lines which said:


Any statement somewhere explaining what will be done with the data?
Since you talk about "electronic blue sheets", I assume there will
be many sensors, at least one per room so, in theory, the readers
may be able to gather a lot of data about attendees.


OK, the complete lack of answer is in itself a good indication. I will
opt out.

___
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