IESG Narrative Minutes

Narrative Minutes of the IESG Teleconference on 2017-10-26. These are not an official record of the meeting.

Narrative scribe: John Leslie, Susan Hares, and Ignas Bagdonas (The scribe was sometimes uncertain who was speaking.)

Corrections from:

1 Administrivia

1.    1003 EDT Amy: Call to order; attendance from WebEx Participants list:

o   Alia Atlas---

o   Ignas Bagdonas---

o   Deborah Brungard--- regrets

o   Ben Campbell---

o   Benoit Claise---

o   Alissa Cooper---

o   Michelle Cotton---

o   Spencer Dawkins---

o   Heather Flanagan--- regrets

o   Sandy Ginoza---

o   Ted Hardie---

o   Susan Hares--- regrets

o   Suresh Krishnan---

o   Mirja Kühlewind---

o   Warren Kumari---

o   John Leslie---

o   Terry Manderson--- regrets

o   Alexey Melnikov---

o   Cindy Morgan---

o   Kathleen Moriarty---

o   Ray Pelletier--- regrets

o   Carlos Pignataro---

o   Eric Rescorla---

o   Alvaro Retana---

o   Adam Roach---

o   Amy Vezza---

o   Suzanne Woolf--- regrets

o    

o   Amy: We are still missing a few people, will wait another minute.

o   Amy: I see most of the people on Webex. Starting for today. Meeting is being recorded. Roll call. We have received regrets from Deborah and Terry, possibly regrets form Suzanne. Of the people we are expecting, we are missing EKR, hopefully he will join us.

o    

2.    Guests:

o   (none)

3.    Observers:

o   (none)

4.    Bash the Agenda

o   Amy: Does anyone want to add anything new to today’s agenda? Nothing. Any other changes to today’s agenda? Nothing.

o    

5.    Approval of the Minutes of the past telechat

o   October 12 minutes---Amy: Does anyone have objections to the minutes of October 12 teleconference being approved? No objections, will get posted in public archive.

o   October 12 narrative minutes--- Amy: I did see revised narrative minutes coming through a while ago, is there any objection approving revised narrative minutes? No objection. Will get posted in public archive. The last set of minutes is the BoF coordination minutes. Is there any objection? We have received no corrections of clarifications to those. No objections. Will get posted on the web page for minutes for 2017 under BoF coordination call minutes section.

6.    Review of Action Items from last Telechat

o   Deborah Brungard to find a designated expert for RFC-ietf-pals-status-reduction [IANA #983681] 

o   Amy: This is on the agenda for later today for approval of the experts. It is provisionally done given those experts are approved.

o   Terry Manderson to find a designated expert for RFC-ietf-anima-grasp [IANA #983682] 

o   Amy: Next one is for Terry who is not with us today, skipping.  

o   Alexey Melnikov to find a designated expert for RFC-ietf-slim-multilangcontent [IANA #983757] 

o   Amy: Alexey, is that still in progress?

o   Alexey: Yes.

o   Amy: Thank you.

2. Protocol actions

2.1 WG submissions

2.1.1 New items

• Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols that use Connectionless Communications (Proposed Standard) 
  draft-ietf-lime-yang-connectionless-oam [txt] 
  Token: Benoit Claise (ops area) 
  Discusses/comments [ballot]:
• Ben Campbell: Comment [2017-10-25 18:26 PDT]: 
  
• Kathleen Moriarty: Comment [2017-10-23 07:19 PDT]: 
  
• Alia Atlas: Discuss [2017-10-25 09:16 PDT]: 
  Thank you for your work on this document. I have a number of serious concerns - but they all amount to fixing up your references and slight restructuring for clarity and reuse. 
  1) In Sec 3.1, the reference is system-id to represent the device or node.[I-D.ietf-spring-sr-yang] 
  I believe that should be 
  'typedef router-id { 
  type yang:dotted-quad; 
  description 
  'A 32-bit number in the dotted quad format assigned to each router. This number uniquely identifies the router within an Autonomous System.'; 
  }' 
  from draft-ietf-rtgwg-routing-types. 
  Certainly '[I-D.ietf-spring-sr-yang]' is NOT an informative reference with such a dependency. 
  I see that this document actually redefines router-id, instead of using it as part of the included import from import ietf-routing-types { 
  prefix rt; 
  } 
  On p.27, I see 
  'leaf system-id { 
  type rt:router-id; 
  description 
  'System ID assigned to this node.'; 
  }' 
  so it is using the routing-yang-types, but renaming it as system-id, there. Consistency isn't just the hobgoblin of little minds - it's actually useful. 
  In choice to-location, again 
  'case system-id { 
  leaf system-id-location { 
  type router-id; 
  description 
  'System id location'; 
  } 
  description 
  'System ID';' 
  using the locally defined router-id and renaming it instead of using rt:router-id. 
  2) On p. 13 & 14, there are many identities associated with time and time-stamps. I cannot believe that the best way to handle these is by having them as part of an OAM model! At a minimum, they should be defined as a separate module and then included, even if it is in the same draft. Then they will be available for reuse elsewhere. 
  3) This is extending [I-D.ietf-i2rs-yang-network-topo] - I do not believe this should be merely an informative reference. 
  4) I cannot tell if I-D.ietf-rtgwg-ni-model is informative or normative; it is not referenced in the draft - though there are fields that are labeled NI without adequate description. 
  5) [I-D.ietf-rtgwg-routing-types] is not an informative reference. Its module is imported and used. It must be normative. 
  6) [I-D.ietf-spring-sr-yang] is listed as an informative reference, but if it were actually used as described, it would need to be normative. Instead, I believe this can be removed as a reference.
• Alia Atlas: Comment [2017-10-25 09:16 PDT]: 
  
• Eric Rescorla: Comment [2017-10-24 17:19 PDT]: 
  
• Adam Roach: Comment [2017-10-25 12:19 PDT]: 
  
• Alissa Cooper: Comment [2017-10-25 17:29 PDT]: 
  

Telechat:

• Amy: Version 14, PS, token is Benoit. It came out of LC yesterday. I have a DISCUSS, do we need to discuss this?
• Benoit: I am not sure. Before addressing this, Adam, I have been thinking about what you said about the readability of the document. This has been on my mind for two LIME documents. I have got document shepherd who will spend some time to improve the readability of both documents. He committed to do that before IETF100. That is Carlos. Thanks for the list of points that can be mechanically applied.
• Adam: That would be a great improvement.
• Benoit: Alia, on your DISCUSS. I have an impression that everything is taken care of. We need a new version of the document.
• Alia: That is my impression too. That is straightforward.
• Benoit: On augment.
• Alia: It is already doing that. I recognized the model - how it is structured. Adding things to the node from the I2RS network topology model, if I misspoke, all I meant that it needs to be a normative reference.
• Benoit: Status should be revised ID needed.
• Amy: Revised ID needed.

 

• Retrieval Methods YANG Data Model for Connectionless Operations, Administration, and Maintenance(OAM) protocols (Proposed Standard) 
  draft-ietf-lime-yang-connectionless-oam-methods [txt] 
  Token: Benoit Claise (ops area) 
  Discusses/comments [ballot]:
• Kathleen Moriarty: Comment [2017-10-23 07:47 PDT]: 
  
• Alia Atlas: Discuss [2017-10-25 10:43 PDT]: 
  1) on p. 19: ' leaf status-code { 
  type identityref{ 
  base status-code; 
  } 
  mandatory true; 
  description 
  'Error code for continuity-check message, that is relevant to the protocol under use for CC. For example if ICMP is the protocol under use, the error codes are as defined in [RFC4443].'; 
  }' 
  I am quite unclear on how this could technically be used?? RFC4443 defines integer error codes or types and sub-codes that are also integers. 
  Is the expectation that an ICMPv6-specific YANG module will define those codes as identityrefs??? 
  Clarification in at least the description is needed, since I don't see how it could be used as currently defined.
• Alia Atlas: Comment [2017-10-25 10:43 PDT]: 
  
• Eric Rescorla: Comment [2017-10-24 17:35 PDT]: 
  
• Adam Roach: Comment [2017-10-24 23:34 PDT]: 
  
• Alissa Cooper: Comment [2017-10-25 08:13 PDT]: 
  

Telechat:

• Amy: We have a DISUCS here, is that a similar issue?
• Benoit: This is a different issue. I would like to discuss with Alia. Your DISCUSS is about status codes. Initially they had status codes. With LIME we may have different OAM protocols. If you want to have meaningful status codes, we must return the one that is protocol specific, that is why there is an identity ref there. We should have a link to protocol specific status code. This is the intent. I am not seeing the author replying to your DISCUSS, but that was the goal behind this identity ref.
• Alia: What was not clear to me whether the identity ref is going to be sufficient vs the value of. My concern is this will be fine if all the actual OAM protocols having associated YANG models and having those connected up. My concern was on description that it is going to use these status codes. It is an identity ref and those are integers.
• Benoit: You mentioned that OAM protocol must support YANG and they should have a list of error codes. Both are true. If we want to use LIME to use OWMAP or two way SLA protocol, we do not want to define those error codes in this document. We will have identities for TWAMP or OWAMP in the YANG module, and we reference the status code from those protocols.
• Alia: That could be fine. One of my thought was it would be useful to have a way even if the protocol returned back numeric values for protocols that are not being modelled. It may be being more useful in the short term because of the dependency considerations.
• Benoit: I think I see what you mean now.
• Alia: I think I did miss some of the nuances of what was intended with the identity ref. My concern is if one had an ability for status code to either refer to YANG model that has actual identity refs, or to bluntly provide integer codes that are defined if there is no acceptable YANG model. I also understand the concerns regarding energy and go with what seems to be practical.
• Benoit. I am not sure how I could model that with YANG. You want a way for protocol for which there is no YANG module to be able to retur a status code. They have to be somewhere somehow referenced to IANA or to a spec?, and I am unsure how to model that. This is a code coming from registry somewhere there.
• Alia: You are going to say that it is a hack. Having an ability to refer to two uint32s for status code and subcode, if you have no better place you can refer to those. If you think of cleaner way of going through IANA that would be fine. It would be more likely to be used sooner if it does not have a dependency on having YANG models of every type of OAM that may be used.
• Benoit: Let me push back on it. If you are using LIME YANG module, you are dealing with YANG. If you want to support TWAMP which does not have a YANG module yet, the only thing you need a YANG module with identity for return codes for TWAMP. That is a small module. You do not need to have full support of YANG module for TWAMP. Just import the error codes. That is all you need.
• Alia: If I want to use RPCs to trigger it remotely as that is a useful capability. I do not feel strongly about this point. I had misunderstood how the identity ref piece would work. If you think it is not really going to hammer. I know how long implementations of new modules may take.
• Benoit: Can I ask you a favor – to restate your DISCUSS based on what we are discussing now. I would like to find an actionable piece of information for the authors. If we do not update the DISUCSS now we will have the same discussion again.
• Alia: I would be happy to do so. Two pieces. One is usage clarifying how it works, I missed some of the subtlety for the identity ref. Second – is there a straightforward way for handling OAM mechanisms that do not have YANG modules that define status codes to minimize the dependencies.
• Benoit: The status should be AD followup.
• Amy: IESG evaluation, AD folowup.
• Benoit: There are some more comments, I want to make sure they are addressed too.  
•  
• Resource-Oriented Lightweight Information Exchange (Proposed Standard) 
  draft-ietf-mile-rolie [txt] 
  Token: Kathleen Moriarty (sec area) 
  Discusses/comments [ballot]:
• Ben Campbell: Discuss [2017-10-24 19:10 PDT]: 
  -5.1.3: 
  I don't think Martin's ART-ART review concern (and Mark's support) about the .well-known URL registration has been fully resolved. While version 11 removed some of the well-known registrations, it still leaves the one. Mark pointed out that RFC 5785 offers explicit guidance that .well-known URLs are intended to offer site-wide policy or metadata, and are not intended for general information retrieval, or to establish a namespace. This usage seems to me to be exactly the sort of thing that the RFC advises against. 
  I recognize that security information is important, but I don't understand why it's discovery needs to be fundamentally different than for other stuff on using ATOM. I'm willing to be convinced, but if there's been a convincing argument so far I've missed it. 
  I'm not sure what to make of the second paragraph. It says DNS SRV can be used to determine the host and port. Is the expectation that people can just do that without further specification, or that someone could specify it in the future? The former is generally not true. If the intent is the latter, please clarify that in the text.
• Ben Campbell: Comment [2017-10-24 19:10 PDT]: 
  
• Alexey Melnikov: Discuss [2017-10-26 04:36 PDT]: 
  This is a useful document and I will be balloting 'Yes' once the following small issues are resolved/discussed (some of these come from Martin's ARTART review): 
  1) 7.4. The 'rolie:property' Extension Point 
  urn:ietf:params:rolie:property:content-id The 'value' attribute of this property is a text representation of an identifier pertaining to or extracted from the content referenced by the 'src' attribute of the entry's atom:content element. 
  Maybe it is just me, but I can't figure out what is the syntax of this field. Can you provide a reference or at least give an example? 
  2) From Martin's review: 
  Section 5.5 prohibits the use of GET on '/'. This prohibits use of the resource for other purposes. It seems reasonable to accept POST messages as defined in RFC 6546, but this requirement is overly strict (and further entrenches the violation of RFC 7320). If, for instance, the server operator wishes to provide HTML in response to a GET request to '/', this would prohibit that. The requirement to return 404 if RFC 6546 is not supported is worse; not supporting RFC 6546 might be a choice that a deployment makes to avoid the need to reserve '/' for that protocol. 
  Alexey: The text in -12 is an improvement, but I think it is still confusing. Maybe mention something along the lines of Martin's suggestion for the case when RFC 6546 is not supported (or at least not followed as far as the '/' resource is concerned). 
  5.5. / (forward slash) Resource URL 
  If the '/' resource is unsupported, then a request for this resource MAY be handled as deemed appropriate by the server. 
  Nit: You haven't expressed any requirement on implementations here, so use of MAY does not seem appropriate. What are you actually suggesting here? 
  3) I think some of the text in 6.1.2 is misleading (or I might be wrong): 
  "Based on RFC5005 section 3 [RFC5005], link elements SHOULD be included in all Feeds to support paging using the following link relation types:" 
  o 'first' - Indicates that the href attribute value of the link identifies a resource URI for the furthest preceding page of the Feed. 
  o 'last' - Indicates that the href attribute value of the link identifies a resource URI for the furthest following page of the Feed. 
  o 'previous' - Indicates that the href attribute value of the link identifies a resource URI for the immediately preceding page of the Feed. 
  o'next' - Indicates that the href attribute value of the link identifies a resource URI for the immediately following page of the Feed. 
  Original definitions of these link relations don't include the word 'page'. I should double check with Mark Nottigham, but I think they reference the next/previous, first/last entry, not page. (And a page may contain several entries.) If I am correct, I don't think it is Ok to redefine meaning of existing link relations the way you do. 
  4) In Section 8.3: 
  "Registration in the ROLIE URN Parameters registry is via the Specification Required policy [RFC8126]. Designated Expert reviews should be routed through the MILE WG mailing list. Failing this, the Designated Expert will be assigned by the IESG." 
  As other people already pointed out, the last 2 sentences are confusing. Are you trying to say that registration requests must be sent to the MILE mailing list or that they must be reviewed there? This is actually significant for IANA workflow. 
  One possibility is that all requests are sent to the MILE mailing list and then the designated expert forwards approved requests to IANA. In this case if a Designated Expert misses a request, IANA wouldn't even know that the requester is waiting for the Designated Expert. 
  Another possibility is for all requests to be submitted to IANA directly, then IANA can track them. IANA might either forward requests to the MILE mailing list or require that all request being submitted to the MILE mailing list first before being sent to IANA. 
  So please clarify.
• Alexey Melnikov: Comment [2017-10-26 04:36 PDT]: 
  
• Eric Rescorla: Comment [2017-10-20 13:29 PDT]: 
  
• Adam Roach: Discuss [2017-10-24 21:02 PDT]: 
  I agree with Ben, Martin, and Mark: the way this document uses /.well-known/ URIs is not consistent with RFC5785, section 1.1. It should be understood that /.well-known/ URLs are already a carve-out from overall REST principles regarding the agency of content publishers to assign URLs within their domain as they see fit; and, as such, need non-trivial justification for their use. 
  If there were some fully-defined autodiscovery mechanism that were (non-artificially) constrained in such a way that only a host and port were available, then the use of /.well-known/ URIs would be more understandable. The only constraint hinted at in this document that might have these properties is the use of DNS SRV records. Given that ROLIE is defining a green-field protocol, the use of something as constrained as SRV seems ill-advised, given that the use of NAPTR records would trivially allow retrieval of a complete URL instead of just a host/port combination. 
  The bottom line, however, is that we need to defer specification of a /.well-known/ URL until we completely define a discovery protocol that requires it. The corollary is that we should avoid defining a discovery protocol that requires it.
• Adam Roach: Comment [2017-10-24 21:02 PDT]: 
  
• Alissa Cooper: Comment [2017-10-25 07:41 PDT]: 
  

Telechat:

• Amy: Version 12, PS, token is Kathleen. I have a quite a number of DISCUSSes for this document. Kathleen, do we need to discuss?
• Kathleen: I do not think so. Editors have been responding and updated the document. Will see if that addresses the DISCUSSes. Unless anyone disagrees?
• Adam: It is not clear whether the use of .well-known is acceptable here. Me, Ben, Alexey can talk offline.
• Kathleen: I would appreciate that. It is not something I am an expert on.
• Ben: Peter has a different issue.
• Alexey: If we need to have a short face to face discussion we can do that in Singapore.
• Amy: Revised ID needed.
•  
•  
•  
• Happy Eyeballs Version 2: Better Connectivity Using Concurrency (Proposed Standard) 
  draft-ietf-v6ops-rfc6555bis [txt] 
  Token: Warren Kumari (ops area) 
  IPR: Apple Inc.'s Statement about IPR related to draft-ietf-v6ops-rfc6555bis 
  Discusses/comments [ballot]:
• Mirja Kühlewind: Comment [2017-10-23 03:59 PDT]: 
  
• Alvaro Retana: Comment [2017-10-24 10:20 PDT]: 
  I completely agree with Adam's Ballot. [I was in the process of writing something similar, so I'm happy he beat me to it.]
• Ben Campbell: Comment [2017-10-24 19:30 PDT]: 
  
• Benoit Claise: Comment [2017-10-19 02:58 PDT]: 
  
• Eric Rescorla: Comment [2017-10-20 13:45 PDT]: 
  
• Adam Roach: Comment [2017-10-23 17:58 PDT]: 
  

Telechat:

• Version 06, PS, token is Warren. I have no active DISCUSSes, unless there is an objection, this one is approved. Hearing no objection. Warren, there are no notes needed, is this ready to go?
• Warren: I believe it is.
• Adam: Warren, I had some comments on normative language describing the the algorithm itself.
• Warren: Let’s keep it in point raised.
• Adam: Thank you.
• Amy: Approved, announcement to be sent, point raised, writeup needed. Warren, let us know.
• Warren: Thank you.
•  
•  
• Cleartext Considered Obsolete: Use of TLS for Email Submission and Access (Proposed Standard) 
  draft-ietf-uta-email-deep [txt] 
  Token: Alexey Melnikov (art area) 
  Discusses/comments [ballot]:
• Alvaro Retana: Comment [2017-10-25 07:28 PDT]: 
  
• Ben Campbell: Comment [2017-10-24 20:00 PDT]: 
  
• Benoit Claise: Comment [2017-10-22 05:59 PDT]: 
  There are still some points that need to be discussed part of Carlos' OPS DIR review.
• Mirja Kühlewind: Comment [2017-10-23 07:49 PDT]: 
  
• Kathleen Moriarty: Comment [2017-10-23 08:04 PDT]: 
  
• Eric Rescorla: Comment [2017-10-20 10:59 PDT]: 
  
• Adam Roach: Comment [2017-10-23 20:43 PDT]: 
  
• Alissa Cooper: Comment [2017-10-24 13:54 PDT]: 
  

Telechat:

• Amy: Version 09, PS, token is Alexey. No active DISCUSSes, unless there is an objection, this is approved.
• Alexey: This will definitely need a new revision, the editor has something pending.
• Amy: Approved, announcement to be sent, revised ID needed. Alexey, let us know when it is all set.
•  
•  
• Network Configuration Access Control Module (Internet Standard) 
  draft-ietf-netconf-rfc6536bis [txt] 
  Token: Benoit Claise (ops area) 
  Discusses/comments [ballot]:
• Alexey Melnikov: Comment [2017-10-25 08:17 PDT]: 
  Thank you for a well written document.
• Ben Campbell: Comment [2017-10-25 18:31 PDT]: 
  
• Kathleen Moriarty: Comment [2017-10-23 09:16 PDT]: 
  
• Eric Rescorla: Comment [2017-10-21 14:00 PDT]: 
  
• Adam Roach: Comment [2017-10-25 16:23 PDT]: 
  

Telechat:

• Amy: Version 07, INT STD, token is Benoit, it came out of LC yesterday. I have no DISCUSSes. Unless there is an objection this is approved.  
• Benoit. It is approved with revised ID needed. There are some comments to be addressed. EKR’s changes are fine, just editorial.
• EKR: I am fine with document proceeding. It is going for Internet Standard. I do think it is important to capture the points that I have raised.
• Benoit: Ok.
• Amy: Approved, announcement to be sent, revised ID needed, Benoit, let us know when it is ready.
•  
•  

2.1.2 Returning items

• (none)

2.2 Individual submissions

2.2.1 New items

• YANG Data Model for L3VPN Service Delivery (Proposed Standard) 
  draft-wu-l3sm-rfc8049bis [txt] 
  Token: Benoit Claise (ops area) 
  Discusses/comments [ballot]:
• Suresh Krishnan: Discuss [2017-10-23 18:46 PDT]: 
  * The usage of the term mask with reference to the 'mask' leaf node in all the places in this document seems to be incorrect. There are two issues with this wrong usage. IPv4 subnet masks are 32 bits in length and cannot be represented with an uint8. IPv6 does not have the same concept of subnet masks as IPv4 at all. So, I think the easiest way to fix this would be to replace the instances of mask with 'prefix-length' instead which can be represented with an uint8 and works for both IPv6 and IPv4 (CIDR). 
  * There is an off-by-one error in the definition of the prefix lengths for IPv6 addresses. Currently this is defined as 
  leaf mask { 
  type uint8 { 
  range '0..127'; 
  } 
  ... 
  but prefix lengths of 128 bits are perfectly legal are common especially in DHCPv6 assigned addresses. So the range must be '0..128'
• Suresh Krishnan: Comment [2017-10-23 18:45 PDT]: 
  
• Alvaro Retana: Discuss [2017-10-25 10:26 PDT]: 
  The Introduction says: 
  "The YANG module described in [RFC8049] cannot be implemented because of issues around the use of XPATH. This document obsoletes [RFC8049] by creating a new module with the same name that is not backward compatible (in the sense described in YANG 1.1 [RFC7950]). The changes (listed in full in Section 1.4) are small in scope, but include fixes to the module to make it possible to implement." 
  As the text above says, the model in this document is not compliant with what rfc7950 (The YANG 1.1 Data Modeling Language) specifies in Section 11 (Updating a Module), which starts by saying: 
  "As experience is gained with a module, it may be desirable to revise that module. However, changes to published modules are not allowed if they have any potential to cause interoperability problems between a client using an original specification and a server using an updated specification." 
  It seems clear that experience after the original module (rfc8049) was published has lead to the conclusion that an implementation is impossible — as this fact was not discovered before publication. I believe that the possibility of implementation (or not) of the module in rfc8049 is irrelevant as the specification in rfc7950 talks about updates without any qualification. 
  The solution seems straight forward to me: follow rfc7950, either by changing the module name, or by keeping the name and following the specification on how to update a module. 
  
  I am concerned that the discussions related to the RtgDir review [1] in the netmod [2][3] and ietf@ietf [4] lists have not yet resulted in an updated draft which complies with rfc7950. Even if any relevant WGs (this document is AD-sponsored) or the ietf@ietf list reached consensus on moving forward with the document as is, it would still not be following what a Standards Track document specifies (rfc7950, in this case). IOW, documents that don’t conform to what is clearly specified in a Standards Track, community consensus RFC, should not be approved for publication (without the proper Updates to that RFC, of course). 
  I am then Balloting DISCUSS for the authors to update the document according to the module update specification in rfc7950, or for the discussions on the lists to reach (a different) consensus [*] and then consider the next steps. 
  [1] https://datatracker.ietf.org/doc/review-wu-l3sm-rfc8049bis-07-rtgdir-lc-berger-2017-10-16/ 
  [2] https://mailarchive.ietf.org/arch/msg/netmod/-VC7QhHzTyY0P8sL1m4QRg20cv8/?qid=373bf84b373edd7be9e51621c294189a 
  [3] https://mailarchive.ietf.org/arch/msg/netmod/xDIT_6R0cw_UT97scDYPArTbCYU/?qid=373bf84b373edd7be9e51621c294189a 
  [4] https://mailarchive.ietf.org/arch/msg/ietf/f4xmJk651EYzIlGi2bgDxAWQkWU/?qid=9c0f779d3f35b9787d796586750fcf36 
  [*] I know that the conversation on versioning is still ongoing.
• Ben Campbell: Comment [2017-10-25 18:37 PDT]: 
  
• Alissa Cooper: Comment [2017-10-25 17:39 PDT]: 
  
• Kathleen Moriarty: Comment [2017-10-24 11:14 PDT]: 
  
• Adam Roach: Comment [2017-10-25 19:04 PDT]: 
  

Telechat:

• Amy: Version 07, PS, token is Benoit. I have a couple of DISCUSSes for this document. Do we need to discuss those today?
• Benoit: I wish not, but we have to. I want to explain for the IESG what is at stake here, and it is an important issue. The background is that in YANG model when we have a new revision, it must be backwards compatible. We can augment the new module. We can have a couple of changes. But if you change the keys in the list, it is not backward compatible. We have to make a distinction between the smaller issue and a bigger issue. RFC8049 could not be implemented. Fair argument. It is not always possibility for operators because they want to have an RFC before they put it in RFPs. I believe that IETF is making a mistake that the only metric for success is the RFC number. In my world of operations it does not work that way. The operators care about YANG modules. Typically they would go the zoo of YANG modules and try to find the relevant modules. They would go to YANG catalog and search for L3VPN. They will find multiple entries there. Assuming that we go with a new name, from l3vpn YANG module to l3vpn-2 YANG module, there is no way to automatically link the two modules expressing that the -2 obsoletes the first draft. There is no automatic way. This is the issue that we are trying to solve. I think we need to change how IETF works here. I am going to address this in NETMOD and would try to post a draft by the deadline. It is important for the service composition because at the end operator want to do services. Same issue is with ietf-routing and ietf-routing-2. All dependencies that we have are important. With all the dependencies, when we create services, if we go with changing the names, we will have more issues in the future. Alvaro, you mentioned the consensus aspect of this. This came from routing directorate, it was discussed at YANG doctors, on NETMOD list, then on IETF list. There is a smaller issue for this draft and a bigger for the IETF. I am trying to focus on the bigger one. The previous RFC is not implementable. We have a chance to make this right.
• Alvaro: I understand and agree with the things that you have said. We need to be faster, the RFC needs not to be a goal post. The problem that I have is that there is a process in RFC7950 that says how do you update the module. It does not say anything like unimplementable or anything else. It says just do it this way. That is a STD track document, we cannot accept something that goes against that process. If we do, we open a door for other modules to say to start over or that they messed up last time. We are setting a precedent here they we here at IESG can change any STD track document by making exceptions and then every time we are arguing about MUST and SHOULD is a waste of time.
• Benoit: The small issue is the process. In my mind it is a small issue. The big issue is whatever we do gets used by operators. We can argue whether it is a l3vpn or l3vpn-2, it does not matter that much. I try to look at what is right for the operators here. We will try to solve that issue in NETMOD by having a YANG keyword that tells that this model obsoletes the other YANG module. And because we have a broken process in 7950 that is the reason for a different name. This is just adding complexity. It is a call for IESG. Do we follow a small process issue or do we try to do what is right for operators. I consider part of my job to go and reach out to operators. Have met 10 operators in last 3 days. This is to gather this type of feedback that I gather. I strongly believe that I am right here and I strongly believe Alvaro that you are right for the process. We are at the diverging point here. Would like to hear from others.
• Suresh: I think we are making progress here. I will leave it up to you. The fixation on mask is wrong, especially as they use mask not for what mask means. It needs to be fixed. The other one I will leave to your discretion.
• Benoit: I thought that Adrian proposed a change for mask?
• Suresh: He did but then Qin sent another mail. Then proposed another change that still keeps the mask. It does not make sense to me.
• Benoit: I have replied to Qin that the mask and prefix length was right. I will follow up on this one.
• Suresh: That is perfect. I will clear and let you handle the mask.
• Benoit. Coming back to the first issue. We need to find a solution here. There is no point to delay this. We can delay to next NETMOD meeting where I plan to address this issue. It is blocking the document. Any other point of view whether we keep the same module name or not?
• Alia: I have been following the discussion about it and I am seeing all the dependencies and suspect that when the update rules were defined, there was not a tsunami of modules and interactions, I am happy to see WG heading towards keeping the same name, same as in routing.  
• Adam: I have a question on larger issue – Benoit, do you think there is a consensus that 7950 needs to change?
• Benoit: It depends on whom you ask. Let’s talk Openconfig as example. We had discussed IETF vs Openconfig multiple times. OC is way ahead in term of YANG modules. We speak about the people who are webscale operators, only automation counts. They enforce entire set of vendors to implement their models. They are using Github, it is version 1, then they change revision based on feedback, it is version 2 now, and keep the same YANG module name. Then they change a revision, it I s an extension keyword, similar to semver one. Version 2 is backwards compatible. You have to be aware of that. This is the way of automation. If they have to change every time when there is a new module when we update yang-module to yang-module-2 in a non-backwards compatible way this is a non-starter for service composition. They have to understand that yang-module-3 has obsoleted yang-module-2. They have to update their scripts. On your question of consensus. If I speak to webscale operators – this is what they need. If I speak to not webscale operators, they want something like that as well. If I asked in the IETF, I do not think that the people are convinced yet. I have got some key people in YANG, they are coming more from academic background. They want to do what is perfect. They are not there yet for some of them. Did I answer your question?
• Adam: I think so. I am left with the admiration of the problem as opposed to the suggestions that I could offer.
• Benoit: This is the only reason why we created YANG catalog. The operators that search for L3VPN would go to YANG catalog. There are 2600 YANG modules. If they want to do their service, where do they start? They do not care about the RFC id. There is a module, it validates, it has the right metadata, and then they see another two modules. Last feedback that I got from the operator based on YANG Catalog – I am trying to get topology module, I see one from ODL, one from I2RS, one from SR, one from vendor. Is there a way to compare those modules that I could see which one is best and how to connect those modules. We are speaking about small issue in IETF. You go from YANG module to RFC id, you see that it is obsolete and you can discard the YANG module. I was not following the chat while I was speaking. Alissa?
• Alissa: Alvaro and I were going back and forth in the chat. This seems challenging. The point is to get this thing implemented and deployed. The argument for renaming and maintain consistency with 7950 is a barrier here. Maintaining parity of what RFC says for the sake of less deployment does not seem as a right tradeoff. I can appreciate where Alvaro is coming from as you do not want to repeat this.  
• Alvaro: It is not for the sake of deployment. It is for the sake of process. You cannot just override. I am happy with giving the same name. I think this is a very bad door that we do not want to open. Because that would mean that IESG can override any RFC that says anything. Without the proper documentation. Not just about YANG. About anything else that comes up. Other people want to come and say because of whatever. We do not feel that conditions in that RFC need to be followed. Security, privacy, anything that we mandate via RFCs.
• Ben: We can certainly override one specific thing without creating a precedent.
• Alvaro: I do not think so.
• Ben: In this specific case we are talking about the precedent. 7950 explicitly qualifies this as interoperability problems. If there are no implementations, this does not seem to violate anything.
• Alvaro: The amount of changes that we have to make. This is a special case of unimplementable. RFC7950 does not say whether it was never implemented. It says if you need to update something do this.
• Ben: It says, interoperability problem. I agree with you that IESG should not be randomly overriding normative requirements of STD FRCs. But it is for IESG to decide whether something is an interoperability problem.
• Alvaro: That would mean the precedent that we set. I may be in the rough, but if this is going to happen it has to be documented somewhere else. Otherwise next year we will see claims that it does not affect interoperability. Archive what was decided.
• Ben: Are we expecting a lot of people doing this?
• Alvaro: I do not know, we are just opening the door. We have thought forever that there is normative language in RFCs. If we do not like we may change it with another RFC.
• Benoit: I do not agree with that. We are not changing the RFC, we are expressing why this does not apply. This is quite different. It is not that we are opening the Pandora’s box of saying that any rules in any RFC can be overridden for whatever reason. There is a clear distinction.
• Alvaro: I do not think there is a clear distinction. Why are we making this decision to go beyond what this RFC says?
• Benoit: On this one I would like someone else to make a call as I am obviously biased, and specifically this is AD sponsor. Alissa, I do not want to put you on the spot but could you help here?
• Alissa: Alvaro is willing to clear acknowledging that he is in the rough.
• Alvaro: I said I would not clear. I think this is important.
• Alissa: I am wondering whether there is any other solution to this. Ultimately we should not be ones deciding this. We could go back and have more discussion with folks in WG. Today you do not expect that anything will change?
• Benoit: Taking it into account that we have IETF meeting in two weeks and I should have a slot in NETMOD to discuss this, can we postpone for two weeks? I spent 15 minutes explaining the issue. Maybe I did not do a good job explaining to the larger community. Maybe it would make sense to get the feedback from NETMOD mailing list?
• Alissa: That sounds as a reasonable approach.
• Benoit: Alvaro, would you join?
• Alvaro: I will be there.
• Warren: Another possible option would be to send email to IETF list, if someone wildly disagrees shout now. That way there is some documentation for history.
• Alvaro: This is already on the IETF mailing list.
• Benoit: I did LC, and this point was discussed. I stressed the unique change between the two versions of why we kept the same name. That was done already.
• Alissa: It sound that you need new information to do this.
• Benoit: The conclusion is to present in NETMOD and see whether there is a different view. If this document comes back in next formal telechat, can I ask you to be a judge on this one? Or Warren. I cannot at the same time push on solution and be responsible AD.
• Alissa: Yes.
• Benoit: Thank you all for a discussion.
• Amy: That is going to be AD followup?
• Benoit: Correct.
• Amy: Stays in IESG evaluation with AD followup.
•  
•  

2.2.2 Returning items

• (none)

2.3 Status changes

2.3.1 New items

• (none)

2.3.2 Returning items

• (none)

3. Document actions

3.1 WG submissions

3.1.1 New items

• Self-Clocked Rate Adaptation for Multimedia (Experimental) 
  draft-ietf-rmcat-scream-cc [txt] 
  Token: Mirja Kühlewind (tsv area) 
  IPR: Microsoft Technology Licensing, LLC. 's Statement about IPR related to draft-ietf-rmcat-scream-cc and draft-ietf-rmcat-nada 
  Discusses/comments [ballot]:
• Spencer Dawkins: Comment [2017-10-24 19:32 PDT]: 
  
• Ben Campbell: Comment [2017-10-25 13:06 PDT]: 
  
• Adam Roach: Discuss [2017-10-25 22:50 PDT]: 
  I'm confused about whether the text in this document is intended to form a normative description of SCReAM. The document contains the following statement: 
  "Note that the pseudo code does not show all details for reasons of readability, the reader is encouraged to look into the C++ code in [SCReAM-CPP-implementation] for the details." 
  This effectively states that the cited C++ code forms the normative specification of the SCReAM algorithm, and that this document is a non-normative companion to help understand the normative code. 
  If this is the case, then: 
  - The [SCReAM-CPP-implementation] reference needs to be moved from 'Informative References' to 'Normative References', 
  - The abstract and introduction need to make it much clearer that the normative definition of the SCReAM algorithm is a body of C++ code rather than the prose and psuedocode in this document, and 
  - We need to coordinate with the RFC editor to ensure proper archival of the code at [SCReAM-CPP-implementation]. At this time, github.com does not meet the standards of archival quality that the RFC series is expected to meet. 
  If the C++ implementation is *not* the normative definition of SCReAM, then the psuedocode and definitions in this document need to be complete and sufficient to implement the algorithm; and, in particular, it cannot omit algorithm details 'for reasons of readability.'
• Adam Roach: Comment [2017-10-25 22:50 PDT]: 
  

Telechat:

• Amy: Version 12, EXP, token is Mirja. I have a DISUCSS in the tracker. Do we need to discuss it today?
• Mirja: No, it is basically resolved, will need a revised id.
• Amy: IESG evaluation, revised ID needed.
•  
•  
• Framework for Interface to Network Security Functions (Informational) 
  draft-ietf-i2nsf-framework [txt] 
  Token: Kathleen Moriarty (sec area) 
  Discusses/comments [ballot]:
• Mirja Kühlewind: Discuss [2017-10-16 08:45 PDT]: 
  I have two points below: 
  1) The first one should be easy to address: 
  'Transport redundancy mechanisms such as Multipath TCP (MPTCP) and the Stream Control Transmission Protocol (SCTP) will need to be evaluated for applicability. ' 
  This sentence is not correct; MPTP and SCTP do not provide any redundancy mechanisms; they simply just provide a reliable transport as TCP does. Therefore I would just remove this sentence here. 
  Further, on this paragraph, it is not clear to me why you say that reliable transport is needed. Especially for some monitoring purposes, unreliable transport might be acceptable as well. Or do you think that all communication for security systems have always to be reliable? I don't think this document discusses things in detail enough to make such an assessment. 
  2) This second is a very high level concern and I'm not sure if balloting discuss on this is the right thing to do but I definitely would like to get some feedback from the group to better understand this document before publication: 
  "This document seem not very security specific to me. To say this in a somehow sloppy way: I have the feeling that if you would just remove the word 'security' everywhere in the text, it would still be the same document. I checked the charter and the charter is also not very concrete about what to expect, besides motivating the needed interfaces with the need for in-network security function. However, if there is nothing security specific about this, what's the difference to the usually control plane architecture as usually deployed with the use of NETCONF? And I am actually wondering if this is the right wg to write such a document." 
  Further, I would at least have expected that this framework mandates for high control plan security given we are talking about the configuration and deployment of security function. However, it does not. It does rarely provide any concrete recommendation here, and basically leaves the door open to used these interfaces without authentication which I think is not acceptable.
• Ben Campbell: Comment [2017-10-24 20:08 PDT]: 
  
• Alissa Cooper: Comment [2017-10-25 13:48 PDT]: 
  
• Alvaro Retana: Comment [2017-10-25 14:04 PDT]: 
  

Telechat:

• Amy: Version 08, INF, token is Kathleen. I have a DISCUSS, do we need to discuss?
• Kathleen: Mirja, do you want to discuss it?
• Mirja: I believe this is small changes. Related to closed environment. I am not sure if it helps to discuss.
• Kathleen: I also commented on that. I do not think they need an isolated environment.
• Kathleen: Will need a revised ID.
• Amy: IESG evaluation, revised ID needed.
•  
•  
•  
• Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS Networks (Experimental) 
  draft-ietf-bier-mpls-encapsulation [txt] 
  Token: Alia Atlas (rtg area) 
  IPR: Cisco's Statement about IPR related to draft-ietf-bier-mpls-encapsulation 
  Discusses/comments [ballot]:
• Warren Kumari: Comment [2017-10-25 11:34 PDT]: 
  
• Mirja Kühlewind: Comment [2017-10-26 02:14 PDT]: 
  Thanks for addressing my discuss on MTU discovery/fragmentation!
• Ben Campbell: Comment [2017-10-25 18:43 PDT]: 
  
• Alvaro Retana: Comment [2017-10-24 06:48 PDT]: 
  
• Kathleen Moriarty: Discuss [2017-10-25 19:28 PDT]: 
  I share the concerns of the SecDir reviewer and would like to see more text in the Security Considerations that reflect the inherent trust model and also the lack of integrity protection for the BIER encapsulation. Having these items detailed explicitly is an important consideration for implementers. I do realize that this is the current state with MPLS, but it bears repeating for a new encapsulation. 
  https://mailarchive.ietf.org/arch/msg/secdir/w8qqQtzlEi00uToUGT0N8XVuHkI 
  Thank you.
• Spencer Dawkins: Comment [2017-10-24 11:49 PDT]: 
  I agree with Mirja's Discuss position, and with the proposed resolution. Thanks to the authors for that.
• Adam Roach: Comment [2017-10-25 21:03 PDT]: 
  

Telechat:

• Amy: Version 11, EXP, token is Alia. Alia, I have a DISCUSS, do we need to discuss this today?
• Alia: No, I think that what needs to be done is clear. Authors are engaged.
• Amy: Revised ID needed?
• Alia: Definitely.
• Amy: Revised ID needed.
•  
•  

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 Status changes

3.3.1 New items

• (none)

3.3.2 Returning items

• (none)

3.4 IRTF and Independent Submission stream documents

3.4.1 New items

• (none)

3.4.2 Returning items

• (none)

4 Working Group Actions

4.1 WG Creation

4.1.1 Proposed for IETF Review

1.    Software Updates for Internet of Things (suit) 
Token: AD

Telechat::

o   Amy: Charter for SUIT, was FUD, charter version 00-03, Kathleen is shepherding AD. I have a BLOCK on this chartering effort, do we need to discuss that block?

o   Kathleen:  Emailed on it. Need clarifying text on preferences for ASN.1.

o   Alexey: Yes. I think we collectively save a lot of time if we stay specific about this.

o   Kathleen: Sure. Same comment from other people. Essentially preference for ASN.1. This will be the first one. Recharter to work on another format later.

o   Ted: Kathleen, I want to turn your attention to comments that Martin had as a shepherd for this on scope creep.

o   Kathleen: People are asking for scope creep.

o   Ted: At this point I am wonder whether you read the mailing list. Whether we should wait. Is scope discussion really finished?

o   Kathleen:

o   Ted: Ok, makes sense, Martin is helping to manage this.

o   Kathleen: I hoped it will be finished for internal review. [inaudible].

o   Ted: Makes sense. Martin is willing to help.

o   Alissa: Is charter going straight to external review?

o   Kathleen: First work with WG on final updates on ASN.1 text. And then to eternal review.

o   Alissa: Ok.

o   Amy: It does not sound that there is an objection to external review pending those changes.

o   Kathleen: Thank you.

o   Amy: External review is approved pending edits to the text and we will wait for your go ahead. After that it will come back for approval after IETF100.

o    

o    

4.1.2 Proposed for Approval

1.    (none)

4.2 WG Rechartering

4.2.1 Under evaluation for IETF Review

1.    (none)

4.2.2 Proposed for Approval

1.    (none)

5. IAB News We can use

• Amy: Kathleen, is there any news?
• Kathleen: Nothing stood to me on the call. [inaudible]
• Amy: No questions.
•  

6. Management Issues

1.    [IANA #983681] Designated expert for RFC-ietf-pals-status-reduction (Deborah Brungard)

Telechat::

o   Amy: Deborah added, she has found two experts for this registry and they are here to be approved. Is there any objection to approve Stewart Bryant and Andy Malis as designated experts? Hearing no objection. We will put in the minutes that they were approved and will send an official note to IANA. AI is done.

o    

 

o   Amy: Next management item is agenda for IETF100. The IESG agenda.

o   Alissa: The first question Mirja whether you want tcpcrypt drafts to come to us.

o   Mirja: That would be great for me.

o   Alissa: Any objections?

o   EKR: I can get with it.

o   Mirja: How do we do this in the datatracker?

o   Amy: If you approve them during IETF100 they can be on the on the agenda and we minute that that decision was taken.

o   Mirja: Great. And then we remove them from datatracker.  

o   Amy: You just leave them for agenda for 30 of November. If you take a decision for approval that action will be minuted as if the discussion had taken place in person. Let us know that the discussion has taken place.

o   Mirja: They will not be on telechat on 30^th.  

o   Amy: That would not be a problem. They are there as a placeholder.

o   Mirja: Ok.

o   Kathleen: Is it possible to have that for SUIT charter as well [inaudible]

o   Amy: Is this a recharter for SACM?

o   Kathleen: Yes.

o   Amy: Any action you take in person at the IETF meeting can be minuted in the next minutes of the next telechat. If you come to a decision that everyone has balloted for the charter, we can do that and minute at the next official telechat.

o   Alissa: Anyone have [] SACM charter?

o   Alissa: We will get those added for agenda for Sunday or Monday. If you have any additional topics please add them to the candidate list.

o   Benoit: Right now we have 3 breakfast meetings. Mon, Wed, Thu.

o   Alissa: I am glancing through the topics lists. It is possible that we will be able to take one off. If people have a preference to cancel one or the other let me know.

o   Benoit: I have no conflicts but many requests for breakfast meetings.

o   Amy: Thank you.

o    

o    

o    

2.    MMM (Member)

Telechat::

o    

o    

o    

o    

o    

7. Working Group News

• Alia Atlas (RTG)---
• Deborah Brungard (RTG)---
• Ben Campbell (ART)---
• Benoit Claise (OPS)---
• Alissa Cooper (GEN)---
• Spencer Dawkins (TSV)---
• Stephen Farrell (SEC)---
• Suresh Krishnan (INT)---
• Mirja Kühlewind (TSV)---
• Worren Kumari (OPS)---
• Terry Manderson (INT)---
• Alexey Melnikov (ART)---
• Kathleen Moriarty (SEC)---
• Eric Rescorla (SEC)---
• Alvaro Retana (RTG)---
• Adam Roach (ART)---

7a. Other Business

• Amy: Is there any other business that we should discuss today?
• Kathleen: I have some WG news. ACE will replace WG chairs. Same for SACM.
• Benoit: Michelle, are we good now with all YANG modules in IANA? We want to consume YANG modules but there is no official place where to get them. We are trying to get official links from IANA. Are we good now?
• Michelle: I think so. We will be in contact with you if we have any questions.
• Alia: We are trying to merge ISIS and OSPF. Will have joint meeting this time. I expect to get them merged shortly. I am still looking for good WG name. [Alia and Amy setting bar plans. :-)]  
• Amy: Any other business? Just a note on Friday ISOC reception event in Singapore – RSVP by tomorrow.
• Amy: We are done for the day and will see you all in Singapore.
•  

1130 EDT Adjourned