Subject: Lisa's Apps Area Activity Report for May

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Jun 2008 10:20:19 -0700

Highlights:
MORG (Message Organization) BOF in planning for Dublin.
Forgot to mention IDNABIS WG was created last month: http://www.ietf.org/html.charters/idnabis-charter.html
P2P Workshop discussed several possible apps projects: finding a  
"local" server or mirror, BitTorrent caching, documenting BitTorrent  
itself.

Document Status and Progress

Active Documents: my action
  - draft-ietf-calsify-rfc2445bis (Proposed Standard):  Did AD Review,  
discussing issues of poorly-interoperable features with WG
  - draft-ietf-sieve-editheader (Proposed Standard): Last call  
Finished. Checking with author if ready for IESG Eval.

Stalled, in review, waiting on other:
  - draft-ietf-lemonade-msgevent (Proposed Standard): Last call  
finished, waiting for authors to deal with last call input
  - draft-freed-sieve-date-index (Proposed Standard): On IESG Agenda  
for Jun 5
  - draft-monrad-sipping-3gpp-urn-namespace (Informational): On IESG  
agenda for Jun 5
  - draft-snell-atompub-bidi (Proposed Standard): On IESG agenda for  
Jun 5
  - draft-resnick-2822upd (Draft Standard): Just needs an impl'n  
report to be approved by IESG.
  - draft-klensin-rfc2821bis (Draft Standard): One DISCUSS over  
example domain names to be resolved.
  - draft-ietf-eai-dsn (Experimental): Finished IETF Last Call,  
waiting on sibling documents
  - draft-ietf-sieve-notify-mailto:  Finished IETF Last Call, IANA has  
issues 	
  - draft-adolf-dvb-urn (Informational): Needs new version to address  
incomplete information about URN resolution

Finished Processing -- new in RFC Ed queue and new RFCs
  - draft-ellermann-news-nntp-uri (Proposed Standard): Now in RFC Queue
- RFC 5174, was draft-evain-ebu-urn-03 (Informational):
               A Uniform Resource Name (URN) Namespace for
                 the European Broadcasting Union (EBU)

WG Status
   CALSIFY: New version of RFC2446bis in WGLC?  RFC2445bis in AD review.
   HTTPBIS:  See summary of activity: http://lists.w3.org/Archives/Public/ietf-http-wg/2008AprJun/0397.html
   IDNABIS:  All WG drafts posted. WG is gathering list of open issues  
on these docs.
   IMAPEXT: In FIN-WAIT
   SIEVE: Finishing a few documents: WGLC on a Lemonade doc, discussion
   USEFOR: No activity.

_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 2 Jun 2008 22:36:08 +0200

> example domain names to be resolved.

BTW, the public tracker makes it easy to see DISCUSSes, but often
it's unclear how they were resolved.  Is there no option to enter
a statement with an updated ballot, or do you (collectively) just
don't use it ?

Out of curiosity I used the atom feeds for the various EAI, SMTP,
and 2822upd drafts, and after weeks I'm still not sure what you
(collectively) mean when you write "discuss discuss".  What is it,
a kind of meta-DISCUSS ?

> Finished Processing -- new in RFC Ed queue and new RFCs

Thanks.  Are you interested to "inherit" an unresolved IANA ticket
wrt the missing Web archive for the register @ uri.arpa list ?  I
fear that this DDDS list specified in RFC 3405 is completely dead.

>    USEFOR: No activity.

I've forwarded the RFC 2822 deployment report request.  To some
degree RFC.ietf-usefor-usefor and NetNews UAs are implementations
of RFC 2822.

 Frank

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Jun 2008 15:38:26 -0700

> a statement with an updated ballot, or do you (collectively) just

The tracker isn't very good at this.  In fact, when I clear my DISCUSS  
position on somebody else's document, the text *goes away* so it's  
hard to reconstruct history this way.  Sometimes, but not often, we  
remember to copy text from the DISCUSS to the COMMENT -- which is  
preserved.

> (collectively) mean when you write "discuss discuss".  What is it,

Yeah, and almost a joke.  The name of the ballot position is "DISCUSS"  
so that literally we can discuss an issue related to the document on  
the call.  However, if a DISCUSS is not cleared after the telechat, it  
becomes used for the ballot position's other purpose -- to block the  
document until certain changes are made -- that when one of us really  
just wants to make sure that something is discussed on the call, we  
say "discuss DISCUSS" in order to say reassuringly " This is really  
just to trigger a discussion and is not a blocking issue."

If we don't trigger a discussion, then the secretariat just announces  
in the call that such-and-such a document is approved and then move on  
to the next document, and its easy to miss this opportunity among  
20-30 documents.

An example of triggering pure discussion is if I want to ask the  
sponsoring AD whether he has considered Experimental instead of  
Informational but in the end either might be appropriate.

> fear that this DDDS list specified in RFC 3405 is completely dead.

I can't inherit IANA tickets.  My position is usually that these old  
never-created registries can remain non-existent until a need is  
proven via a registration request.

> degree RFC.ietf-usefor-usefor and NetNews UAs are implementations

Ok.

Lisa

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Jun 2008 15:56:15 -0700

>remember to copy text from the DISCUSS to the COMMENT -- which is

The text doesn't really go away; it becomes less handy to find, though,
as they aren't in the ballot text but are in the detail record.

>From the public tracker for a document, click the "detail" button.
The "Comment Log" will contain the text of each DISCUSS or
COMMENT listed, though you have to press a "View Detail" button
in most cases to actually see the text.

I would strongly object to any system which did not preserve the
previous DISCUSS texts, as it would significantly reduce the transparency
of the system.  Making it handier to find would be nice, but since
it is chronologically organized in the core record, this works well
enough.
			regards,
				Ted

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 3 Jun 2008 01:38:42 +0200

Lisa Dusseault wrote:

> we say "discuss DISCUSS" in order to say reassuringly " This is 
> really just to trigger a discussion and is not a blocking issue."

Thanks, now I got it, it is a pseudo-DEFER, not a meta-DISCUSS :-)

I knew "view details" to see older transactions, but for a ballot
update the details are just that, "xyz new position no objection"
or a similar one-liner.

 Frank

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jun 2008 10:10:47 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ted Hardie
> Sent: Tuesday, June 03, 2008 1:56 AM
> To: Lisa Dusseault; Frank Ellermann
> Cc: [email-masked]
> Subject: Re: Lisa's Apps Area Activity Report for May
> 
> >> it's unclear how they were resolved.  Is there no option 
> to enter a 
> >> statement with an updated ballot, or do you (collectively) 
> just don't 
> >> use it ?
> >
> >position on somebody else's document, the text *goes away* 
> so it's hard 
> >to reconstruct history this way.  Sometimes, but not often, 
> we remember 
> >to copy text from the DISCUSS to the COMMENT -- which is preserved.
> 
> The text doesn't really go away; it becomes less handy to 
> find, though, as they aren't in the ballot text but are in 
> the detail record.
> 
> COMMENT listed, though you have to press a "View Detail" 
> button in most cases to actually see the text.
> 
> I would strongly object to any system which did not preserve 
> the previous DISCUSS texts, as it would significantly reduce 
> the transparency of the system.  Making it handier to find 
> would be nice, but since it is chronologically organized in 
> the core record, this works well enough.
> 			regards,
> 				Ted
> 

The text of a cleared DISCUSS does not really go away and is still
retrievable as Ted observed. However it seems to me that the original
question was slightly different - it was not about the original DISCUSS
but about how it was resolved. Matching each DISCUSS with a DISCUSS
RESOLUTION seems to be the missing information in the tracker. 

Dan

---

From: John Leslie <[email-masked]>
Date: Tue, 3 Jun 2008 07:57:53 -0400

>> a statement with an updated ballot, or do you (collectively) just

   I'm guessing Frank is referring to the Comment Log found at

https://datatracker.ietf.org/idtracker/

which shows the entire history of state changes, ballot positions,
comments and DISCUSS texts; and is noting that it's hardly ever clear
how a DISCUSS was resolved. (Indeed, you have to look carefully for
the email address of the AD to even see _that_ a DISCUSS was cleared.)

> hard to reconstruct history this way.

   I believe Lisa is referring to the "Web Ballot" link from the IESG
Agenda web page, which shows only a snapshot summary of the positions
at the time it is generate and the text of COMMENTs and open DISCUSSes.
I believe this is what most IESG members work from for the telechat
discussions.

   The text of a DISCUSS does indeed "go away" from this page, which
I find confusing. There's a good reason, though: when the DISCUSS
position is cleared, that text is obviously out of date. (There's no
similar automatic expiry of COMMENT text.)

> Sometimes, but not often, we remember to copy text from the DISCUSS to
> the COMMENT -- which is preserved.

   It's not clear that individual IESG members _should_ feel any
obligation to do this. And a lot of the clearing of DISCUSSes happens
"at the last minute" -- leaving very little time to do any fancy
footwork for the benefit of folks who will later try to make sense
of what happened.

   Speaking only for myself, I'd find it easier to follow things if
there was an option (perhaps even the default) for each AD clearing a
DISCUSS to leave the text of the DISCUSS -- or edit it -- as a COMMENT
which is non-blocking but preserved (without any fancy cut-and-paste
footwork).

   This wouldn't help Frank much, unless the AD clearing the DISCUSS
actually had enough time to record _how_ an issue was resolved, but
it might be a step in the right direction...

--
John Leslie <[email-masked]>
_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 3 Jun 2008 09:35:49 -0700

> RESOLUTION seems to be the missing information in the tracker.

In theory we could move that information into a COMMENT field which  
would be kept with the ballots, without updating the tracker-- or even  
enter a comment in the comment log (Confusing, no?).   If we have a  
convention like that, it would be nice to be consistent about which we  
choose.

Of course, to encourage this more than by convention, one of the "nice  
to haves" for the tracker would be to prompt for a DISCUSS resolution  
text when a DISCUSS position is changed.

Lisa

---

From: "David Harrington" <[email-masked]>
Date: Tue, 3 Jun 2008 12:45:38 -0400

I think prompting for, and logging, a discuss-resolution really meets
the need. 

David Harrington
[email-masked]
[email-masked]
[email-masked]

> [mailto:[email-masked]] On Behalf Of Lisa Dusseault
> Sent: Tuesday, June 03, 2008 12:36 PM
> To: Romascanu, Dan (Dan)
> Cc: Frank Ellermann; [email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Wed, 04 Jun 2008 10:27:26 +0900

Two points:

- I have always looked at the comments log at
  https://datatracker.ietf.org/idtracker/, so I have never
  missed any (even cleared) DISCUSSes. There is a bit of noise
  there (sometimes, somebody goes back and forth on whether
  to add a discuss or not,...), but it's not bad enough that
  I was ever feeling the need for a fix.

- I agree that often, it might be good to see more discuss-
  resolution details. But while DISCUSSes are created very
  formally, my impression is that they often get resolved
  very informally. In many cases, e.g., there is some mail
  discussions with the draft authors or the WG chairs (and WG),
  and some text gets added or tweaked in a draft. In some
  other cases, it just ends up as "seem it wasn't as big
  a problem as I thought" or "ah, they already have a pragraph
  describing that issue", or "well, if the WG thought about
  it and decided the way they did, that's good enough",
  and so on. In the extreme, it may be "sorry, misunderstood,
  my bad". If these things have to be entered into
  a system, they suddenly might have to be worded much more
  formally, and I guess this might significantly reduce the
  flexibility of the current process.

Regards,    Martin.

>I think prompting for, and logging, a discuss-resolution really meets

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 4 Jun 2008 12:59:26 +0200

Martin Duerst wrote:
 
> If these things have to be entered into a system, they suddenly
> might have to be worded much more formally, and I guess this
> might significantly reduce the flexibility of the current process.

For minor issues like "does 2821bis say that DKIM signers are
gateways?" [Answer: no] I'm not worried about the invisibility
of the answer in the tracker, because I think I know what the
correct answer is.  

For other issues it is more interesting, e.g., what to do with
a missing implememtation report when more than ten requests on
different lists inside and outside the IETF by more than one
participant triggered no result, *and* everybody knows that  
SMTP is in use, *and* an older version is already part of a
STD.  The answer to this question (apparently: we tried, that
is good enough, let's move on) has major consequences:

- for implementors, they will now have to continue to support
  VRFY and EXPN no matter if two interoperable implementations
  actually using it exist.
- for other standards (next in queue: 2822upd) where getting a
  decent implementation report might turn out to be difficult.
  Is the same procedure as for 2821bis (= move on) okay ?  JFTR,
  IMO yes, but I still think that for PS to DS proposals the
  implementation report(s) should exist at the very begin of 
  the procedure, not as a procedural afterthought in the IESG
  discussion when the XXXXbis is ready.  

The answer might affect say IRIbis and 2616bis, even if I got
it completely wrong.

More on the hardcore nitpicking side, I'm really interested how
the 2821bis IPv6- and IPvFuture address ABNF issue work out,
and for the example addresses it's a bad case of "told you so"
schadenfreude on my side (after rightfully suffering the same
question for the detailed news-URI example).

 Frank

P.S.: this might also affect mailto-bis if you go for DS, and
      I don't see why you shouldn't at least try DS.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Jun 2008 12:24:10 +0100

>  I was ever feeling the need for a fix.
Agreed.

>  resolution details.
+1.

>  But while DISCUSSes are created very
>  very informally.
Indeed. In many cases document editors are so exhausted working on the 
document that they don't even post the result of changes to the WG 
mailing list. I was guilty of this myself.

>In many cases, e.g., there is some mail
I think the benefit for the community outweigh the disadvantages of 
wording things more formally. I don't think IESG members should be shy 
saying that they misunderstood something.
Besides, some discusses can be avoided by asking authors the question 
informally.

---

From: John Leslie <[email-masked]>
Date: Wed, 4 Jun 2008 11:01:15 -0400

Frank Ellermann <[email-masked]> wrote:
> STD.

   When this came up on the May 8 telechat, the blocker was a DISCUSS
by Russ Housley:
" 
" http://www.ietf.org/IESG/implementation.html does not seem to include 
" an implementation report for this document.  Scott Hollenbeck raised 
" this point on 30-Nov-2007 in a Last Call comment, but a report has not 
" appeared.  

   There now is a document titled "SMTP (2821) Implementation Information,
Used in Preparing RFC2821bis". (It's not clear when this was added, but
note it makes no claim of reporting implementations of 2821bis...)

> The answer to this question (apparently: we tried, that is good
> enough, let's move on) has major consequences:
> 

   ... a bit picky: we know perfectly well at least two exist (even if
we can't be bothered to prove _anyone_ actually enables it)...

>   Is the same procedure as for 2821bis (= move on) okay ?

   Umm...

   You won't catch it from reading the Ballot Tracker link from the
agenda page, but among the rougly 90 entries at 

https://datatracker.ietf.org/idtracker/draft-klensin-rfc2821bis/?

there's no entry saying that Russ ever cleared that DISCUSS.

   Instead he added two more DISCUSS comments about example domains.
I don't know whether Russ still sees that as a concern: I suspect that
most IESG members don't actually know either.

>   JFTR, IMO yes, but I still think that for PS to DS proposals
>   the implementation report(s) should exist at the very begin of 

   Let us not forget what RFC 2026 actually says:
] 
] A specification from which at least two independent and interoperable
] implementations from different code bases have been developed, and
] for which sufficient successful operational experience has been
] obtained, may be elevated to the "Draft Standard" level...
] The requirement for at least two independent and interoperable
] implementations applies to all of the options and features of the
] specification.  In cases in which one or more options or features
] have not been demonstrated in at least two interoperable
] implementations, the specification may advance to the Draft Standard
] level only if those options or features are removed.

   Clearly, nothing we post on this list can change that.

   The IESG can ignore it, I suppose, but I don't see that as setting
any sort of precedent for the next case.

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 4 Jun 2008 17:45:48 +0200

> note it makes no claim of reporting implementations of 2821bis...)

Oops, thanks for info, I wasn't aware of this.  Apparently the IETF
overdose script also doesn't look into the implementation reports
and appeals directories, or I missed it. 

> picky: we know perfectly well at least two exist (even if

TINW, I couldn't name the two when asked, but I believe you... :-)

> there's no entry saying that Russ ever cleared that DISCUSS.

For identical issues they sometimes pick somebody to hold the
DISCUSS, and clear the dupes.  In that case it's anyway obsolete,
I just didn't know that a somewhat anonumous report was posted,
but I saw that Cullen cleared his "discuss discuss" about it.

  [RFC 2026] 
 
> The IESG can ignore it, I suppose, but I don't see that as
> setting any sort of precedent for the next case.

Agreed, but I'm still interested "how stuff works", in practice.
Example, I submitted the CRAM-MD5 report because I want it to be
promoted on standards track at an appropriate point in time.

 Frank

---

From: Lisa Dusseault <[email-masked]>
Date: Wed, 4 Jun 2008 09:52:15 -0700

You're mostly right about the status of this but:

> most IESG members don't actually know either.

 From the comment log, it looks like Russ added to the DISCUSS text,  
but actually he replaced it.  It's a confusing aspect of the tracker,  
but if you find some way to look at just the current ballots rather  
than the comment log, you'll see that Russ's current DISCUSS text says  
nothing about interoperability or implementation reports.

> any sort of precedent for the next case.

Indeed, and while the IESG is perfectly satisfied about the  
interoperability of SMTP and Internet Message Format (2822upd), the  
next couple paragraphs of RFC2026 are very clear in requiring  
documentation of interoperability, testing and specific  
implementations, not merely that we be satisfied of a protocol's  
maturity.  So naturally we have to follow that process requirement.   
We had long discussions last week about how to reduce the effort  
required when interoperability is obvious, and whether that requires  
process changes.

Lisa

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Jun 2008 14:31:26 -0400

--On Wednesday, 04 June, 2008 17:45 +0200 Frank Ellermann
<[email-masked]> wrote:

>...
> Agreed, but I'm still interested "how stuff works", in
> practice. Example, I submitted the CRAM-MD5 report because I
> want it to be promoted on standards track at an appropriate
> point in time.

But it won't happen because, despite its very wide deployment
and demonstrations of utility, the lead author* believes that it
has been made clear that

-- There is a sufficiently strong preference for
	SASL-based mechanisms over standalone things like RFC
	2195 that the odds of a 2195bis being advanced are
	nearly zero.
	
-- There are enough concerns over challenge-response
	mechanisms based on MD5 (or keyed MD5) and the belief
	that CRAM-MD5 requires storing clear-text
	passwords/secrets on the server that the Security Area
	is likely to block any attempt to advance CRAM-MD5.
	Neither disclaimers in a Security Considerations section
	nor "better than clear-text passwords" arguments are
	likely to do much good here.

I even agree with the first of these.  I have mixed feelings
about the second, especially when the claimed solution is
Digest-MD5 instead of keyed-MD5, but no energy for arguments
with people who see the operational environment issues
differently that I do and who are sure they are right.

So, if there were any real desire to advance CRAM-MD5, it would
need to come from someone else.  It is not clear that I'd even
participate.

    john

* Paul Krumviede passed away some years ago and I don't know how
to find Randy these days, so...