IESG Narrative Minutes
Narrative Minutes of the IESG Teleconference on 2016-10-27. These are not an official record of the meeting.
Narrative scribe: John Leslie (The scribe was sometimes uncertain who was speaking.)
Corrections from: John
1 Administrivia
2. Protocol actions
2.1 WG submissions
2.1.1 New items
Telechat:
Telechat:
Telechat:
Telechat:
2.1.2 Returning items
2.2 Individual submissions
2.2.1 New items
Telechat:
2.2.2 Returning items
2.3 Status changes
2.3.1 New items
2.3.2 Returning items
3. Document actions
3.1 WG submissions
3.1.1 New items
Telechat:
Telechat:
Telechat:
3.1.2 Returning items
3.2 Individual submissions via AD
3.2.1 New items
3.2.2 Returning items
3.3 Status changes
3.3.1 New items
3.3.2 Returning items
3.4 IRTF and Independent Submission stream documents
3.4.1 New items
3.4.2 Returning items
1038 EDT no break
4 Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
4.1.2 Proposed for Approval
Telechat::
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
4.2.2 Proposed for Approval
5. IAB News We can use
6. Management Issues
Telechat::
Telechat::
Telechat::
Telechat::
7. Working Group News
1116 EDT Adjourned
(at 2016-10-27 06:00:02 PDT)
draft-ietf-mmusic-sdp-mux-attributes
- 4.5 and 5.7: What if the different a=crypto lines specify different strength ciphersuites? Wouldn't it be better to pick the strongest or to say they MUST be the same (as is done in 5.35)? If picking the first is the right answer then maybe warn folks to not put a stronger ciphersuite anywhere else? - 5.36 vs. 5.39: It wasn't clear to me why these have different rules - can you explain?
Two comments: 1) The category TDB is not fully clear to me. It says: "The attributes in the TBD category have not been analyzed", but why? Can you further explain? 2) Is the new registry for the Mux Category really needed? Is it expected to (much) more categories in future?
Update: The reference to the obsolete RFC 4901 is to cover a deprecated attribute that is defined in that doc. Is the reference to 4901 (obsoleted by 5245) intentional?
Thank you for all the work on this.
Thank you for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06749.html
This document is a work of art. Thank you folks for accepting the challenge,
because it's important.
I have a couple of observations, to go along with my Yes ballot. Please do the
right thing.
I know Mirja also pushed on the TBD category, but I find RFC 2119 "SHOULD NOT"
to be problematic.
The attributes in the TBD category have not been analyzed under the
proposed multiplexing framework and SHOULD NOT be multiplexed.
The point of SHOULD (NOT) is that you don't do this unless you understand the
risks, and in this case, it seems to me that you don't know the risks. If
you're determined to multiplex the TBD attribute "frommet=", won't you have to
do your own analysis? Wouldn't that mean you might make assumptions ("it's
IDENTICAL") that conflict with the analysis other implementers are doing ("it's
TRANSPORT")?
I could imagine a couple of approaches that might be helpful here.
Saying "MUST NOT be multiplexed" would avoid implementers doing their own
analysis and coming up with conflicting answers. Is it obvious why this is
"SHOULD NOT" instead of "MUST NOT"? In other words, who needs to multiplex TBD
attributes, and why?
Saying "cannot be assumed to be safe when multiplexed" probably captures what I
think you are saying.
Would it be clearer if the category was called UNKNOWN?
In this text,
16. Security Considerations
This document does not add any new security considerations beyond the
existing considerations in the RTP RFCs ([RFC3550] and [RFC3711])
that are referenced by this specification.
I don't understand how the first paragraph ^^ and the third paragraph of the
section are compatible, because you're referring to issues described in this
specification. But if you delete the first paragraph, leaving only
The primary security for RTP including the way it is used here is
described in [RFC3550] and [RFC3711].
When multiplexing SDP attributes with the category "CAUTION", the
implementations should be aware of possible issues as described in
this specification.
the security considerations would be consistent.
draft-ietf-roll-routing-dispatch
Thanks for addressing the INT dir review comments from Bernie Volz.
I enjoyed the introduction (as the writeup says: generous (5 page) introduction appropriate for a reader who is unfamiliar with the why).
In figure 2, I'm a bit confused on what the third-from-the-left vertical line represents - is it also IPv6 in IPv6 plus RPL SRH, or something else?
Mahesh Jethanandani <mjethanandani@gmail.com> performed the opsdir review
draft-ietf-mpls-rfc4379bis
There are comments in the gen-art review that I think need to be considered: https://mailarchive.ietf.org/arch/msg/gen-art/NCnpeM8V5bWmrw_eLEuiT0FPP_E
The document authors will increase by one (to a total of six) as due to a mix up of communications, George Swallow was omitted. We had planned to fix with the next update when addressing the Gen-Art comments last week but got delayed.
A few not very important comments: 1) To me it seems a bit unfortunate that this draft points to rfc6425 and rfc6426 for the definition of the T and R flags, given the goal was to have all specifications in one doc. Not sure if that can or should be fixed. Just wanted to mention it. 2) I would expect that the security section recommends border filtering of MPLS ping message, given that these are usually used within one domain, no? 3) I know this is a bis doc but I'm still wondering why this TTL trick is used here. For ICMP that was a way that utilizes the existing specification and implementation to get further information. However here, you could just have used a flag in the header either saying 'only forward to the end' or 'reply and still forward', or something like this, to cover the two modes. This would also allow to just send one packet to the end instead of sending one for each hop. Is there a rational for copying this ICMP hack?
Thank you for writing this document. I will recommend its approval, but before that we have a fix a couple of issues. A Gen-ART review by Elwyn Davies raised a number of valid points. The ones worthy of a Discuss are the following: 1. Section 3.4 protocol definition refers to Appendix A.2 which is depracated/non-normative. I think you have to decide which parts are still in the normative spec, and keep those in the body of the document. 2. Reference to the R flag in 6.2.3 seems wrong, as the flag isn't actually allocated in RFC 6426 due to an oversight. Maybe either explain the situation and the existing errata, or just define the flag in this RFC and be done with it?
Please work with the Gen-ART reviewer on the remaining issues as well.
Sheng Jiang <jiangsheng@huawei.com> performed the opsdir review
draft-ietf-l3sm-l3vpn-service-model
This is a nicely readable document, especially given its size. I just have a few minor comments: - There are a number of uses of MAY that seem more like statements of fact than permission to do something. Some of these take the form of "MAY decide" or "MAY want" that might be more appropriate if reformulated along the lines of "MAY do": -- 5.6.3, last paragraph: "Other parameters like the requested svc-input-bandwidth, svc-output- bandwidth MAY help to decide the access type to be used." -- 5.6.7, last paragraph: "Note that a service provider MAY decide..." -- 5.11.6, last paragraph: "...user MAY decide..." -- 5.13.1, first paragraph: "...a customer MAY want to..." -- 7, 2nd paragraph: "The management system MAY be modular..." and "... the component...MAY be different." - 14.2: As currently used, I think the references to restconf and to RFC6536 should be normative.
(1) In 5.9.2, how are pre shared keys (PSK) updated or rotated? Don't you at least need some key id or versioning or old/new thing defined? (Apologies if that "just works" via some yang magic of which I'm unaware:-) (2) When someone wants to use IPsec with PSK, wouldn't you also need to specify algorithms etc to get interop? I see there's an "algorithm" string in the yang module, but that seems too underspecified to be useful.
- 5.9.1: Just curious, the text says " The current model does not support any authentication parameters..." is that because there's no user or host authentication? - 5.9.2: I wondered why the empty "pki" container? Would it not have been useul to define what's needed there, or do you just never see IPsec using IKE for these VPNs? (Which would be a bit sad;-)
Please spell out acronyms, e.g. OSS, CLI,ASM, SSM, RP, DHCP, OAM , BFD, LIME, VRF and many more... That would at least help me a lot :-) Two question mainly on the transport constraints part (sec 5.13.2): 1) I don't really understand why there is bandwidth as a service parameter (section 5.12.1) and a transport constraint on bandwidth. Isn't that the same? Can you explain! 2) There is a transport constraint on path-diversity. Shouldn't that be a side specific parameter because that information in needed when placement is considered? And respectively isn't side-diversity already covered by Site network accesses parameters (sec 5.3.2)?
I do have a concern about the definition of the IPv6 address allocation mechanisms. It looks like the service model assumes that one of these mechanisms will be used, while in reality more than one of these mechanisms might be in use at the same time. I just wanted to make sure that this was a considered decision and not an oversight.
This is generally a well written document, so only a couple of nits:
leaf country-code {
type string;
description
"Country of the site.";
}
2 letter country codes? 3 letted country codes? Please add a normative
reference. (I think you meant 2-letter ISO country codes.)
14.2. Informative References
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-17 (work in
progress), September 2016.
This should be Normative due to RFC 2119 language used when mentioning
RESTCONF. However it doesn't look like RESTCONF needs any normative language
when mentioned. For example:
The configuration of network elements MAY be done by CLI,
or by NETCONF ([RFC6241])/RESTCONF ([I-D.ietf-netconf-restconf])
coupled with specific configuration YANG data models (BGP, VRF, BFD
...) or any other way.
I don't think use of MAY is correct here, because it is not an implementation
choice that affects use of your document. I would just change "MAY" to "can".
There is another similar use later in the document.
Thanks for addressing the SecDir review: https://www.ietf.org/mail-archive/web/secdir/current/msg06909.html I'm sure the RFC editor would catch this, but IPsec instances should be replaced: s/IPSec/IPsec/
First, thank you very much for a well-written and easy to read and understand document. There are a few places where expanding acronyms would be useful - but the RFC Editor can deal with those. Nit: Top of page 42 - sentence fragment " Each constraint is expressed as "I want my current site-network- access to be <constraint-type> (e.g. pe-diverse, pop-diverse) from these <target> site-network-accesses". In addition, " Model described as proposed - less tentative language for a standard is appropriate now.
Les Ginsberg did the rtg-dir review: https://mailarchive.ietf.org/arch/msg/l3sm/NKEk7xO8RRUvBlNRP81RukOgzyo
Would suggest s/zip code/postal code/ since zip code is a US-only concept.
draft-weis-gdoi-iec62351-9
Maybe s/MUST NOT be specified/MUST NOT be used/ (2x in the security section) because this doc is the spec and not specifying it...
I would support adding a note as Stephen proposed in his Discuss, about the IETF's ability to evaluate this specification in the absence of access to referenced documents.
I'm not clear how to evaluate the security properties of this protocol given that the IEC specs on which it builds aren't visible to me. (Or at least I didn't find a version I could access.) That's made worse by my relative ignorance of GDOI as well. So I wonder should the authors or IESG add a note to that effect? Say along the lines of: "This memo extends RFC6407 in order to define extensions needed by IEC62351-9. With the current IANA registry rules setup by RFC6407, this requires a standards action by the IETF - essentially that means the production of this document. As the relevant IEC specifications are not available to the IETF community, it is not possible for this RFC to fully describe the security considerations applying. Implementers therefore need to depend on the security analysis within the IEC specifications. As two different SDOs are involved here, and since group key management is inherently complex, it is possible some security issues have not been identified, so additional analysis of the security of the combined set of specifications may be advisable." I'd be fine with any wording that calls out that the IETF can't really be sure of the overall outcome here. Note that that's not in any way to doubt the authors' own analysis - but given that we know it is quite possible for fewer eyeballs to lead to gaps, and that this really is a complicated beast solving a complicated problem, I'm a bit concerned that we may miss something.
- I'm left wondering why the IETF is doing this rather than changing the registration rules for existing registries (e.g. along the lines being followed for TLS1.3) so that IEC could do the work themselves? - The various algorithm codepoints listed at [GDOI-REG] seem fairly outdated. Is it really a good idea to extend those as is being done here by adding new registries for modern ciphers? (It may be the case that we are doing this because there is implementer energy for this, but not for a general revamp of GDOI.)
I assume that multioctet fields are in network byte order, but this is not mentioned anywhere.
Carlos Pignataro (cpignata) <cpignata@cisco.com> provided the opsdir review
draft-ietf-lisp-ddt
6.4.1: RSA-SHA1 is not the right choice today, shouldn't this be RSA-SHA256?
- 6.4.1: Can you clarify what bits are signed? I'm not quite sure from the description given - you can have more than one signature but you say the the "entire record" is covered. - Section 8: Where's signature validation in the pseudo-code?
Would it be worth it to potentially think about/document potential attacks against this system? I didn't think myself about how such an attack could look like but given that location and identity are potential sensitive data it might be worth it...
I have no objections to the publication of this document. However, I do wonder why an extension to the DNS infrastructure wasn't used instead. The Gen-ART review provided a significant set of good comments that should be taken into consideration.
Linda Dunbar <linda.dunbar@huawei.com> performed the opsdir review
draft-ietf-pce-stateful-pce-app
I agree with Alvaro's comment. To me one important question here is if section 4 (Deployment Considerations) should be moved back into the stateful pce spec?!
This document mostly presents application scenarios, which (by reference) serve as motivation for draft-ietf-pce-stateful-pce. However, there are a couple of places (in Section 4) where the operation defined in draft-ietf-pce-stateful-pce is used as part of the considerations. For example (from 4.1): Stateless and stateful PCEs can co-exist in the same network and be in charge of path computation of different types. To solve the problem of distinguishing between the two types of PCEs, either discovery or configuration may be used. The capability negotiation in [I-D.ietf-pce-stateful-pce] ensures correct operation when the PCE address is configured on the PCC. I see a circular dependency between this document and draft-ietf-pce-stateful-pce, where the considerations here are expected to motivate the extensions, but the specific extensions are used to discuss “generic issues with stateful PCE deployments”. Given that draft-ietf-pce-stateful-pce is a Normative Reference, I would rather see this document come back for IESG Evaluation with/after draft-ietf-pce-stateful-pce. Note that draft-ietf-pce-stateful-pce is still (AFAICT) under consideration in the WG. I am not making this comment a DISCUSS because I don’t think that it raises to the appropriate level (as only some parts of the document seem to have the dependency), and we’ll have to wait for draft-ietf-pce-stateful-pce to be processed before publication anyway. However, I think that the application scenarios and motivation for future extensions should be able to be described without referring to the extensions themselves — I would then like the authors, Shepherd and the responsible AD to consider whether it is possible for this document to stand on its own, or whether we need to process it with the extensions draft. Given that draft-ietf-pce-stateful-pce is still in the WG, I think it is important for us to talk about it as this point. I noted in the Shepherd’s writeup that this document used to be “originally included in the base stateful PCE protocol specification” (which I assume is draft-ietf-pce-stateful-pce). To be clear: I am not opposing the publication of this document (even though the content could have been part of draft-ietf-pce-stateful-pce), I just think that in the current form it should be processed/published *with* draft-ietf-pce-stateful-pce. [Mechanisms from I-D.ietf-pce-stateful-sync-optimizations and I-D.ietf-pce-pce-initiated-lsp are also mentioned in similar ways, and those drafts are also in process in the WG. I’m focusing on draft-ietf-pce-stateful-pce above just to make the point.]
draft-ietf-i2rs-ephemeral-state
Agree with Alvaro's Discuss. Not clear where Section 2 requirements are distilled from or if they are tied with supporting ephemeral state as RFC7921 did not require an active communication channel to be open at all times.
Two comments: 1) "I2RS requires ephemeral state; i.e. state that does not persist across reboots." -> why? Maybe add 1-2 sentences about the use (case) in the introduction. 2) Are all these requirements specific to ephemeral state? I would assume that some requirements are more general, e.g. don't you need priorities also for all other state updates?
I am surprised to see MUST level requirements on YANG "Ephemeral-REQ-06: YANG MUST have the ability to do the following:" and further requirements on NETCONF (REQ-09) and RESTCONF (REQ-10) in this document. Are there associated drafts in the respective WGs to make sure these requirements are met?
Section 2 (Review of Requirements from I2RS architecture document) presents a
list of “requirements distilled from [RFC7921]”, which I initially assumed to
mean that this list may have been a summary of the requirements in RFC7921.
However, I can’t find them in RFC7921; for example:
1. The I2RS protocol SHOULD support a high bandwidth, asynchronous
interface, with real-time guarantees on getting data from an I2RS
agent by an I2RS client.
…”high bandwidth” and “real-time” don’t even appear in RFC7921! While I
understand that distilling is not the same as copying, the use of rfc2119
language in this document makes me uncomfortable because it seems to be
defining requirements that may or may not conflict with RFC7921.
If the requirements in Section 2 do come from RFC7921, please put the
appropriate pointers in (and even better, use the same language to avoid
confusion). If by distilling the authors may have taken the liberty to
interpret the requirements from RFC7921, please don’t use rfc2119 language. If
there are new or different requirements, please point them out.
I'm curious about the requirements on YANG and NETCONF/RESTCONF. Does this contemplate changes to those? Criteria to determine if they are acceptable choices?
-
The I2RS Working Group has chosen to use the YANG data modeling
language [RFC6020] as the basis to implement its mechanisms.
I guess you mean RFC 7950.
RFC7950 should be a normative reference.
-
I read the abstract and title: clearly this is about ephemeral state.
I2RS Ephemeral State Requirements
draft-ietf-i2rs-ephemeral-state-19.txt
Abstract
The I2RS (interface to the routing system) Architecture document
(RFC7921) abstractly describes a number of requirements for ephemeral
state (in terms of capabilities and behaviors) which any protocol
suite attempting to meet the needs of I2RS has to provide. This
document describes, in detail, requirements for ephemeral state for
those implementing the I2RS protocol.
And in section 2, I see requirements "distilled" (btw, I agree with Alvaro's
DISCUSS) from RFC7921 about the I2RS protocol, I2RS agent, I2RS client. Why
(re-hashing) requirements not related to ephemeral? What the goal of this
section 2? It seems more like adding confusing that being helpful. Too many
requirements from different documents in I2RS: "distilling" them between
documents is looking for troubles. note: section 9 title " Pub/Sub Requirements
Expanded for Ephemeral State" and content area clear
- I read REQ3 and 4 multiple times. Isn't REQ 3 a subset of REQ4?
Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints
that refer to operational state, this includes potentially fast
changing or short lived operational state nodes,
Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-
ephemeral state as a constraint. Non-ephemeral state can be
configuration state or operational state.
I should be missing something. Examples would help me.
- Clarification:
Ephemeral-REQ-12: When a collision occurs as two clients are trying
to write the same data node
I2RS clients with the I2RS protocol, or NETCONF/RESTCONF clients?
Note: multiple instances of "clients" (as opposed to I2RS clients) in the doc.
Editorial:
- Section 5 versus 6
For NETCONF:
2. The ephemeral state MUST support notification of write conflicts
using the priority requirements defined in section 7 below (see
requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
For RESTCONF:
2. The ephemeral state must support notification of write conflicts
using the priority requirements defined in section 7 below (see
requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
must versus MUST. If there are some language subtleties here, I didn't grasp
them.
- "To support Multi-Headed Control,"
Multi-Headed Control? I guess I know what you mean, but expressed like this
(capitalized), I'm looking for a well-known, well-defined term. Later on, I see
"Multi-headed control"
- s/yang/YANG
-
Ephemeral-REQ-11: The following requirements must be supported by the
I2RS protocol I2RS Protocol
remove one "I2RS protocol" instance
-
Ephemeral-REQ-11: The following requirements must be supported by the
I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order
to support I2RS client identity and priority:
I would remove: "(e.g. NETCONF/RESTCONF + yang)"
- "MUST BE" = MUST Belgium :-)
Pretty good feedback from Lionel Morand's OPS DIR review:
1. Introduction
The I2RS Working Group has chosen to use the YANG data modeling
language [RFC6020] as the basis to implement its mechanisms.
Additionally, the I2RS Working group has chosen to re-use two
existing protocols, NETCONF [RFC6241] and its similar but lighter-
weight relative RESTCONF [I-D.ietf-netconf-restconf], as the
protocols for carrying I2RS.
What does re-use of a protocol mean? Re-use means that while YANG,
NETCONF and RESTCONF are a good starting basis for the I2RS protocol,
the creation of the I2RS protocol implementations requires that the
I2RS requirements
1. select features from YANG, NETCONF, and RESTCONF per version of
the I2RS protocol (See sections 4, 5, and 6)
2. propose additions to YANG, NETCONF, and RESTCONF per version of
the I2RS protocol for key functions (ephemeral state, protocol
security, publication/subscription service, traceability),
The purpose of these requirements is to ensure clarity during I2RS
protocol creation.
[LM] The aim of the document is not so clear. The working assumption is :
re-use but with "addition". What does addition mean? Who is in charge to check
that the proposed "additions" can be supported by YANG/NETCONF/RESTCONF without
protocol updates? Where is the need to first derive specific requirements from
RFC7921 and then check if they can be fulfilled by the model and the protocols,
instead of doing both in the same document?
2. Review of Requirements from I2RS architecture document
The I2RS architecture defines important high-level requirements for
the I2RS protocol. The following are requirements distilled from
[RFC7921] that provide context for the ephemeral data state
requirements given in sections 3-8:
[LM] What is the meaning of "distilled" here? Are these requirements explicitly
part of the RFC7921 or the requirements listed in this draft may be "relative"
or even complementary requirements compared to the RFC7921?
1. The I2RS protocol SHOULD support a high bandwidth, asynchronous
interface, with real-time guarantees on getting data from an I2RS
agent by an I2RS client.
[LM] Is it a requirement related to the I2RS protocol or to the transport
protocol?
2. I2RS agent MUST record the client identity when a node is created
or modified. The I2RS agent SHOULD to be able to read the client
identity of a node and use the client identity's associated
priority to resolve conflicts. The secondary identity is useful
for traceability and may also be recorded.
[LM] I think that the first sentence is not so related to the I2RS protocol but
rather to the mechanism to provision the I2RS agent with this info (e.g. AAA).
3. An I2RS Client identity MUST have only one priority for the
client's identifier. A collision on writes is considered an
error, but the priority associated with each client identifier is
utilized to compare requests from two different clients in order
to modify an existing node entry. Only an entry from a client
which is higher priority can modify an existing entry (First
entry wins). Priority only has meaning at the time of use
[LM] If I'm correct, "First entry wins" is for clients associated with the same
priority, right? If it is, it is not only about 'higher' priority.
4. I2RS Client's secondary identity data is read-only meta-data that
is recorded by the I2RS agent associated with a data model's node
is written. Just like the primary client identity, the secondary
identity SHOULD only be recorded when the data node is written.
[LM] Not sure of the relevance of this requirement in the context of the I2RS
protocol design if this info is opaque for the agent.
5. I2RS agent MAY have a lower priority I2RS client attempting to
modify a higher priority client's entry in a data model. The
filtering out of lower priority clients attempting to write or
modify a higher priority client's entry in a data model SHOULD be
effectively handled and not put an undue strain on the I2RS
agent.
[LM] This requirement seems to imply that the priority associated with the
client ID is transitively associated with the client's entry in the I2RS agent.
If it is, this requirement should be clarified along with Req 3 or just after.
3.1. Persistence
Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
not persist across reboots. If state must be restored, it should be
done solely by replay actions from the I2RS client via the I2RS
agent.
[LM] this one is related to Req 8 and is about a "MUST" regarding the YANG
model. As defined in RFC7950 (recently published), there are only two flavors
of data managed with YANG: configuration data and state data, differentiated by
the "config" statement with the argument the string "true" or "false". This
requirement seems to imply a new "flavor" i.e. ephemeral state, which seems not
compatible with the existing model that cannot be accommodated using a Boolean
value. Does it mean that a new version of the YANG model would be required to
fulfil this requirement?
[LM] Most of the other requirements are derived from and/or dependent on the
req 1.
[LM] Other specific comments:
5. NETCONF Features for Ephemeral State
2. The ephemeral state MUST support notification of write conflicts
using the priority requirements defined in section 7 below (see
requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).
[LM] I wonder how this impacts the recommendation on the use of configuration
lock mechanism when it is known that multiple instances may update the same
configuration data as per RFC6241. Here, it seems that the priority is able to
override the lock in place, which is not allowed in NETCONF.
Ephemeral-REQ-11: The following requirements must be supported by the
I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order
to support I2RS client identity and priority:
o the data nodes MAY store I2RS client identity and not the
effective priority at the time the data node is stored.
[LM] This requirement seems to be in contradiction with the one given in
section 2 i.e. "I2RS agent MUST record the client identity when a node is
created or modified.". If I'm correct, the "MAY" applies only to the "effective
priority" and not to the I2RS Id storage.
o The priority MAY be dynamically changed by AAA, but the exact
actions are part of the protocol definition as long as collisions
are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13,
and Ephemeral-REQ-14.
[LM] there are several references to the use of AAA-based solutions for
priority handling. Does it require any action in RADEXT or Dime to support
these requirements, at least as a default standard mechanism for I2RS?
Thanks for the updates from the previous version, it looks better and is nicer to have the security requirements in one place.
Ephemeral-REQ-12: "were created" seems wrong. (Oh, and "MUST BE" isn't 2119 language:-)
In Section 9: s/Pub-Sub-REQ-03: The subscription service must support/Pub-Sub-REQ-03: The subscription service MUST support/ (I'm assuming that was the intent, anyway)