Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05

[Brian Weis (bew)]

I support advancing this document, and have the following minor comments.

(1) Section 1.3. LLDP should be referenced at first use. The wording at the 
beginning of Section 11 is nice: "IEEE802.1AB Link Layer Discovery Protocol 
(LLDP) [IEEE8021AB]”.

(2) Section 1.4. An interesting policy example is:

Allow access to host controller.example.com with 
QoS AF11

I don’t see how QoS markings are defined in MUD. If not, then “ with QoS AF11” 
should be removed. Supporting QoS markings would be a good idea though.

(3) Section 1.4 and beyond. The word “authority”, “authority component”, 
“authority section” are all used to mean the same thing, but without further 
explanation as to what this means. The inconsistency is confusing. But more 
importantly, it isn’t clear to the reader in those earlier sections that each 
“authority *" is a forward reference to the “authority element” in the URL 
definition (Section 5)  It would clearer if these references said something 
like “authority element of the MUD URL”.

(4) Section 1.6. Regarding this text: "In the case of IEEE 802.1X, the switch 
would tunnel the URI via a certificate ….”.  The URI isn’t really “tunneled”. 
How about, "In the case of IEEE 802.1X, the switch would present a certificate 
containing the URI …”.

(5) Section 3.2. For "it should not be necessary to resign a MUD file when a 
new one is released”, I believe you mean that the MUD file does not not need to 
be signed again (“re-sign”). Or do you really mean that the manufacturer will 
“resign” (e.g., “leave” or “stand down”) the MUD file by moving it to the 
archival location? If so, this needs to be clearer.

(6) Section 3.12. This section mentions "standard classes”. There’s should be a 
reference to what those classes would be, or more text describing what is a 
“standard class”. Should there be an IANA registry of “standard classes”?

Thanks,
Brian


On Mar 17, 2017, at 3:17 AM, Tianran Zhou 
mailto:zhoutian...@huawei.com>> wrote:

Dear OPSAWG,

This is a notice to start a two-week OPSAWG WG last call for the document:

Manufacturer Usage Description Specification
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

Please read the above draft and send any issues, comments, or corrections to 
this mailing list.
Please indicate your support or concerns by Friday March 31, 2017.

Thanks,
Chairs

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: b...@cisco.com

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Comment on draft-pularikkal-opsawg-wifi-calling

[Joe Clarke]

Allow me to channel my fellow IETF NOC colleague Clemens and offer one
comment on the WiFi calling draft.

Add a bit on NAT.  We found in Korea that someone was trying to use
iPhone WiFi calling to Europe.  Because we used a public IPv4 address
space, the IPSec NAT detection algorithm found no NAT and used pure ESP
for the tunnel.  This particular provider had not seen this before and
their firewall didn't allow for ESP (only tunneled udp/4500).

If the draft could mention that some WiFi hotspots do not use NAT
(especially in the IPv6 space) and to make sure that the proper
allowance for security is taken, I think that would be helpful.

Joe

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Progress of draft-ietf-netmod-yang-model-classification and draft-wu-opsawg-service-model-explained

[Adrian Farrel]

Hi,

As just stated at the mic in the OPS Area meeting, I met with Dean Bogdanovic
today to discuss the overlap/underlap between these two drafts.

1. We went through the text changes to
draft-ietf-netmod-yang-model-classification and I am happy that changes in the
-05 revision address the questions I have been asking. I do see two nits:
a. draft-ietf-l3sm-l3vpn-service-model is now RFC 8049
b. The paragraph that references that document is perfect and correct, but may
be slightly out of place as its current position suggests that it is a "Network
Service model" where I think that Dean and I have agreed that it is actually one
level higher (a business service model in his language) and so basically out of
scope of this document.
I would suggest moving this paragraph to be the last paragraph in Section 2.1.

2. draft-wu-opsawg-service-model-explained
We will revise this document to align a little more closely with the language in
draft-ietf-netmod-yang-model-classification and (more important) to not re-state
(even in different language) what is in
draft-ietf-netmod-yang-model-classification.
I believe this will address all open worries in the document that have been
expressed on the list.

Thanks,
Adrian

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Notes and Jabber for OPSAWG meeting

[Ignas Bagdonas]

Hi,

OPSAWG is meeting soon, note taking and jabber room monitoring seem to 
be just the right snoozing mode tasks after a nice lunch. Please could 
any volunteers for notes or Etherpad and jabber come forward?


Thank you.


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg