IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2009-05-21. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was often uncertain who was speaking.)
Corrections from: Russ
1 Administrivia
- Roll Call 1135 EDT Amy:
- Jari Arkko--- y
- Ron Bonica--- y
- Ross Callon--- y
- Michelle Cotton--- y
- Ralph Droms--- y
- Lisa Dusseault--- y
- Lars Eggert--- regrets
- Pasi Eronen--- regrets
- Marshall Eubanks---
- Adrian Farrel--- y
- Sandy Ginoza--- y
- Russ Housley--- y
- Cullen Jennings--- y
- Olaf Kolkman--- regrets
- John Leslie--- y
- Alexey Melnikov--- y
- Cindy Morgan--- y
- Dave Oran---
- Ray Pelletier--- regrets
- Tim Polk--- y
- Dan Romascanu--- y
- Robert Sparks--- regrets
- Amy Vezza--- y
- Magnus Westerlund--- regrets
- Bash the Agenda
- Amy: webex, did you get instructions (sent Tuesday)
- Amy: new mgmt issue
- Amy: Nomcom earlier
- Cullen: could we discuss RSVP docs at the same time
- Amy: approches before first doc
- Approval of the Minutes of the past telechat
- May 7 minutes--- approved
- May 7 narrative minutes--- approved
- Review of Action Items from last Telechat
- Magnus Westerlund to draft an IESG Statement on BCP 32
Amy: Magnus not here
2 Protocol Actions
2.1 WG submission
2.1.1 - New Items
- RSVP Extensions for Path-Triggered RSVP Receiver Proxy (Proposed Standard)
draft-ietf-tsvwg-rsvp-proxy-proto-09
IPR: Cisco's Statement about IPR claimed in draft-ietf-tsvwg-rsvp-proxy-proto
Token: Magnus Westerlund Note: Please read the informational document draft-ietf-tsvwg-rsvp-proxy-approaches before this one!
Extracted from Balloting:
- Ron Bonica: Comment [2009-05-19]: I am abstaining not so much because of the content of this document, but because this document extends other work which is not fit for deployment across provider boundaries.
For the most part, ISPs do not permit customers to signal bandwidth across their boundaries using RSVP. There are many reasons for this, most significant of which is that it generally does not support the ISPs business models.
Network security issues are also significant. When most routers detect an RSVP message, which includes the IP Router Alert Option, the router consumes additional resources to process the optioned packet, before it authenticates the packet. This leaves the router vulnerable to various types of DoS attack.
The IETF should address the general problem of secure signaling before it spends any more cycles on RSVP extensions.
- Ross Callon: Comment [2009-05-21]: I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network).
I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail.
I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.
- Ralph Droms: Comment [2009-05-19]: Is the problem described in this text from section 3 a new problem introduced by RSVP receiver proxies:
"While the sender could infer reservation failure from the fact that it has not received a Resv message after a certain time, there are clear benefits in ensuring that the sender gets a prompt, explicit notification in case of reservation failure..."
- Adrian Farrel: Comment [2009-04-29]: Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor misses them.
...I am a little bothered by the use of "protected by an RSVP reservation" throughout the document. This is not the use of "protection" that I am familiar with. Perhaps "guaranteed" or "enabled"?
Figure 4: The key does not explain NotifyU
- Cullen Jennings: Discuss [2009-05-21]: I have placed all my issues for this spec into the discuss for proxy-approaches as it seemed better to have them in one place. Once we resolve theses, we can figure out what to do here. I would expect for important things like deployment applicability, for theses to occur in this specification and not just by reference to an informational document.
- Tim Polk: Discuss [2009-05-20]: The specification implies that use of these extensions is restricted to Receiver Proxies, but as I understand it, the sender has no way to determine whether they are performing end-to-end RSVP or communicating with a proxy. If a Regular RSVP Receiver implemented sender notification, what are the consequences (if any)?
- Robert Sparks: Comment [2009-05-19]: The document currently doesn't discuss how a proxy knows to act as a proxy. It appears that if a proxy as defined in this document is placed in front of a RSVP capable endpoint, that endpoint will cease to be allowed to participate in RSVP with no indication of why. Was that the intent, and if so, shouldn't this be explained in the document?
Telechat:
- (other RSVP doc discussed first)
- Amy: this also AD-followup
- DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal (Proposed Standard)
draft-ietf-dccp-simul-open-08
Token: Lars Eggert
Extracted from Balloting:
- Pasi Eronen: Comment [2009-05-15]: One editorial nit: there are two instances of "LISTEN'" that probably should be "LISTEN1" instead.
- Adrian Farrel: Comment [2009-05-21]:
Section 2.2.1
I believe that the final paragraph ("The remaining fields, including...") should include a full list of the fields. Further, the note should be placed before the text that states the specific values to be assigned to those fields.
It might be nice to discuss the X field just once.
It would be helpful to place the RFC Editor note immediately adjacent to the paragraph that deines the setting of the Type field.
Figure 2: The figure does not make it clear whether the DCCP-Listen should be sent a third time on time-out from Invited state. The text says "at most 2 retransmissions" so the figure appears to be wrong. It should say "3rd timeout".
- Alexey Melnikov: Comment [2009-05-15]:
2.2.2. Protocol Method for DCCP Server Endpoints
typo
2.2.3.1. Optional generation of Triggered Requests
typo
- Tim Polk: Comment [2009-05-21]:
Section 2.2.2, Note under the Figure
s/A server that responds a DCCP-Request/A server that receives a DCCP-Request/
s/LISTEN1state/LISTEN1 state/
s/LISTEN1states/LISTEN1 states/
Section 4, Security Considerations, paragraph 4 has unbalanced parentheticals...
s/SDP [RFC4566])/SDP [RFC4566]/
Telechat:
- Amy: Lars not here, open pos, Jari, didn't get to it; approved, I will check the notes
- MPLS Generic Associated Channel (Proposed Standard)
draft-ietf-mpls-tp-gach-gal-05
Token: Adrian Farrel Note: This I-D was last called in MPLS and PWE3; It has been approved by the ITU-T; IANA comments have been answered satisfactorily; Loa Andersson (loa@pi.nu) is the document shepherd
Extracted from Balloting:
- Russ Housley: Comment [2009-05-20]: In the Gen-ART Review, Miguel Garcia points out that the following sentnece in the first paragraph of Section 3.1 cn be interpretted in more than one way:
"The structure of ACH TLVs that MAY follow an ACH TLV Header is defined and described in the following sections."
Rewording to add clarity is desirable.
- Alexey Melnikov: Comment [2009-05-21]: I assume all 16bit fields are in network byte order?
Telechat:
- Amy: couple of open, all absent, no discusses,
- Adrian: couple of comments I want RFCed notes or whatever
- Amy: approved, point raised, will wait for Adrian
2.1.2 Returning Items
- An Internet Attribute Certificate Profile for Authorization (Proposed Standard)
draft-ietf-pkix-3281update-05
Token: Tim Polk
Extracted from Balloting:
- Adrian Farrel: Comment [2009-04-20]: s/IPSec/IPsec/ x2
- Dan Romascanu: Discuss [2009-04-21]: If I understand well the current rules and the latest interpretation given by the Legal Counsel of the IETF, the code in Appendix B should include the (long version) copyright notice in "code" similarly to MIB modules and such.
- Robert Sparks: Comment [2009-04-20]: The diff between this and 3281 is pretty simple. The deletion of this sentence (near the end of page 32 of 3281 update) sticks out on casual inspection:
"In this case, the digestedObjectType MUST be publicKey and the otherObjectTypeID field MUST NOT be present."
I wanted to shine the light on it to make sure its deletion was intentional.
Telechat:
- Amy: no open, a discuss
- Tim: can we move after mgmt item about copyright notice: don't know yet how to address the DISCUSS
- Russ: AD-followup in case we don't come back
2.2 Individual Submissions
2.2.1 New Items
- (none)
2.2.2 Returning Items
- H.248/MEGACO Registration Procedures (BCP)
draft-groves-megaco-pkgereg-03
Token: Cullen Jennings
Extracted from Balloting:
- Jari Arkko: Discuss [2009-05-21]: This document is fine overall, but there were two parts that I was unable to understand. Am I missing something obvious, or is there a mistake in the document:
"3) The public package requester shall provide a reference to a document that describes the package, which should be public:
"a) The document shall specify the version of the package that it describes.
"b) If the document is public, it should be located on a public web server and should have a stable URL. The site should provide a mechanism to provide comments and appropriate responses should be returned.
"c) If the document is not public, it must be made available for review by the IESG appointed Expert (without requiring an NDA) at the time of the application."
I am not sure I understand how a "public package requester" can ask for a value to a non-public specification, even if the expert reviewer will be able to see it.
"Note: The documenting text does not have to be publicly available at the time of the registration request, however the text shall be provided and available for review by the IESG appointed Expert at the time of application."
I do not understand the difference between "at the time of the registration request" and "at the time of application".
Also, how about s/documenting text/document/?
Comment [2009-05-21]:
"1. Binary ID (or serial number)"
Do people really register these using the binary representation? Perhaps you mean numeric, not binary. On the wire the number may be binary, but the IANA registry, for instance, uses hexadecimal representation. (http://www.iana.org/assignments/megaco-h248)
- Russ Housley: Comment [2009-05-19]: From the Gen-ART Review by Pete McCann ...
Section 4: typos
Section 6.2: typo
Section 6.3: s/(Specification required/and required specification/
- Alexey Melnikov: Discuss [2009-05-21]: 5.3. Error Code Registration Procedure
"6) An error number shall not be redefined nor modified except by the organization or individual that originally defined it, or their successors or assigns."
I would like to better understand what is meant by "redifinition or modification" of an error number?
If this means that the error condition associated with an error is redefined, then surely this should result in another Expert review (to make sure that redifinition is a clarification, as opposed to assignment of a totally different meaning). If redefinition means changing of the error number, then again, this would require another Expert review.
Comment [2009-05-21]: I think IANA registration templates for "Error Code Registration" (section 6.2) and "ServiceChange Reason Registration" (section 6.3) should also include the owner/contact information.
- Tim Polk: Comment [2009-05-21]: I support Alexey's Discuss.
Telechat:
- Amy: open not here, some discusses
- Cullen: not really a returning item, didn't know how to clear "returning" flag; primary issue private/public: two registries, intent single-vendor vs. interoperable; right now you can get public entries without making the spec public: the ones that care share their secret specs
Russ: couple of situations: codepoint private until approved, vs given only to members, we don't have an in-between category, so I cleared; first part of Jari's discuss same as mine
- Jari: second part was confusion about wording
- Cullen: we'll fix that
- Jari: I cleared to no-obj
- Alexey: prefer enough info in RFC for expert to know what to check; wording looks OK
- Cullen: text has to be available to expert reviewer, bounce text back and forth to fix intent; AD-followup waiting RFCed notes
3 Document Actions
3.1 WG Submissions
3.1.1 New Items
- Adding Explicit Congestion Notification (ECN) Capability to TCP's SYN/ACK Packets (Experimental)
draft-ietf-tcpm-ecnsyn-09
Token: Lars Eggert
Extracted from Balloting:
- Jari Arkko: Comment [2009-05-21]: Excellent work. It was a pleasure to read this.
- Pasi Eronen: Discuss [2009-05-15]: I have reviewed draft-ietf-tcpm-ecnsyn-09. Overall, the document looks OK, but there are two things that should be fixed before the document is approved:
The document does not have any normative references -- certainly at least RFC793 and RFC3168 should be normative? (perhaps some others, too)
Since the document uses RFC 2119 key words, it should have a (normative) reference to RFC 2119.
- Tim Polk: Comment [2009-05-21]: Good document overall.
This document might benefit from a description of the experiment(s) that should be run to see if deployment is beneficial. (Section 6 indicates that the answer will be different based on the specific environment).
Telechat:
- Amy: Lars not here, Pasi not here either, AD-followup
- DomainKeys Identified Mail (DKIM) Service Overview (Informational)
draft-ietf-dkim-overview-11
Token: Pasi Eronen
Extracted from Balloting:
- Adrian Farrel: Comment [2009-05-21]: In section 1.4.1 you have "(per Allman)". Presume this is a reference to RFC 4871 and so changning to "[RFC4871]" would be nice. but if it is a reference to
something else, perhaps you could iclude it.
- Alexey Melnikov: Comment [2009-05-16]:
1. Introduction
typo
1.2. Prior Work
"There have been four previous IETF Internet Mail signature standards. Their goals have differed from those of DKIM. The first two are only of historical interest."
Actually, I think the 2nd and the 3rd are of historical interest. I.e. OpenPGP is still in use.
"PEM eventually transformed into MIME Object Security Services (MOSS) in 1995. [RFC1848] [RFC1991]"
RFC 1991 is "PGP Message Exchange Formats". Is it the correct reference here?
2.2. Enabling Trust Assessments
typo
3.1.1. Use Domain-level granularity for assurance
typo
3.1.4. Distinguish the core authentication mechanism from its derivative uses
typo
- Tim Polk: Comment [2009-05-21]: In Figure 1, the flow from the "Assessments" box is non-deterministic; it appears the next step could be "Check Signing Practices" or "Message Filtering Engine". The supporting text in Section 5.5 did not clarify the situation.
I would suggest labeling the diagram or adding explanatory text in 5.5.
Telechat:
- Amy: Pasi not here, no discusses
- Jari: some text about when no dkim signature; e.g. drop if "all have dkim signature"
- Lisa: I'm not convinced either, but WG took position of "same"
- Russ: until we have SSP, no way for recipient to know the policy of the sender; even then, SSP will depend on DNSSEC for integrity; "act in forgiving manner", not yet to point to trust
- Tim: we can rachet up later, "mail isn't bad because of lacking dkim"
- Cullen: don't want this to be blacklist, or favor poorly-known domains
- Russ: once you build expectation, you can say "this one not like the others"
- Cullen: that would make statement in draft false: why does WG stick to this mantra
- Tim: spam signed with dkim is still spam
- Lisa: WG has long avoided saying anything about what "system" would do
- Jari: will follow up, but won't block
- Tim: may be some decisions made due to lack of dkim signature
- Russ+Jari: approved-point-raised
- RSVP Proxy Approaches (Informational)
draft-ietf-tsvwg-rsvp-proxy-approaches-07
IPR: Cisco's Statement about IPR claimed in draft-ietf-tsvwg-rsvp-proxy-approaches-02.txt
Token: Name Magnus Westerlund: Note: Read this before the Protocol document; Was deferred by Cullen Jennings on 2009-05-05
Extracted from Balloting:
- Jari Arkko: Discuss [2009-05-21]: I am not against publishing these specifications (and I guess even the authors see them as necessary evil in comparison to the end-to-end RSVP model). However, I think the documents should describe more clearly their implications and limitations. A Surgeon General's Warning if you will.
I'll note that I am not an RSVP expert. I may have missed something. In that case, please educate me and I'll clear this Discuss.
In particular, Section 4.1 says:
"In order to build the Resv message, the RSVP Receiver Proxy can take into account information received in the Path message. For example, the RSVP Receiver Proxy may compose a FLOWSPEC object for the Resv message which mirrors the SENDER_TSPEC object in the received Path message."
RSVP has separate flow reservations for the two directions, and just copying the flow spec from one direction to another is a severely limited approach. Or perhaps even a potentially harmful approach. For instance, in any streaming or IPTV situation this approach would clearly lead to problems. One could ask how well the network works (a) with the proxy QoS reservations or (b) without any reservations. The ability to make the reservations allows bandwidth to be reserved, and increases the likelihood of, say, successful video transmission. However, the guessing involved in the mirroring process leads to incorrect reservations...
The application triggered mechanisms have a better chance of a successful outcome, but they imply fairly severe involvement in the application signaling process, such as the introduction of a b2bua. What's the likelihood of a b2bua on the signaling path disrupting your intended communication setup? I'd claim its a non-zero probability...
I would suggest that Section 4.1 needs to include additional text to document the problems associated with mirroring. Also, the introduction should provide stronger guidance on the overall benefits vs. disadvantages associated with the proxies, and suggest that the proxies only be setup for very specific networks, applications, and flows to specific destinations.
- Ron Bonica: Comment [2009-05-19]: I am abstaining not so much because of the content of this document, but because this document extends other work which is not fit for deployment across provider boundaries.
For the most part, ISPs do not permit customers to signal bandwidth across their boundaries using RSVP. There are many reasons for this, most significant of which is that it generally does not support the ISPs business models.
Network security issues are also significant. When most routers detect an RSVP message, which includes the IP Router Alert Option, the router consumes additional resources to process the optioned packet, before it authenticates the packet. This leaves the router vulnerable to various types of DoS attack.
The IETF should address the general problem of secure signaling before it spends any more cycles on RSVP extensions.
- Ross Callon: Comment [2009-05-21]: I am concerned that RSVP in general allows hosts to send something that the router has to receive in its control plane, which opens up the possibility of DOS attacks by the hosts against the routers. Given the current state of host security, it is pretty much a non-starter to let millions of hosts send anything to the router's control plane. The result is that service providers won't allow RSVP packets across the CE/PE boundary (or just tunnel them over the network).
I am not aware of this being discussed anywhere. I think that this general issue is worth writing up in more detail.
I am putting this in as a comment, rather than a DISCUSS, since this is not specific to RSVP proxy. It is a basic issue with RSVP (which of course is water than went over the dam a very long time ago). Thus it is not at all clear that this document is the right place to discuss this issue.
- Ralph Droms: Comment [2009-05-21]: In section 4.1, the paragraph immediately following figure 3 explains that receipt of a ResvErr by the RSVP Receiver Proxy "ensures that the RSVP Receiver Proxy is aware of the reservation failure, conventional RSVP procedures do not cater for notification of the sender of the reservation failure." It's not clear to me why the sender needs to be notified of reservation failure. Is this addressing a problem with RSVP generally or just RSVP Receiver Proxy? I speculate that the problem here may be that the Proxy receives the ResvErr, so neither the application receiver nor the sender is explicitly notified of the reservation failure; do I have that right? Would someone more familiar with RSVP than I am be able to deduce the reason for sender notification? I'm happy to be educated as I'm not well-versed in RSVP.
Nit: "cater for" might read better as "cater to" or "provide for"
- Adrian Farrel: Comment [2009-04-29]: Nits to fix if you have to do a respin or in AUTH-48 if the RFC Editor misses them.
I am surprised that all of your references are Informative. Surely some of these are prerequisites for understanding your work?
- Cullen Jennings: Discuss [2009-05-21]: Need to discuss the applicability of deployment - as previous RSVP discussions, this is likely only deployable inside a single trust domain.
For a proxy that does inspection or path triggered, how does it know which ones to "proxy" and what to ignore. It seems this will break all end to end RSVP that behind a proxy.
How does one migrate out proxy RSVP to end to end RSVP?
How do proxies know what bandwidth to request for a flow? If they assume some certain bandwidth, this makes it much harder to deploy new services.
For something like triggered approach, when does the reservation get town down?
The draft discusses deployments snooping SIP. Experience with SIP ALGs in firewalls has proven this is a really bad idea and mostly fails. Not to mention SIP over TLS.
The draft seems to hint at detecting RTP packets - I have no idea how to do this, please clarify.
ICE is sometime used to signal media flows, but not always - how would the device know. Even worst, how would it know what bandwidth to use.
Has the working group considered if there are ways to achieve this that are not IPR encumbered?
The example in A.3 seems really confused about how SBC work.
As I am sure the authors of this draft are aware, the example in A.5 was something the SIP WG had more than one strong hum on this was not an appropriate use of SIP.
- Alexey Melnikov: Comment [2009-05-03]: 4.3. Inspection-Triggered Proxy
"Note however, that in case of reservation failure, the inspection-triggered RSVP Proxy does not have a direct mechanism for notifying the application..."
The first use of the DSCP acronym should be expanded.
I am also agreeing with Adrian's comment, I was wondering about this myself.
- Tim Polk: Discuss [2009-05-05]: Two issues: number one is actionable, the second is a discuss-discuss...
Issue #1: The security considerations do a nice job highlighting the issues introduced by proxies, but more detail is needed with respect to RSVP proxies that operate under control of another entity (Para 4). These models introduce new security requirements for communication between the proxy and the controlling entity that are outside the scope of RSVP or this document. Specifically, these models introduce authentication and confidentiality requirements to protect against a variety of attacks. The current text indicates the controlling entity needs to be trusted, which is also true, but is insufficient.
Issue #2: (Section 1, Introduction) What are the consequences of violating the topological constraints and having two Receiver Proxies on path? It seems that RSVP would not be used to its fullest, and the resource reservation would cover less of the path than it could, but this seems to be sub-optimal rather than broken.
I also wonder whether this merits discussion in the security considerations... perhaps that will become clear as we discuss the consequences of violating the topological constraints.
Comment [2009-05-05]: section 1:
"presents several fundamental RSVP proxy approaches insisting on how ..."
I don't think "insisting" is the right word here!
section 4.4:
s/cortresponding/corresponding/
s/implicitely/implicitly/
- Dan Romascanu:Comment [2009-05-21]:In Section 4.5:
"Candidate protocols for realizing such interface include SNMP ([RFC3416]), COPS-PR ([RFC3084]), QPIM ([RFC3644]), the Extensible Markup Language (XML) and DIAMETER ([RFC3588])."
SNMP is seldom used for configuration purposes over the Internet in real life. COPS-PR has very little reported deployment if at all. XML is manguage to present information and not a protocol.
I suggest to take out XML, and to consider whether SNMP and COPS-PR should be left in the text. On the other hand I believe that it would be appropriate to mention here NETCONF (RFC 4741) which is a protocol that uses XML-encoding for performing configuration management operations on network devices.
- Robert Sparks: Comment [2009-05-17]: Agree with Tim's concern #2 (what happens when you unintentionally (or intentionally) end up with more than one proxy in a path?
Telechat:
- (taken up first)
- Amy: Magnus not here; Cullen did you clear discuss
- Cullen: no
- Amy: webex showing a work document
- Ralph?: I put in comment, text probably would go somewhere else; service providers can't let hosts send options to control plane of their routers; good to have document that discusses this generally applicable to RSVP
- Cullen: need to be consistent within RSVP; deployments I'm aware of run within a single trust framework. I don't think this is appropriate for other reasons, "move all intelligence to network" breaks RSVP to end-hosts when router intercepts; difficult to migrate away from this once deployed. Intercept/trigger modes... how do they know when to tear down bandwidth; all that architecture is in this informational document; do others have feelings about architecture
- Amy: already deferred once
- Russ: AD-followup
3.1.2 Returning Items
- (none)
3.2 Individual Submissions via AD
3.2.1 New Items
- (none)
3.2.2 Returning Items
- (none)
3.3 Independent Submissions via RFC Editor
3.3.1 New Items
- (none)
3.3.2 Returning Items
- The Subnetwork Encapsulation and Adaptation Layer (SEAL) (Informational)
draft-templin-seal-23
Token: Jari Arkko: Note: Brought back to the agenda because of desired status change (now Inf)
Extracted from Balloting:
- Ralph Droms: Comment [2009-05-20]: I will change my position to "No Objection" when the course of action suggested by Jari (in e-mail on 5/20) is carried out; draft-templin-seal-23.txt shows "Intended status: Informational":
I have no problem with going ahead with this content and an Experimental RFC.
(I did not have any problem with the original content either. You and the RFC Editor should work out which text actually goes out, you changed quite a bit and they had already done their editing.)
RFC-Editor, Fred: I take it that we are back in the original plan, i.e., Experimental RFC and the IANA considerations as they were. If yes, I could just withdraw the draft from the new consideration of the IESG. Perhaps you want to send an e-mail to that effect to the IESG.
- Cullen Jennings: Discuss [2009-05-21]: On the IESG call, I would like to talk about if, given the IANA considerations, we need to add more the IESG note about the deployability of this.
Telechat:
- Amy: one discuss
- Jari: recap history, Mark was handling, agreed to be Experimental; Fred complained... now asking for Informational, not entirely clear about protocol numbers, flopping Experimental / Informational; eventally might be Proposed Standard; note I have covers both Experimental and Informational (funny to use experimental codes in Info, don't want to burn protocol numbers)
- Ron: he talks of rollover problem, there are other motivations that are sound; maybe it really does want to be Proposed Standard
- Jari: started that process in San Francisco, shouldn't have to go standards track
- Ross: cases where parts of code-space assigned for Experimental, but none for Informational
- Jari: it's type-of-use, not document type; argument here is whether Experimental codepoints are appropriate
- Ross: would make sense to start with Experimental codepoints, then find folk to work on permanent codepoints
- Cullen: if Experimental path, is it deployable, how would somebody use it? should we mention deployment issues?
- Jari: already says "not to be used for deployment"
- Ron: not a lot stopping you from deploying (at tunnel ends) with Experimental code points
- Jari: RFCed note says if IANA allocates actual numbers, would violate IETF procedures, also says useful to adopt via IETF process
- Amy: approved to go back to RFCed, notes OK
1224 EDT break
1229 EDT back
- Jari Arkko--- y
- Ron Bonica--- y
- Ross Callon--- y
- Michelle Cotton--- y
- Ralph Droms--- y
- Lisa Dusseault--- y
- Lars Eggert---
- Pasi Eronen---
- Marshall Eubanks---
- Adrian Farrel--- y
- Sandy Ginoza--- y
- Russ Housley--- y
- Cullen Jennings--- y
- Olaf Kolkman---
- John Leslie--- y
- Alexey Melnikov--- y
- Cindy Morgan--- y
- Dave Oran--- y
- Ray Pelletier---
- Tim Polk--- y
- Dan Romascanu--- y
- Robert Sparks---
- Amy Vezza--- y
- Magnus Westerlund---
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
- (none)
4.1.2 Proposed for Approval
- Yet Another Mail (yam)
Token: Alexey
Telechat:
- Amy: any objection, need chairs & milestone dates
- Alexy: two proposed chairs, want IETF mailing-list, will send revised charter
- Amy: approved pending edits and creation of mailing-list
- Extensible Messaging and Presence Protocol (xmpp)
Token: Cullen
Telechat:
- Amy: any objection?
- Cullen: end-to-end confidentiality is a goal, third paragraph last sentence; WG name has been a problem, need to pick one and move on, xmpp is the preferred name, can we use it?
- Russ: old charter will disappear
- Cullen: don't think any of that matters, could consider this as recharter, happy to add text to clarify, have two proposed WGCs
- Russ: approved-point-raised
- Cullen: will try process to create mailing-list before end of call
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
- (none)
4.2.2 Proposed for Approval
- (none)
5. IAB News We can use
- Dave: no update, nothing of specific interest from Amsterdam meeting
- Russ: status of "harmful" draft, got comments from Malcolm, will forward to authors
6. Management Issues
- Ballot Procedures (Russ Housley)
Telechat:
- (taken fifth)
- Russ: distributed results of our discussion, should these be posted? Approved-point-raised
- Amy: discussed, approved ballot procedures, will post when Russ sends it
- Revision 1.9 for ID-Checklist.html (Russ Housley)
Telechat:
- (taken third)
- Russ: followup from retreat sent; is this ready for posting
- Several: fine with me
- Russ: Secretariat directed to post it
- Amy: check that files came in correctly; IESG approved the revision
- Shepherd names in agendas (Jari Arkko)
Telechat:
- (taken fourth)
- Jari: came from discussion with Mary; they look at agenda to email appropriate people, shepherds not seeing everything they'd like to; we're not using the same field, thoughts?
- Cullen: stopped adding it two years ago
- Russ: other people are using it, not always in proto tracker
- Ross: doesn't WGC get info anyway
- Jari: don't know if GenArt is already sending to WGC; we need to point to one place, Note field is about 30%
- Dan: may have name but not address
- Russ: don't see reviewer digging through tracker
- Tim: always intend to put shepherd email; seems like we ought to have separate field in tracker, one place where people will always fill it; decide long-run, temporary if necessary
- Russ: database changes needed
- Jari: Secretariat could fill in Note field
- Cullen: Note field isn't the important place, the list of email addresses is important
- Russ: give review teams a separate list, secretariat to include proto shepherd
- Cullen: <draft-name>@tools could include everyone
- Tim: expanded list beyond authors once it goes into tracker
- Ralph: is there legacy assumption to worry about (only authors)?
- Jari: two proposals, neither is immediately, what do we do immediately
- Russ: I'd rather not clutter the agenda; ask secretariat to put into notify list when entering tracker
- Ross: secretariat could add to existing (email addresses) field if needed
- Jari: final solution is <draft>...@tools; interim...; I'll talk to Henrik, Russ talk to GenArt, tell secretariat to add shepherd name to Note field and email field if needed
- Ross: no-one objecting
- Amy: action items, Jari talk to Henrik, Russ to GenArt, regarding distribution of reviews, secretariat to check if shepherd not WGC, add to notification-change field
- IESG Requirements to NomCom (Russ Housley)
Telechat:
- (taken first)
- Russ: sent out descriptions from last two years, need update, especially OPS, want a timeline for review, target 2-weeks for final approval
- Dan: I can provide draft in next few days; holiday next week...
- Ross: most recent NomCom wanted e.g. both ops & mgmt
- Russ: we declined that request
- Cullen: descriptions generally high-level, could say "especially need expertise in X"
- Several: our description are pretty general
- Lisa: during NomCom interview I explained areas Chris covered
- Tim: suggest thinking what info we want to give them, then resume discussion
- Ralph: offer to chat offline with anyone who wants the NomCom viewpoint
- Amy: discussed, mgmt item on June 4 agenda
- Legal provisions relating to IETF documents (Russ)
Telechat:
- (taken second)
- Russ: draft sent last Friday, IETF trust wants to know if IESG generally agrees
- Tim: referencing sections which didn't exist in earlier draft; still having trouble with corner cases, e.g. code components
- Russ: no license in code itself, instead in document once
- Tim: what about pre-5378 content
- Russ: put disclaimer, no copyright, if anyone extracts, must be under BSD license; legend at end, pointer to TLP
- Cullen: copyright statement vs. license statement
- Russ: FIBs and MIBs statement is only copyright statement
- Dan: I only remeber ever seeing short version; not clear whether MIB/FIB is "fragment"
- Tim: "code component" well defined
- Russ: anyone object to me telling Trust we're OK with releasing to general comment
- Cullen: can't find email with this document: I promise to read it when I get it (Russ sent another copy)
- Russ: 30-day comment period required, can't start until we say OK to start it
- Cullen: unclear to me what "date" a document is posted; huge problem if license statement changes
- Russ: if we do that again, we have to repeat the 5378 process of asking authors
- Cullen: submission tool is letting through month-only
- Russ: I-D-announce archive is authoritative
- Cullen: problem if date on document differs; we need to enforce the date
- Russ: tool complained to me if it thought date was future or past
- Cullen: do you have diff output?
- Russ: everyone agree to one week to settle this?
- Amy: agreement to comment within one week (skipped doc stays in AD-followup)
7. Agenda Working Group News
- Jari Arkko (Internet)--- netext WG created (later than others), with BoF chairs
Lisa: didn't find announcement of public comment request in my folders
Amy: went out April 14, shows up in archives
Several: I got it
Jari: new-work and iesg sent separately from ietf-announce
Cullen: think I only got that one
Amy: when it was sent to ietf-announce list, I got itself; will ask Glenn to look into it
- Ron Bonica (O & M)--- ?? WGC stepping down; working with NANOG to propose items they suggest we work on (IETF was perceived as blackhole)
- Ross Callon (Routing)--- none
- Ralph Droms (Internet)--- none
- Lisa Dusseault (Applications)--- nothing
- Lars Eggert (Transport)---
- Pasi Eronen (Security)---
- Adrian Farrel (Routing)--- mpls-tp face-to-face next week
- Russ Housley (General)--- pass
- Cullen Jennings (RAI)--- couple of WGs having phone-call-interims
- Alexey Melnikov (Applications)--- pass
- Tim Polk (Security)--- pass
- Dan Romascanu (O & M)--- pass
- Robert Sparks (RAI)---
- Magnus Westerlund (Transport)---
1346 EDT Adjourned