date:20090831



--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
jari.ar...@piuha.net 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

2009-08-31 Thread 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 jari.ar...@piuha.net 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



--On Monday, August 31, 2009 10:59 -0400 Brian Rosen
b...@brianrosen.net 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

2009-08-31 Thread 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
jari.ar...@piuha.net 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

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 
http://www.ietf.org/rfc/rfc.txt, 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

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

2009-08-31 Thread 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

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 bortzme...@nic.fr 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

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 
http://www.ietf.org/rfc/rfc.txt, 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

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




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

2009-08-31 Thread 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

2009-08-31 Thread 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 john-i...@jck.com 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

2009-08-31 Thread 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

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

2009-08-31 Thread 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

2009-08-31 Thread 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 st...@shinkuro.com 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




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

2009-08-31 Thread 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




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

2009-08-31 Thread 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



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


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

 
 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

2009-08-31 Thread 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


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

--On Monday, August 31, 2009 10:30 -0700 Bob Braden
bra...@isi.edu 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


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

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



--On Monday, August 31, 2009 13:20 -0500 Adam Roach
a...@nostrum.com 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




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

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

2009-08-31 Thread 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 
http://www.ietf.org/rfc/rfc.txt, 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

2009-08-31 Thread 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




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

2009-08-31 Thread 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


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

2009-08-31 Thread 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

2009-08-31 Thread 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 CROCKERd...@dcrocker.net 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

2009-08-31 Thread 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

2009-08-31 Thread 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

2009-08-31 Thread 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 allow 
  the initiator to match the Binding Revocation 
 Acknowledgement to its 
  outstanding Binding Revocation Indication that had the 
 Acknowledge (A) 
  bit set.
 
 Actually, I think the point would be clearer if you dropped 
 the part about the A bit

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

2009-08-31 Thread 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 
  other security mechanisms that would possibly be used in 
 the future to 
  secure IPv6 mobility signaling and consequently BRI/BRA.
 
 
 Sure--but it's appropriate for the BRI spec to say If BRI is 
 used without IPSec,

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



--On Monday, August 31, 2009 16:29 +0300 Jari Arkko
jari.ar...@piuha.net 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

2009-08-31 Thread 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 it.  Do we need more flexibility in

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

2009-08-31 Thread 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

2009-08-31 Thread 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

2009-08-31 Thread 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

2009-08-31 Thread 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 ste...@aaa-sec.com 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

2009-08-31 Thread 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



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

2009-08-31 Thread 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



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

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



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

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

2009-08-31 Thread Doug Ewell


Lawrence Rosen lrosen at rosenlaw dot com 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

2009-08-31 Thread 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 bortzme...@nic.fr 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

Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard

The IESG has received a request from the IP Security Maintenance and 
Extensions WG (ipsecme) to consider the following document:

- 'IKEv2 Session Resumption '
   draft-ietf-ipsecme-ikev2-resumption-07.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
i...@ietf.org mailing lists by 2009-09-14. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-07.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17990rfc_flag=0

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications' to Proposed Standard

The IESG has approved the following document:

- 'Definitions of Managed Objects for Mapping SYSLOG Messages to Simple 
   Network Management Protocol (SNMP) Notifications '
   draft-ietf-opsawg-syslog-msg-mib-06.txt as a Proposed Standard


This document is the product of the Operations and Management Area Working 
Group. 

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-msg-mib-06.txt

Technical Summary

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines a mapping of SYSLOG messages to Simple
   Network Management Protocol (SNMP) notifications.

Working Group Summary

   There was consensus in the working group to publish these documents.

Document Quality

   SNMP and SYSLOG are widely used and deployed. The document was 
   reviewed in the Working Group and by MIB DOctors. 

Personnel

   Scott Bradner is the Document Shepherd. Dan Romascanu is the 
   Responsible Area Director.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Mapping Simple Network Management Protocol (SNMP) Notifications to SYSLOG Messages' to Proposed Standard

The IESG has approved the following document:

- 'Mapping Simple Network Management Protocol (SNMP) Notifications to 
   SYSLOG Messages '
   draft-ietf-opsawg-syslog-snmp-05.txt as a Proposed Standard


This document is the product of the Operations and Management Area Working 
Group. 

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-snmp-05.txt

Technical Summary

   This memo defines a mapping from Simple Network Management Protocol
   (SNMP) notifications to SYSLOG messages.

Working Group Summary

   There was consensus in the working group to publish this document.

Document Quality

   SYSLOG and SNMP are widely implemented and deployed. The document was
   reviewed in the Working Group and by the MIB DOctors. 

Personnel

   Scott Bradner is the Document Shepherd. Dan Romascanu is the 
   Responsible Area Director.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Last Call: draft-ietf-calsify-2446bis (iCalendar Transport-Independent Interoperability Protocol (iTIP)) to Proposed Standard

The IESG has received a request from the Calendaring and Scheduling 
Standards Simplification WG (calsify) to consider the following document:

- 'iCalendar Transport-Independent Interoperability Protocol (iTIP) '
   draft-ietf-calsify-2446bis-09.txt as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
i...@ietf.org mailing lists by 2009-09-14. Exceptionally, 
comments may be sent to i...@ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-calsify-2446bis-09.txt


IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=13952rfc_flag=0

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer' to Proposed Standard

The IESG has approved the following document:

- 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport 
   Layer '
   draft-green-secsh-ecc-09.txt as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-09.txt

Technical Summary

This document describes algorithms based on Elliptic Curve
Cryptography (ECC) for use within the Secure Shell (SSH) transport
protocol.  In particular, it specifies: Elliptic Curve Diffie-Hellman
(ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key
agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for
use in the SSH Transport Layer protocol.

Working Group Summary

This document is the result an individual submission by members of
the community interested in seeing support for use of ECC algorithms
in the SSH protocol.  While there is no active working group behind
this work, it was extensively reviewed and discussed on the ietf-ssh
mailing list, which was the home of the Secure Shell Working Group
before that group concluded and still counts many of the participants
of that working group among its members.

Document Quality

While there are no existing implementations of this protocol, there
has been indication of interest from SSH implementors.

Personnel

The document shepherd for this document is Jeffrey Hutzelman
The responsible Area Director is Tim Polk.

RFC Editor Note

Section 12.1

Please remove the URL from the reference [FIPS-180-3].
 
Section 12.2

Please remove the URLs from references [NIST-800-57] and [NIST-CURVES].

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Alarms in SYSLOG' to Proposed Standard

The IESG has approved the following document:

- 'Alarms in SYSLOG '
   draft-ietf-opsawg-syslog-alarm-02.txt as a Proposed Standard


This document is the product of the Operations and Management Area Working 
Group. 

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-alarm-02.txt

Technical Summary

   This document describes how to send alarm information in syslog.  It
   includes the mapping of ITU perceived severities onto syslog message
   fields and a number of alarm-specific SD-PARAM definitions from X.733
   and the IETF Alarm MIB.

Working Group Summary

   The document was revised based on WG feedback  the result meets
   the issues that were raised.

Document Quality

   SYSLOG is widely implemented and deployed, and the ITU severities are

   used by a number of protocols and alarm models including the IETF 
   Alarm MIB. 

Personnel

   Scott Bradner is the Document Shepherd for this document.  Dan 
   Romascanu is the Responsible Area Director.

RFC Editor Note

Please insert the following edits in the published version: 

1. In section 1, 

Old:Alarm related terminology is defined in [RFC3877].


New:Alarm related terminology is defined in [RFC3877].

SD-ID, SD-PARM and other syslog related terms are defined in [RFC5424] 


2. In section 3

Old: the SD-PARARMS are mandatory.

New: the SD-PARAMS are mandatory.

 

3. In section 3.6

Old: [RFC1738] and its updates.  In the case of an SNMP resource, the

New: [RFC3986] and its updates.  In the case of an SNMP resource, the

 

4. In section 4

Old: In this example, extended from [Syslog], the VERSION is 1 and the
New: In this example, extended from [RFC5424], the VERSION is 1 and the

OLD: 'APP-NAME is su'
NEW: 'APP-NAME is evntslog'

OLD: 'examples...@0' 
NEW: 'examples...@32473'

OLD: 'resourceURI =' 
NEW: 'resourceURI='

5. In section 6

Old: IANA is requested to register the SD-IDs

New: IANA is requested to register the syslog Structured Data ID Values

6. In section 8.1

Old:[RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill,
Uniform
  Resource Locators (URL), RFC 1738, December 1994.

New:[RFC3986]  Berners-Lee, T., Fielding, R., and Masinter, L.,
Uniform Resource Identifier (URI): Generic Syntax, RFC RFC3986, January
2005.

7. In Section 3.1: 

OLD:  If the alarm SD-ID is supported, the resource SD-PARAM MUST be
   supported. 

NEW:  If the alarm SD-ID is included, the resource SD-PARAM MUST be
   included. 

8. In Section 3.2: 

OLD: If the alarm SD-ID is supported, the probableCause SD-PARAM MUST


   be supported.

NEW: If the alarm SD-ID is included, the probableCause SD-PARAM MUST
   be included.

9. In Section 3.3: 

OLD: If the alarm SD-ID is supported, the perceivedSeverity SD-PARAM
   MUST be supported.

NEW: If the alarm SD-ID is included, the perceivedSeverity SD-PARAM
   MUST be included.

10. In Section 3.4:

OLD: If the alarm SD-ID is supported, the eventType SD-PARAM SHOULD
be supported. 

NEW: If the alarm SD-ID is included, the eventType SD-PARAM SHOULD be
included. 

11. In Section 3.5: 

OLD: If the alarm SD-ID is supported, the trendIndication SD-PARAM
   SHOULD be supported. 

NEW: If the alarm SD-ID is included, the trendIndication SD-PARAM
   SHOULD be included. 

12. In Section 3.6: 

OLD: If the alarm SD-ID is supported, the resourceURI SD-PARAM SHOULD


   be supported.

NEW: If the alarm SD-ID is included, the resourceURI SD-PARAM SHOULD
   be included.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

Protocol Action: 'Extended MKCOL for WebDAV' to Proposed Standard

The IESG has approved the following document:

- 'Extended MKCOL for WebDAV '
   draft-ietf-vcarddav-webdav-mkcol-06.txt as a Proposed Standard


This document is the product of the vCard and CardDAV Working Group. 

The IESG contact persons are Alexey Melnikov and Lisa Dusseault.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-webdav-mkcol-06.txt

Technical Summary
  This specification extends the Web Distributed Authoring and
  Versioning (WebDAV) MKCOL method to allow collections of
  arbitrary resourcetype to be created and to allow properties
  to be set at the same time. It avoids minting new MK* methods
  (such as MKCALENDAR) for each new type of collection.
   
Working Group Summary
  Process was smooth; the only early disagreement was about the
  scope of this document (whether it should apply to
  non-collection resources as well, and whether it should also
  setting ACLs). In the end, the WG converged on the minimal
  functionality needed to resolve the issue.

Document Quality
  This protocol extension defined in this document is used
  by the VCARDDAV protocol (another deliverable of the Working
  Group), for which several vendors have announced support
  (for instance, Apple, and Viagenie).

Personnel
  The Document Shepherd for this document was Julian Reschke,
  and the responsible Area Director is Alexey Melnikov.

___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

IETF 76 - Registration Now Open

2009-08-31 Thread Alexa Morris

76th IETF Meeting
Hiroshima, Japan
November 8-13, 2009
Host: WIDE

Registration is now open! Note: while we stated earlier that we would
be moving to a new registration system, we have postponed that
transition to IETF 77. If you have attended a recent IETF meeting, the
IETF 76 registration system will be quite familiar.

1. Registration Categories
2. RFID Tagging Experiment
3. Visas and Letters of Invitation
4. Accommodations Breakfast Information

Changes from daylight savings to standard time are noted below.

1) Registration Categories

A. Early-Bird Registration - USD 635.00
Register and pay before Friday, 30 October 2009 at 17:00 PDT (24:00
UTC/GMT) for Early-Bird rate.

B. After Early-Bird cutoff - USD 785.00

C. Full-time Student Registrations - USD 150.00
Full-time students with proper ID are eligible to receive a special
USD 150.00 student rate. Student rate is not subject to any late-fees.
Students will also be able to register on-site at the special student
rate. Failure to provide valid student ID on-site will revoke the
special student status.

D. NEW: One Day Pass Registration - USD 200.00
For IETF 76 we are also experimenting with a one-day pass for $200.
Benefits are:

1. Attend all sessions during any one day of the Meeting, and partake
of the food and beverage during the breaks

2. You select which day to attend when you show up onsite to check-in
3. Payments may be made onsite without a late fee
4. Pass can be upgraded to a full Meeting Registration, however, late
fee may apply if initial one-day payment not made before Early Bird
deadline

5. Attend Sunday Tutorials at no additional charge
6. Attend Sunday Welcome Reception at no additional charge
7. Attend Wednesday and Thursday Plenaries at no additional charge
8. If available, you may purchase a ticket between 4-5pm on Tuesday
to attend the Host's social event that evening

CANCELLATION
The cut-off for registration cancellation is Monday, 2 November 2009
at 17:00 PST (01:00 Tuesday, November 3 UTC/GMT). Cancellations are
subject to a 10% (ten percent) cancellation fee if requested by that
date and time.

Online Registration ends: Friday, 6 November, 2009 at 17:00 local
Hiroshima time (00:00 Pacific, 08:00 UTC/GMT).

On-site Registration
You can register onsite at the meeting in Hiroshima, Japan starting
Sunday, 8 November at 12:00 noon PST (local Hiroshima time).

Meeting Schedule: Start Monday morning and run through Friday at 15:15
local Hiroshima time. Most training sessions will take place on
Sunday afternoon 13 November 2009. Participants should plan their
travel accordingly.

2) RFID Tagging Experiment
The hosts for IETF 76 are organizing an RFID tag experiment for the
meeting. The tag will be affixed to the underside of your meeting
badge, as a sticker, and will contain only your full name and any
listed affiliation. The experiment will allow us to explore the
possibility of electronic blue sheets (though we are still using paper
blue sheets as the official blue sheets of record for this meeting).
We also hope that the RFID tag will improve the experience for remote
participants, since speakers will be identified through the RFID tags.
While you will be given the option to opt out of this experiment
when you register for the meeting, we sincerely hope you will
participate. More information is available here: http://www.ietf.org/EbluesheetInformation.html

3) Visas and Letters of Invitation
Please check the Japanese MOFA site (http://www.mofa.go.jp/j_info/visit/visa/02.html
) for list of countries with visa exemptions. If you travel on a
passport issued by a country NOT on this list, you will require
documents issued in Japanese by the local host. An English language
letter of invitation from the IETF Secretariat WILL NOT suffice to
obtain a visa.

We recommend at least one month to complete the visa process.

To begin the process: 1) please complete Meeting registration and
payment of registration fees, 2) reserve accommodation, 3) complete
and return the visa information form, which are available in either
xls or PDF format on the host site here: http://www.ietf76.jp/

In addition, if you would also like to receive the official IETF
letter of invitation, you will be given the option of requesting one
after you have completed your meeting registration. Please note that
this letter will not assist with the visa process.

4) Accommodations Breakfast Information
Information on IETF 76 accommodations can be found here: http://www.ietf.org/meeting/76/hotel.html
. Please note that breakfast will NOT be provided as part of the on-
site meeting services. If you reserve a sleeping room at the ANA Crown
Plaza Hotel or at any of the IETF overflow properties, breakfast is
included with your room. If you choose to

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

2009-08-31 Thread 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-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 5616 on Streaming Internet Messaging Attachments


A new Request for Comments is now available in online RFC libraries.


RFC 5616

Title:  Streaming Internet Messaging Attachments 
Author: N. Cook
Status: Informational
Date:   August 2009
Mailbox:neil.c...@noware.co.uk
Pages:  28
Characters: 65579
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-lemonade-streaming-13.txt

URL:http://www.rfc-editor.org/rfc/rfc5616.txt

This document describes a method for streaming multimedia attachments
received by a resource- and/or network-constrained device from an
IMAP server.  It allows such clients, which often have limits in
storage space and bandwidth, to play video and audio email content.

The document describes a profile for making use of the URLAUTH-
authorized IMAP URLs (RFC 5092), the Network Announcement SIP Media
Service (RFC 4240), and the Media Server Control Markup Language (RFC
5022).  This memo provides information for the Internet community.

This document is a product of the Enhancements to Internet email to support 
diverse service environments Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 5641 on Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values


A new Request for Comments is now available in online RFC libraries.


RFC 5641

Title:  Layer 2 Tunneling Protocol Version 
3 (L2TPv3) Extended Circuit Status Values 
Author: N. McGill, C. Pignataro
Status: Standards Track
Date:   August 2009
Mailbox:nmcg...@cisco.com, 
cpign...@cisco.com
Pages:  11
Characters: 23133
Updates:RFC3931, RFC4349, RFC4454, RFC4591, RFC4719

I-D Tag:draft-ietf-l2tpext-circuit-status-extensions-05.txt

URL:http://www.rfc-editor.org/rfc/rfc5641.txt

This document defines additional Layer 2 Tunneling Protocol Version 3
(L2TPv3) bit values to be used within the Circuit Status Attribute
Value Pair (AVP) to communicate finer-grained error states for
Attachment Circuits (ACs) and pseudowires (PWs).  It also generalizes
the Active bit and deprecates the use of the New bit in the Circuit
Status AVP, updating RFC 3931, RFC 4349, RFC 4454, RFC 4591, and RFC
4719.  [STANDARDS TRACK]

This document is a product of the Layer Two Tunneling Protocol Extensions 
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 5647 on AES Galois Counter Mode for the Secure Shell Transport Layer Protocol


A new Request for Comments is now available in online RFC libraries.


RFC 5647

Title:  AES Galois Counter Mode for 
the Secure Shell Transport Layer Protocol 
Author: K. Igoe, J. Solinas
Status: Informational
Date:   August 2009
Mailbox:kmi...@nsa.gov, 
jaso...@orion.ncsc.mil
Pages:  10
Characters: 20990
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-igoe-secsh-aes-gcm-03.txt

URL:http://www.rfc-editor.org/rfc/rfc5647.txt

Secure shell (SSH) is a secure remote-login protocol.  SSH
provides for algorithms that provide authentication, key agreement,
confidentiality, and data-integrity services.  The purpose of this
document is to show how the AES Galois Counter Mode can be used to
provide both confidentiality and data integrity to the SSH Transport
Layer Protocol.  This memo provides information for the Internet 
community.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

STD 69, RFC 5731 on Extensible Provisioning Protocol (EPP) Domain Name Mapping


A new Request for Comments is now available in online RFC libraries.

STD 69
RFC 5731

Title:  Extensible Provisioning Protocol (EPP) Domain 
Name Mapping 
Author: S. Hollenbeck
Status: Standards Track
Date:   August 2009
Mailbox:shollenb...@verisign.com
Pages:  44
Characters: 87764
Obsoletes:  RFC4931
See Also:   STD0069

I-D Tag:draft-hollenbeck-rfc4931bis-01.txt

URL:http://www.rfc-editor.org/rfc/rfc5731.txt

This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet domain names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names.
This document obsoletes RFC 4931.  [STANDARDS TRACK]

This is now a Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

STD 69, RFC 5732 on Extensible Provisioning Protocol (EPP) Host Mapping


A new Request for Comments is now available in online RFC libraries.

STD 69
RFC 5732

Title:  Extensible Provisioning Protocol (EPP) Host 
Mapping 
Author: S. Hollenbeck
Status: Standards Track
Date:   August 2009
Mailbox:shollenb...@verisign.com
Pages:  29
Characters: 56219
Obsoletes:  RFC4932
See Also:   STD0069

I-D Tag:draft-hollenbeck-rfc4932bis-01.txt

URL:http://www.rfc-editor.org/rfc/rfc5732.txt

This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet host names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to host names.
This document obsoletes RFC 4932.  [STANDARDS TRACK]

This is now a Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

RFC 69, RFC 5733 on Extensible Provisioning Protocol (EPP) Contact Mapping


A new Request for Comments is now available in online RFC libraries.

RFC 69
RFC 5733

Title:  Extensible Provisioning Protocol (EPP) Contact 
Mapping 
Author: S. Hollenbeck
Status: Standards Track
Date:   August 2009
Mailbox:shollenb...@verisign.com
Pages:  41
Characters: 80698
Obsoletes:  RFC4933
See Also:   RFC0069

I-D Tag:draft-hollenbeck-rfc4933bis-02.txt

URL:http://www.rfc-editor.org/rfc/rfc5733.txt

This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of individual or
organizational social information identifiers (known as contacts)
stored in a shared central repository.  Specified in Extensible
Markup Language (XML), the mapping defines EPP command syntax and
semantics as applied to contacts.  This document obsoletes RFC 4933.  
[STANDARDS TRACK]

This is now a Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


___
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

STD 69, RFC 5734 on Extensible Provisioning Protocol (EPP) Transport over TCP