Subject: [drinks] Interim notes on interim meeting

From: Dean Willis <[email-masked]>
Date: Wed, 1 Feb 2012 09:59:24 -0600

I scribed notes for first half of meeting:

notes-drinks-interim-20120131
by Dean Willis

Document points:

Framework 5.2.2.2 Derived Object Key Types has a"there" where it needs a "their".

Chaired byAlex Mayrhofer, Sumanth Channabasappa <[email-masked]>

Note Well presented

Agenda accepted as presented.

Plan to change milestone to submit last documents to IESG by April. This requires "advanced" versions of docs by mid March for last call. NOted that cutoff for Paris is March 12.

Proposed that we review current drafts by having most recent editor (Vikas) talk through major changes. Most of the recent changes were "housekeeping" or minor soiling fixes.

Vikas provided a summary based on his recent email to the list.

Suggested that we look at "to do" list and use that as a basis for further discussion. It turns out we don't really have one … Discussion ensued

Proposed by chair that we go through document quickly and build a to-discuss list.

Noted to-do items
1) Change egress node
2) Internationalization
3) Internal consistency on terminology and structure
4) Framework 3.1 logical structure diagram and XSD alignment; remove "extension" from digram, handle extension consistently in XSD.
5) Clarify uniqueness of object-type names.
6) Determine whether route-group offer can be generalized to object-offer.
7) Consider generic identifier type in Public Identifier
8) Removing "priority" attribute from RteRecType.
9) Add isInSv cattribute to RteGrpType

Poll: How many people have read a ref since last IETF meeting?

Framework: About a dozen
Protocol: about a dozen

Iterative discussion of Framework follows

3.1 Framework Data Model

David noted some inconsistency between schema diagram and actual XSD, about resource references. Also issues with route group definition, and "extension" on Public Identifier. The reef is on the wrong object.

Discussion: What is the purpose of this digram? Is it a logical reference, or a description of the XSD. Proposed that it is a higher-level concept. So, how much data to include in the diagram?

David asked to send his compiled "list of nits" to the list.

Section 5.  Base Framework Data Structures and Response Codes

Proposed that 5.2 Various Object Key Types be renamed Object Relationships or Data Identity. Perhaps under 5.2 we should have introductory text.

Proposed that Section 5 is also the right spot for string comparison and upper/lowercasing rules. Alex could send text. Or we might just keep this in a separate internationalization section.

Does object name need to be unique within scope? Probably yes; need to clarify in text.

Discussion around relationship between tntype and route rec vs route group. Why can't we share any objKeyType? What is an offer of a Registrant type good for? But we might want to offer destination groups. Much discussion ensued … No conclusion

Could carrier of record be elevated into the parent type, non-mandatory? Ans. Probably not, as we might need types for which COR is irrelevant.

Could we have a more generic (not TN) identifier in Public Identifier? Possibly. Might use a base type with number or string.

David Schwarz reiterated concerns (from mailing list and design group) about problems with pointing TNType to a RteRecRefType  instead of a route group making his peering decisions difficult. It basically makes the route grouping mechanism useless. Other uses cases he raised suggest that it might be better to have a generic offer type.

Section 6.3 Route Group

David praised use of route group ref and asked for consistency with this in other structures.

Discussion: What is relationship between route priority, route group priority and route group ref priority? Should we remove priority attribute from RteRecType? Discussion shows a consensus to remove this attribute.

Discussion: Should "in service" attribute be on RteRecType instead of RteGrpType?? Consensus says "probably" should be on both.

Going to break...