Rights Contributors Provide to the IETF Trust
RFC 5378
Yes
Lars Eggert
(Russ Housley)
No Objection
(Chris Newman)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 09 and is now closed.
Lars Eggert
(was Discuss)
Yes
Jari Arkko Former IESG member
Yes
Yes
(2008-05-21)
Unknown
The legend URL is currently non-existent. It should be created when the document is approved.
Russ Housley Former IESG member
Yes
Yes
()
Unknown
Chris Newman Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Cullen Jennings Former IESG member
(was Discuss)
No Objection
No Objection
(2008-06-04)
Unknown
It might be good to add an appendix to this document that contains the initial text that needs to be placed at the legends URL so there are no delays or surprises figuring that out. (Or if that is just a direct copy of something else, provide a pointer to it). In outbound, section 4.3, do you want to add "pseudo code" to the list. I seem to recall some IETF preference to pseudo code over any particular programming language. Section 4.5 of outbound. I've asked three other people to read section 4.5 and they have all come to somewhat different conclusions about what it means. You should consider if you need to make it more explicit - perhaps an example. Incoming section 3.4, 2nd para, "the" -> "The"
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
(2008-06-03)
Unknown
It may be the case that I have been involved in too many process discussions last week. I'm left reading the definition of RFC and the section on Non-IETF documents and not sure we're all talking about the same things. The definition of "RFC" (section 1.k) implies that all RFCs are IETF documents though it does not state it. This could be fixed with OLD: k. "RFC": the basic publication series for the IETF. NEW: k. "RFC": the publication series used by the IETF among others. Section 4 limits rights assignment to "IETF Standards Process". This may be OK but I think "IETF Processes" would be better here. Not all of our work is creating standards (some of it is process-changing work) but I believe the rights assignment applies to drafts on process changes. Like this one.
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
No Objection
No Objection
(2008-06-05)
Unknown
I believe that the text on IETF contributions probably covers WG charters already, but I support adding it to the definition for "Contribution" (1.a) in -incoming. I also note that the iab has explicitly requested that the iab stream be in scope. That made me wonder about the -iesg drafts. I know that -iesg documents should be considered in scope for the IETF stream, but I can't find a reference that clearly specifies that. Do we need to make a declaration like that in section 11 for our