Narrative Minutes

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative Minutes for the October 18, 2007 IESG Teleconference

Narrative Scribe: Spencer Dawkins <spencer@mcsr-labs.org>

With corrections from: Michelle Cotton, Russ Housley, Magnus Westerlund, Dan Romascanu, Jari Arkko, Lars Eggert

1. Administrivia

1.1 Roll Call

We welcomed Amanda, Michelle's backup from IANA

1.2 Bash the Agenda

No bashing took place.

1.3 Approval of the Minutes

2007 10 04 Minutes - approved with no discussion

2007 10 04 Narrative Minutes - approved with Magnus' update this morning, Spencer will submit

1.4 Review of Action Items

Lisa - RFC 3406 author - propose we don't need to update document, not limited to limited registrations

- Cullen - all certainly true, but no one has claimed 3406 is CLEAR, does not match our standard practice. not asking to resolve now, asking for clear guidance.

- Lisa - not VERY unclear, need a proposal

- Cullen - have already DISCUSSed based on unclarity and then moved to ABSTAIN. Will do this in the future. Agree with what people are saying now but don't think IESG should approve documents in violations of BCP text. Can have offline discussion

- Russ - "in progress"

Jari -When IESG can consider documents before last call - running code is that this is a BAD idea, will write text about this anyway

- Russ - please send text on the list before putting this into the Wiki

Dan to find a designated expert for draft-ietf-ipfix-info-15 - still in progress

Chris to draft a policy on Autoresponse Messages sent to any IETF mailing list - still in progress

2. Protocol Actions

2.1 WG Submissions
2.1.1 New Item
o draft-ietf-ipcdn-pktc-signaling-15.txt
Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) (Proposed Standard) - 1 of 5
Note: Jean Francois Mule is the PROTO SHEPHERD of the document
Token: Dan Romascanu

No DISCUSSes, document approved with no discussion on call.

o draft-ietf-avt-profile-savpf-11.txt
Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF) (Proposed Standard) - 2 of 5
Note: PROTO shepherd is Colin
Token: Cullen Jennings

Do have DISCUSSes, but Cullen thinks this is Revised ID Needed and we can add text to accommodate DISCUSSes. Magnus is right about inverted sentence.

Tim - won't be too hard to clear, don't need to discuss today

o draft-ietf-crisp-iris-dchk-07.txt
A Domain Availability Check (dchk) Registry Type for the Internet Registry Information Service (IRIS) (Proposed Standard) - 3 of 5
Note: April Marine is Document Shepherd.
Token: Chris Newman

Chris - inherited this from Ted, took a lot of time getting write-up, lack background.

Sam - mandatory to implement was BEEP/CRISP? document says "probably don't want to run this over BEEP" but doesn't say "need a new transport" - are we expecting people to tun this over BEEP? need to decide and have document match what we recomend. Please let me know if you read the document the way I do.

Lars - didn't DISCUSS, but people wrote the document preferring UDP.

Chris - needs to be clarified. Revised ID Needed.

o draft-ietf-lemonade-reconnect-client-06.txt
IMAP4 Extensions for Quick Mailbox Resynchronization (Proposed Standard) - 4 of 5
Token: Chris Newman

One DISCUSS.

Chris - would an RFC Editor note work?

Russ - absolutely, can clear on call (and he did, after seeing text)

o draft-ietf-tsvwg-udplite-mib-02.txt
MIB for the UDP-Lite protocol (Proposed Standard) - 5 of 5
Note: Shepherd by responsible AD: Magnus Westerlund
Token: Magnus Westerlund

Don't need to DISCUSS today, revised ID needed

2.1.2 Returning Item
o draft-ietf-magma-mgmd-mib-10.txt
Multicast Group Membership Discovery MIB (Proposed Standard) - 1 of 2
Note: Document Shepherd is Brian Haberman
Token: Jari Arkko

Couple of DISCUSSes.

Jari - Dan, we talked about whether this is revised ID needed or just RFC Editor notes (so won't get new issues inserted). Dave Thaler OK as long as he gets to review changes.

Dan - OK as well, was leaning toward Revised ID needed but that's OK

Jari - help me craft RFC Editor notes? If too big, will send to author.

Jari - Tim - deleting rows - Dan, is this typical?

Dan - let me read this and get back to you and author.

AD Followup, Dan and Jari will talk later, probably Monday.

Chris - I will keep watching for e-mail over next few days

o draft-ietf-sip-answermode-06.txt
Requesting Answering Modes for the Session Initiation Protocol (SIP) (Proposed Standard) - 2 of 2
Note: Keith is shepherd.
Token: Cullen Jennings

Sam - question here. I'm probably NO-OBJ either way, but concerned because we had people say that outbound media case should not be automatic, but other people saying market isn't going to respect that. If that's true, writing what people will ignore is not in our best interest.

Cullen - complicated, speaking as individual I've said in WG that this is written so everyone will violate security considerations but there are no use cases that drive this - even baby monitors aren't activated from far end.

Sam - then leave the text as is, if we believe that's what people are going to do.

Cullen - the current text is the hardest way to implement, people will just autoanswer, policy will be "if this comes from a trusted party, answer". Brought this up in WG, it's been discussed. If I wasn't the sponsoring AD, this wouldn't be a YES.

Sam - not imposed by IESG? it's good advice if you followed it. I can go NO-OBJ.

Cullen - need to go back to WG/Revised ID needed. Some stuff they need to fix (including Jon's DISCUSS)

2.2 Individual Submissions
2.2.1 New Item
o draft-narten-iana-considerations-rfc2434bis-08.txt
Guidelines for Writing an IANA Considerations Section in RFCs (BCP) - 1 of 1
Token: Russ Housley

Jon - YES, don't want to be odd man out.

Three DISCUSSes

Russ - is Chris happy with e-mail discussion?

Chris - may not have read last few messages. Probably will be happy unless text stays as it is

Russ - leaving to IANA's discretion.

Chris - will be happy

Dan - "not blocking but want to discuss" - saying specification required as distinct policy, but don't describe the most common case ("specifications originated by other SDO"). Not clear what "publicly available" actually is, clarification would help.

Michelle - "specification required" also requires expert review - couldn't tell if specification was "good enough" to support the registration. This is fixing a real problem.

Dan - will double-check by expert - policy is more clear.

Russ - Michelle is saying that judgement is required, and IANA wants us to identify judge

Sam - can describe "available" in an ION - probably best

Magnus - usually other SDOs

Chris - no, have seen vendors "free on website", but have also seen "free to customers"

??? - have discussed whether vendor-provided is good enough.

Mark - Michelle is telling me she's got primary, seconday, grouping, this is working, don't want to break this

Michelle - multiple experts is good but want one primary who is ultimately responsible.

Mark - if primary is unavailable you go to secondary after timeout?

Michelle - yes, L2TP experts ALL see the requests and someone responds. Lean toward this style because people get back to us.

Mark - issue is if primary has checked out of IETF or is on vacation

Michelle - do we need secondary for everything?

Cullen - no, AD is default expert.

Chris - have two experts with different expertise

Mark - Michelle would want to send to both

Russ - is change needed?

Mark - one plural, but most text says "expert" singular, doesn't describe what IANA should look for or how to name multiple expert

Sam - don't have BCP consensus for how to handle multiples

Tim - don't know that we need to go any farther than "name one primary" and use judgement beyond that - then everything else falls into place.

Mark - lay down one simple default, then there will be a discussion with IANA every single time about what this means. Have this dicussion every time I name more than one. Lay out one case so Michelle knows what's normal.

Sam - don't have BCP consensus for the details now.

Mark - don't have energy to argue. If Michelle says what she does most often and we think it makes sense, that would be a BCP. What's your indication there's a problem with a specific example? Harald and Thomas are only saying we need one expert, if Michelle is defining a single primary, why is that not BCP?

Sam - there's a point where discussions come to the same answer every time, but we're not there on this question. People are saying different things. I don't think we need consensus to get the document out.

Mark - agree, but if we propose something people will say "good enough"

Michelle - would like to see language that there's one person responsible. If we never ask questions again based on this text it's good enough to move forward.

Mark - always a primary, name secondaries if you want, IANA will contact secondaries

Sam - think this is a step backwards but I'm not going to move backwards. I should not lose because I'm not willing to DISCUSS. Someone needs to make a consensus call.

Mark - if Michelle says what she usually does and it makes sense, I think we'd have BCP consensus, IANA won't have to ask every time.

Sam - discussion needs to happen, hasn't been copied beyond authors. Russ as sponsor needs to ultimately judge consensus here.

Russ - need a little more dialog, first on IESG list and possibly wider after that.

Michelle - will send language, maybe that will make everyone happy

Mark - that would be great.

Sam - another question about Mark's DISCUSS. What changes are proposed for IESG evaluation?

Mark - had problems with wording, one actual bug (Harald called that) on AD sponsored documents. Document says "expedient path is through IESG", but has to go on telechat agenda, etc - not speedy. What does "call for comments" actually mean? Could get bitten here by someone appealing "call wasn't wide enough", generate lots of discussion about this.

Sam - proposed resolution?

Mark - Thomas asked how we do a call on a non-document

Russ - sending to Announce list should be good enough.

Sam - agree. Not necessary to say this but won't object

Russ - fine with announcement. Discretion to send elsewhere is where this should be.

Mark - IETF Announce list is catch-all - fine with me.

Michelle - so something like a straight forward codepoint assignment would go to public comments?

Mark - already there, "community should be consulted", but these are guidelines. Michelle has a good point - are we taking away discretion by writing this down?

Russ - Sam is arguing to retain discretion

Mark - don't want to take away discretion, but if we have this much discretion ...

Russ - sometimes we just need to do the right thing

Mark - losing strength on DISCUSS, clarifying is a good idea. Just add sentence about IETF Announce list being a good place to get comments. If you and authors think this is an improvement, then add it. Moving to COMMENT.

Michelle - so IANA can do a straight forward assignment with IESG approval and without going out to the IETF list?

Mark - "following guidelines"/"community should be consulted". It's a guideline.

Russ - AD followup.

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions

3.1.1 New Item
o draft-ietf-ippm-bw-capacity-05.txt
Defining Network Capacity (Informational) - 1 of 2
Note: Document Shepherd: Matt Zekauskas (matt@internet2.edu).
Token: Lars Eggert

Couple of DISCUSSes. Authors have sent e-mails, can resolve via e-mail.

AD Followup.

o draft-ietf-radext-rfc3576bis-11.txt
Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) (Informational) - 2 of 2
Token: Dan Romascanu

Two DISCUSSes .

Dan - shortly discuss one item (why document is Informational). WG chairs have history, basic specification is Informational and this is an update.

Tim - as long as WG has discussed this (several times)

Dan - has discussed, not worth the effort

Tim - second part of DISCUSS - security considerations cover component that's not even addressed in specification. Text was in 3576, so not blocking. Requires update to security considerations in RFC 2865 - what's the right answer here?

Dan - authors may have perceived issue differently and may not have understood impact of the statement

Tim - will have discussion with authors, will clear because text is carry-over

Sam - in common case, this path also goes to AAA server, proxy must be updated anyway. Not inherently true, but commonly true.

Tim - feel much better about security being in another specification. Not actionable DISCUSS. Interested in author feedback about Sam's deployment scenario.

AD Followup.

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD

3.2.1 New Item
NONE

3.2.2 Returning Item
o draft-tschofenig-eap-ikev2-15.txt
EAP-IKEv2 Method (Experimental) - 1 of 2
Note: There is no Document Shepherd.. Another doc to take back to telechat
Token: Jari Arkko

Jari is only DISCUSS holder. Expected no comments, got comments from EKR, and haven't heard from IANA if they are happy with text in RFC Editor Notes.

Michelle - we were happy with RFC Editor note

Amanda - yes

Jari - clears my DISCUSS. Responded to EKR with background, haven't heard back. Should be COMMENT, not DISCUSS.

Cullen - read whole thread and said NO-OBJ. Not a big fan of publishing things where there's no case to use new stuff over old stuff. Interesting, not saying "don't publish", but we should think about this. Very much a fan of IANA registrations pointing to documents that explain things.

Jari - agree, clearing DISCUSS, Approved, Point Raised

o draft-aboba-sg-experiment-03.txt
Experiment in Study Group Formation within the Internet Engineering Task Force (IETF) (Experimental) - 2 of 2
Note: No document shepherd.. Need to bring this back to the telechat
Token: Jari Arkko

No DISCUSSes - Jari wants to talk.

Jari - certain amount of e-mail, is there sufficient consensus to go ahead with experiment (since it's not a permanent change). New text deals with some of this, don't think I know there's consensus.

Mark - maximum number of SGs? (yes) Collison with SGss?

Jari - saw this on list

Mark - IAB list leaning toward renaming as preference

Loa - didn't take a vote, but this isn't blocking

Lisa - name it what?

Mark - Exploratory Group - better than what's on IETF list

Jari - sounds a little like IRTF.

Sam - ITU collision is the big problem. IEEE collision is "don't change this".

Loa - SG is equivalent to an IETF area

Mark - even though there are a lot more SGs in ITU than areas - we often liaise between IETF WGs and ITU-T SGs.

Jari - is this a blocking comment? If not, will tell authors about input and ask them to think about names.

Sam - Jari needs to make a consensus call based on discussion, if no one is going to DISCUSS here

Mark - getting IAB discussion now

Sam - if IAB didn't send comments outside IAB, there's a limit. No formal feedback is no formal position.

Mark - but 2/3rds of people had opinion and even had a name. No reason to ignore this, it's information.

Jari - wouldn't think there is any consensus based on IETF list

Mark - if this is potentially deciding, go back to IAB and clarify. Can send e-mail for you

Jari - there was a discussion, but our response on last call didn't mention name change. Didn't object or support the idea, but discussion took place on IAB list later. We're to blame here.

Mark - given that IAB is responsible for liaison relationships, listen to them before you make a decision. And IAB should weigh in

Ross - chances of ITU-T getting confused by collision is actually pretty good

Jari - hearing this is important, will discuss with authors.

Mark - think IAB should be checkoff for the name

Jari - not easy to agree on names in public list. asking IAB to sign off on name would be OK.

Loa - name offered didn't raise eyebrows (exploratory group) - discuss with authors

Jari - will discuss with authors, with IAB. Will DISCUSS to hold up approval.

3.3 Independent Submissions Via RFC Editor

3.3.1 New Item
NONE
3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
o Performance Metrics for Other Layers (pmol) - 1 of 1
Token: Dan Romascanu

Russ - did Dan see IESG comments on list? Should we do cleanup before sending out?

Dan - not sure what to clean up

Magnus - taking a wider scope than the text reflects

Dan - what to change? BOF is "not only applications", but session-oriented stuff, too.

Russ - all kinds of carriage returns where they shouldn't be, at least in the e-mail. Paragraphs broken up, etc.

Magnus - do have a general problem about text for charter discussions here

Dan - will work on format change, will use simplest format I can

Russ - problem is when you go past column 72 and then extra line breaks get inserted

Cullen - would really like to support Magnus - provide DIFFs, use a sane format (this is general comment)

Dan - authors tried to add test about motivation of the work (issue Lars raised) and work elsewhere in IETF

Lars - paragraph hasn't actually changed much. This is stuff we should know before we charter. Would like to have answers to charter questions shaping the charter

Dan - don't think second BOF would help

Lars - don't want to push to second BOF. Third item sounds like they get to provide own charter, this stuff is what we should know when we approve a WG.

Dan - <horrible things happened on voice quality about here> frame of document tries to explain starting this work, provide criteria for identifying and evaluation of metrics. authors kind of intended this for informational purposes, not for action. Will work with them

Jari - so they actually DO know how this fits with IETF chartered work? Wanted to make sure this didn't sound more like an SG (EG).

Dan - will fix this and see if it makes sense so work can move forward. Will work in next three days and send to IETF review

Approved pending edits.

4.1.2 Proposed for Approval
o HyperText Transport Protocol Bis (httpbis) - 1 of 1
Token: Lisa Dusseault

Any objection to creation?

Russ - WG needs to be renamed from Transport to Transfer. Can create with one chair, and then add another later.

Cullen - lot of feedback about how open charter was for adding new features, got this at last call time. Surprised this isn't showing up

Lisa - inconclusive, no improvements suggested

Sam - Ted suggested "no new methods or headers"

Lisa - I missed something here. I'm behind the ball on this one. "Not tasked with" is ambiguous

Sam - others of us were confused - Ted suggested "no new methods or headers"

Lisa - but he also suggested "not tasked with", does not mean "not allowed to".

Sam - sounds intentional

Lisa - was, and I agree with him for same reason as Magnus (although I couldn't think of better test)

Russ - does anyone object?

Cullen - got "trust us, we'll fix this" last time. Would like to see actual text - I'm lost here.

(looking at modified text in Jabber)

Cullen - but everything proves to be problematic

Lisa - Julian thinks anything that breaks a very old server can't be done in the IETF - you can never make any changes at all

Cullen - "consider existing implementation" -

Lisa - can go back to previous text, was also happy with that. If we are still discussing this, second BOF in Vancouver

Cullen - do you think your text means the same as Ted's? Lower-case may/should doesn't have a lot of weight here. Mailing list assumed working group would be doing some of this, but wouldn't be doing much of it. Saying "A/not A" in the same document. Will shut up about this, but concerned that this is being pushed through.

Lisa - no one has suggested an override, not happy about this situation.

Sam - not making a blocking comment, but looks like IESG-minus-Lisa prefers Ted's text.

Lisa - I'm OK with Ted's original text

Sam - you've convinced me that I don't know what Ted's text means. Either is better than original text.

Cullen - am OK with this, you're the one who has to deal with this, your call.

Russ - OK to approve this text as charter? No objections.

Approved on this call.

4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
o Common Control and Measurement Plane (ccamp) - 1 of 2
Token: Ross Callon

Changes are to include GELS work (control plane for Ethernet). People have been talking about this for at least a year, maybe two. Held GELS BOF, thought we shouldn't do this, but got cooperation with IEEE and it turns out there's not much work to do - one document, would fit in CCAMP. Added TDM as example in charter (was already in the work, just not in the charter).

External review?

Ross - not controversial (any longer), don't think this needs external review.

Mark - did have conversation a while back, had understanding GELS would go Experimental. What happened? It's standards-track now.

Ross - there was discussion about what is IEEE data plane, since devices have different capabilities. IEEE has clarified what the data plane is, so Experimental is less necessary.

Loa - CCAMP expects standards-track

Ross - agree, not sure I would have said that a year ago.

Loa - pretty much everyone is on the same page here.

Ross - how long ago were discussions?

Mark - February of this year? at MPLS conference? ANYway, if I've been out of the loop, I'm not going to insist on Experimental. Problem I've got is that Loa's test network was driving this, felt experimental would be more useful.

Loa - kind of true, actually two documents. Once we got response back from IEEE things moved quickly, work has started on design team.

Mark - how did you get feedback from IEEE?

Loa - liaison earlier this year. Got some comments and response back from IEEE. 802.1 had no objections. They also pointed out that they don't have any plans to do the same thing at this time.

Mark - much more comfortable now. Will accept on faith.

Loa - even if we do standards-track work here, I can still publish Experimental based on my test network.

Magnus - are we cleaning charter up with old work?

Ross - people wanted to see DIFFs, showing old TO-DOes, assumed secretariat would remove these

Russ - that's you're job

Ross - I can do that. Assume we do that now? Secretariat sends out for review?

Russ - correct.

Amy - yes, and we'll have this on November 4 telechat for approval

Mark - Dward comments in jabber - concerned?

Dward - will make comments with Ross before this goes out for review (shooting for Tuesday to secretariat)

o Audio/Video Transport (avt) - 2 of 2
Token: Cullen Jennings

Adding one bullet point and corresponding milestone. Does this need IETF review? simple change around complex package.

Jari - just one milestone, is that really right?

Cullen - one ADDITIONAL milestone, with corresponding text

Magnus - need to recuse on sending out, I'm the proponent, don't want to push this through IESG

Cullen - not controversal

Russ - just approve?

No objections. The revised charter is approved without need for external review.

4.2.2 Proposed for Approval
o Dynamic Host Configuration (dhc) - 1 of 2
Token: Jari Arkko

Objection to rechartering?

Jari - have gotten some support and one issue from Dave Harrington about cutting security stuff. I'm still happy and other people are too. Dan?

Dan - have some feedback about Dave's comments, since DHCP is used for configuration. He's sayng that by approving kind shows lack of consistency between different configuration protocols. I believe this can vary from case to case. Will not oppose.

Jari - certainly is a decision we've taken seriously. Had this in previous version, but work on this is pretty minimal.

Dan - reached conclusion that deployment is always in constrained environment?

Jari - DHCP deployment most certainly does NOT happen in controlled environment, but there are mechanisms to secure your networks - remaining work isn't interesting and it would be hard to make DHCP "secure".

No objection to chartering, changes are approved

Jari - please look at formating, but actual content is OK for posting

o Network File System Version 4 (nfsv4) - 2 of 2
Token: Lars Eggert

Objections to rechartering?

Chris - not objection, but a niggle - charter mentions XDR, question need to advance on standards track.

Lars - pulling recharter from the agenda until the three documents currently with the IESG are approved

5. IAB News We can use

Loa

- providing text in Jabber room. Thinking about incoming liaison reports, probably need to do something to organize this, we get reports at varying frequencies.

- IAB representative for ICANN board has been chosen

- becoming an ISO approved reference organization so they can reference our RFCs without explaining how this works

- agreed on name for IETF liaison to ITU-T NGN, will be announced over coming week

- IAB decided to set up T-MPLS design team to sort out what needs to be done. have already seen some names proposed this mornng. Hope to have this done in week-to-10 days

- Russ - thanks for agreeing to lead this

- Loa - don't know that I actually agreed :-)

6. Management Issue

6.1 ion-2026-practice.html (Russ Housley)

Brian has made suggested changes. Surprised if I hear comments.

Chris - URL with trailing slash, delete that and I'm fine.

Russ - Can Cullen fix this? (yes)

Approved on this call.

6.2 On Appeals of IESG and Area Director Actions and Decisions (Russ Housley)

Made statement two weeks ago, Ted asked about posting as starement, people have made other suggestions but don't think we should post different text from e-mail statement.

Sam - consider me as strong but not blocking opponent of posting, if there's consensus to post

Russ - poll the group?

Sam - who wants to post?

Russ polling the group on exactly the same text... polled consensus is 7 post, 6 no-post (could it be any closer?) comparing strong and weak positions... any opposed?

Magnus - concerned about insufficient context

Russ - I understand. However, we are running out of time on today's call, so I'm leaning toward bringing this back on the next agenda. The half-and-half results from polling bothers me, and this will probably not be resolved quickly.

Chris - move to weak opposed if it won't come back :-)

Russ - Do others feel like Chris?

(several people voiced that they did)

Russ - Approve as it is?

No objection. The IESG Statement will be posted.

6.3 IANA question for wave-avi-codec-registry [IANA #97962] (Michelle Cotton)

Creates an action item for Cullen - he's working on this, please create the action item.

Cullen is trying to get response from AVT working group to resolve a registration issue.

6.4 Approval of ion-ion-store (Cullen Jennings)

Name of web server changed, so URL changed. Need to change this, any objections?

Russ - just lining up with reality?

Cullen - yes, URL won't resolve, that's the only change. Brian did it, Bill checked it, I diffed and checked it in.

No objections - approved on this called.

7. Agenda Working Group News

Jari Arkko

LISP futures (LIFE) BOF discussion with the proponents in NANOG this week, made forward progress beyond what we got in e-mail, moving beyond organization to discussing what exactly is needed for the ideas to go forward: conceptual problems need to be solved, experiments performed, etc. Current idea is to do this within the RRG. Didn't conclude discussion and didn't get a chance to talk to Tony Li, but will have more discussions in RIPE.

Private meeting with SAVA guys and came out with good resolution and reasonable proposal - a practical thing we can do for both IPv4 and IPv6

Lisa Dusseault

ATOMPUB is closed

Lars Eggert

TSV has gotten a liaison statement from ITU-T SG13, which notifies us that they have completed the requirements for Y.flowreq. The same liaison also went to SG12 for their information and SG11 to request that they start developing protocol extensions for Y.flowreq. The protocols that will need changing are mostly IETF ones. There is a potential for conflict between the IETF and ITU-Y here; we'll need to send a liaison response and track this closely.

Russ Housley

IPR working group arguing about PR actions, will probably come our way