Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call

[Tianran Zhou]

Thanks Warren very much for the suggestions from the AD side.
Base on AD suggestions, I with the WG Chair role, would like to:
1. Let the authors to discuss the relation between the IPR and the draft, and 
get wider WG awareness. 
2. Base on the above, see if the authors need to update the IPR disclosure.
3. Ask the consensus again before sending to IESG.

Thanks,
Tianran 

> -Original Message-
> From: Warren Kumari [mailto:war...@kumari.net]
> Sent: Wednesday, April 18, 2018 4:52 AM
> To: Joel M. Halpern 
> Cc: Tianran Zhou ; opsawg@ietf.org
> Subject: Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR
> call
> 
> Noting that I am not the responsible AD for this
> 
> The IPR had been disclosed shortly after the call for adoption, and so the
> WG was "aware" of it when the WGLC occurred -- however, it is very easy to
> forget that there is IPR during the WGLC, which is why RFC7602 says (emphasis
> mine):
> 
> "The chairs *might* also wish to include a reminder about  the importance
> of IPR disclosures in any WGLC message communicated to  the working group.
> (Note: If IPR disclosure statements have been  filed, the chairs *might* wish
> to include a link in the WGLC message to  ensure that the consensus call
> reflects this information.)"
> 
> Section 6 of this also says: "WG chairs and ADs are not expected to enforce
> IPR disclosure rules, and this document does not suggest that they take on
> such a role.", however, RFC8179 says:
> "The IETF policies about Intellectual Property Rights (IPR), such as
>patent rights, relative to technologies developed in the IETF are
>designed to ensure that IETF working groups and participants have as
>much information as possible about any IPR constraints on a technical
>proposal as early as possible in the development process. "
> and
> "5.4.2. Updating IPR Disclosures
> 
>Those who disclose IPR should be aware that as Internet-Drafts
>evolve, text may be added or removed, and it is recommended that they
>keep this in mind when composing text for disclosures.
> 
>A. Unless sufficient information to identify the issued patent was
>   disclosed when the patent application was disclosed, an IPR
>   disclosure must be updated or a new disclosure made promptly after
>   any of the following has occurred: (1) the publication of a
>   previously unpublished patent application, (2) the abandonment of
>   a patent application, (3) the issuance of a patent on a previously
>   disclosed patent application, or (4) a material change to the IETF
>   Document covered by the Disclosure that causes the Disclosure to
>   be covered by additional IPR.  If the patent application was
>   abandoned, then the new IPR disclosure must explicitly withdraw
>   any earlier IPR disclosures based on the application.  IPR
>   disclosures against a particular Contribution are assumed to be
>   inherited by revisions of the Contribution and by any RFCs that
>   are published from the Contribution unless the disclosure has been
>   updated or withdrawn."
> 
> 
> Again noting that I am not currently the responsible AD for the WG, I was
> when the WGLC occurred. So, I think that I'm within my rights to suggest that
> the chairs:
> 1: Suggest that the author who originally had the disclosure made (thank you,
> this was the right thing to do!) remind their lawyers of the requirement in
> RFC8179 Section 5.4.2
> 2: As you are raising concerns about whether everyone was aware (and state
> that at least one person wasn't) that the chairs ask if anyone who previously
> expressed support for progressing the document has changed their views
> **because** they were not aware of the existence of the IPR disclosure.
> before sending it to the IESG.
> 
> 
> Please please also keep in mind that:
> "(a) The IETF will make no determination about the validity of any
>particular IPR claim.
> 
>(b) The IETF, following normal processes, can decide to use
>technology for which IPR disclosures have been made if it decides
>that such a use is warranted."
> 
> (and everything else in RFC8129, RFC2026, BCP79, etc).
> 
> W
> 
> 
> 
> 
> 
> On Tue, Apr 17, 2018 at 8:41 AM, Joel M. Halpern  wrote:
> > As far as I can tell, the formal IPR disclosure with IPR terms was not
> > filed until several days after that request.
> > Thus, the WG can not have considered it in the light of the actual terms.
> >
> > When I asked one WG participant, he was quite surprised by the terms.
> >
> > Given the difficulty both Huawei and Ericsson have gotten from IETF
> > participants over similar terms, I do not think this can be ignored.
> >
> > Yours,
> > Joel
> >
> > On 4/17/18 1:12 AM, Tianran Zhou wrote:
> >>
> >> Hi Joel,
> >>
> >> Thanks for reminding this important information.
> >> Yes, we did the IPR poll when it became a WG draft. 

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[Tianran Zhou]

I think it worth the authors can discuss about this IPR in the WG before 
sending the draft to IESG.

Tianran



Sent from WeLink

发件人： heasley
收件人： li 
zhenqiang>;rtg-dir>;gen-art>;draft-ietf-opsawg-ipfix-bgp-community.all>;ietf>;opsawg>
主题： Re: Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
时间： 2018-04-17 23:49:16

Why is there IPR on this draft?  Is this because of section 3?  A section
that is unnecessary and could be entirely removed without affecting the
draft in any manner?

Otherwise, I think it absolutely absurd that there is IPR on this document.
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call

[Warren Kumari]

Noting that I am not the responsible AD for this

The IPR had been disclosed shortly after the call for adoption, and so
the WG was "aware" of it when the WGLC occurred -- however, it is very
easy to forget that there is IPR during the WGLC, which is why RFC7602
says (emphasis mine):

"The chairs *might* also wish to include a reminder about
 the importance of IPR disclosures in any WGLC message communicated to
 the working group.  (Note: If IPR disclosure statements have been
 filed, the chairs *might* wish to include a link in the WGLC message to
 ensure that the consensus call reflects this information.)"

Section 6 of this also says: "WG chairs and ADs are not expected to
enforce IPR disclosure rules, and this document does not suggest that
they take on such a role.", however, RFC8179 says:
"The IETF policies about Intellectual Property Rights (IPR), such as
   patent rights, relative to technologies developed in the IETF are
   designed to ensure that IETF working groups and participants have as
   much information as possible about any IPR constraints on a technical
   proposal as early as possible in the development process. "
and
"5.4.2. Updating IPR Disclosures

   Those who disclose IPR should be aware that as Internet-Drafts
   evolve, text may be added or removed, and it is recommended that they
   keep this in mind when composing text for disclosures.

   A. Unless sufficient information to identify the issued patent was
  disclosed when the patent application was disclosed, an IPR
  disclosure must be updated or a new disclosure made promptly after
  any of the following has occurred: (1) the publication of a
  previously unpublished patent application, (2) the abandonment of
  a patent application, (3) the issuance of a patent on a previously
  disclosed patent application, or (4) a material change to the IETF
  Document covered by the Disclosure that causes the Disclosure to
  be covered by additional IPR.  If the patent application was
  abandoned, then the new IPR disclosure must explicitly withdraw
  any earlier IPR disclosures based on the application.  IPR
  disclosures against a particular Contribution are assumed to be
  inherited by revisions of the Contribution and by any RFCs that
  are published from the Contribution unless the disclosure has been
  updated or withdrawn."


Again noting that I am not currently the responsible AD for the WG, I
was when the WGLC occurred. So, I think that I'm within my rights to
suggest that the chairs:
1: Suggest that the author who originally had the disclosure made
(thank you, this was the right thing to do!) remind their lawyers of
the requirement in RFC8179 Section 5.4.2
2: As you are raising concerns about whether everyone was aware (and
state that at least one person wasn't) that the chairs ask if anyone
who previously expressed support for progressing the document has
changed their views **because** they were not aware of the existence
of the IPR disclosure.
before sending it to the IESG.


Please please also keep in mind that:
"(a) The IETF will make no determination about the validity of any
   particular IPR claim.

   (b) The IETF, following normal processes, can decide to use
   technology for which IPR disclosures have been made if it decides
   that such a use is warranted."

(and everything else in RFC8129, RFC2026, BCP79, etc).

W





On Tue, Apr 17, 2018 at 8:41 AM, Joel M. Halpern  wrote:
> As far as I can tell, the formal IPR disclosure with IPR terms was not filed
> until several days after that request.
> Thus, the WG can not have considered it in the light of the actual terms.
>
> When I asked one WG participant, he was quite surprised by the terms.
>
> Given the difficulty both Huawei and Ericsson have gotten from IETF
> participants over similar terms, I do not think this can be ignored.
>
> Yours,
> Joel
>
> On 4/17/18 1:12 AM, Tianran Zhou wrote:
>>
>> Hi Joel,
>>
>> Thanks for reminding this important information.
>> Yes, we did the IPR poll when it became a WG draft. The IPR was disclosed
>> then. Please see
>> https://www.ietf.org/mail-archive/web/opsawg/current/msg04792.html
>> We did not received any objection based on this.
>>
>> Thanks,
>> Tianran
>>>
>>> -Original Message-
>>> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
>>> Sent: Tuesday, April 17, 2018 8:25 AM
>>> To: opsawg-cha...@ietf.org
>>> Subject: regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call
>>>
>>> Is the working group aware of the IPR disclosure China Mobile made
>>> against
>>> this document?  Specifically, that the IPR disclosure says that a license
>>> may be required?
>>>
>>> Normally, I would not even comment on that, and as you can see, I am not
>>> commenting on the list about it.
>>>
>>> But I note that this is a case where there is a clear workaround (just
>>> don't
>>> do this).  So I would expect that the shepherd report, 

Re: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eliot Lear]

Hi Ben,

Maybe we can swat two birds with one stone here, so to speak.  I think
both EKR and I have been ruminating on the right text, and hopefully
between the three of us, and perhaps others from the community we can
zero in on what is needed.  


On 17.04.18 17:31, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> DISCUSS:
> --
>
> Hopefully this will be an easy DISCUSS to clear.
>
> Partially guided by some of the discussion that has already happened, it seems
> like there are three places where authentication/identity validation occurs in
> the MUD flow: the (CMS) signature alongside the MUD file, the TLS connection
> used to retrieve the MUD file, and the binding between the MUD URL and the
> device itself.  The last one seems pretty important, especially given some of
> the points in Ekr's DISCUSS about limiting damage in case of
> compromised/malicious device.  The security considerations already give some
> coverage in the first paragraph, but basically limited to the "manufacturer"
> groupings, and only covers the usage of the certificate extension for binding 
> a
> MUD URL to a specific device.  There's also some related text when considering
> what to do if the MUD URL for a given MAC address changes, but I didn't see 
> any
> coverage for the general case.  The entity using the MUD contents needs to be
> aware of the provenance of the URL and the risks of using a "spoofed" MUD from
> an attacker.

I think EKR's last statement jibes well with what you are saying.  I
propose an amended first paragraph of the security considerations
section, to address that last point as follows:
> Devices emitting MUD URLs that are not signed by someone else may lie,
> potentially gaining additional network access by pretending to be
> something it is not.  In these cases, while we describe some
> mitigations below, a risk of lying remains in some circumstances,
> particularly when a device may masquerade as another device that has
> already been approved to be on the network, but it isn't currently
> connected.  There are two overarching mitigations for this case:
>
>  * Best mitigation: devices should migrate to the use of  802.1AR
> certificate.
>  * 2nd best mitigation: do not grant such devices access to critical
>    resources, recognizing that attackers may be masquerading as
>    them.
>
> In addition, even those    devices    that do    have manufacturer
> certificates
> may be attackers.  MUD managers    that do    not recognize a  
>  signer MUST
> seek approval of the administrator prior to further processing.
>
> Additional mitigations are described below.
>
> When certificates are not present, Things claiming to be of a certain
> manufacturer SHOULD NOT be included in that manufacturer grouping
> without additional validation of some form. 

--

The LLDP and DHCP options are not nothing.  In the context of a
physically secure environment they can go a long way and at least deter
if not stop a fair amount of nonsense.  But they are by no means perfect.

With this having been said, I hope you would both be comfortable with
the above text, or perhaps with some additional suggestions.


>
>
> --
> COMMENT:
> --
>
> It's pretty exciting to have the prospect of getting this kind of information
> out there in a standard, machine-readable format.  That said ... there's been 
> a
> decent amount of talk of "still getting feet wet", "need to get experience how
> this unfolds", etc., so I have to ask: are we confident that this is better as
> Proposed Standard than Experimental?

There's good reason to get to proposed.  We will never get enough
manufacturers to get the operational experience we need to get to the
next stage if it is not.  Vendors in this arena simply don't move on
experimental work.

> Adding the ability to use DNS names in ACL 'match' patterns should probably be
> accompanied by some note about the (lack of) veracity of DNS information.  
> This
> is not a DISCUSS since the DNS name is expected to be what the Thing actually
> attempts to use, and the DNS resolver used by the Thing is likely to be the
> same one as used by the network, so in that sense the ACL will still "work as
> 

Re: [OPSAWG] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06

[heasley]

Why is there IPR on this draft?  Is this because of section 3?  A section
that is unnecessary and could be entirely removed without affecting the
draft in any manner?

Otherwise, I think it absolutely absurd that there is IPR on this document.

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

[OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Benjamin Kaduk]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



--
DISCUSS:
--

Hopefully this will be an easy DISCUSS to clear.

Partially guided by some of the discussion that has already happened, it seems
like there are three places where authentication/identity validation occurs in
the MUD flow: the (CMS) signature alongside the MUD file, the TLS connection
used to retrieve the MUD file, and the binding between the MUD URL and the
device itself.  The last one seems pretty important, especially given some of
the points in Ekr's DISCUSS about limiting damage in case of
compromised/malicious device.  The security considerations already give some
coverage in the first paragraph, but basically limited to the "manufacturer"
groupings, and only covers the usage of the certificate extension for binding a
MUD URL to a specific device.  There's also some related text when considering
what to do if the MUD URL for a given MAC address changes, but I didn't see any
coverage for the general case.  The entity using the MUD contents needs to be
aware of the provenance of the URL and the risks of using a "spoofed" MUD from
an attacker.


--
COMMENT:
--

It's pretty exciting to have the prospect of getting this kind of information
out there in a standard, machine-readable format.  That said ... there's been a
decent amount of talk of "still getting feet wet", "need to get experience how
this unfolds", etc., so I have to ask: are we confident that this is better as
Proposed Standard than Experimental?

Adding the ability to use DNS names in ACL 'match' patterns should probably be
accompanied by some note about the (lack of) veracity of DNS information.  This
is not a DISCUSS since the DNS name is expected to be what the Thing actually
attempts to use, and the DNS resolver used by the Thing is likely to be the
same one as used by the network, so in that sense the ACL will still "work as
intended" even in the face of spoofed DNS.  But we can probably mention that
it's still a risk.

I echo Ekr's question about CMS vs. JWS.

Please consider using the BCP 14/RFC8174 boilerplate.

Other comments (in document order, sorry about the interspersed nits).

Section 1

   o  Substantially reduce the threat surface on a device entering a
  network to those communications intended by the manufacturer.

Comma after 'network'?

Section 1.5

  [...] The DHCP server may take further actions,
  such as retrieve the URL or otherwise pass it along to network
  management system or controller.

Retrieve the resource from the URL?

Section 1.7

   my-controller:  Devices associated with the MUD URL of a device that
  the administrator admits.

I'm probably just being dumb, but I am failing to parse what this
means.

Section 1.8

   The information returned by the MUD file server (a web server) is
   valid for the duration of the Thing's connection, or as specified in
   the description.  Thus if the Thing is disconnected, any associated
   configuration in the switch can be removed.  Similarly, from time to
   time the description may be refreshed, based on new capabilities or
   communication patterns or vulnerabilities.

This feels slightly internally inconsistent about valid/refreshed.

Section 12.2

"Prior to retrieving a MUD file [...] validating the signature
across the MUD file" is internally inconsistent.  Perhaps the first
pargaraph is stale, since the second paragraph basically duplicates
it?

Also,
   [...] For another, what is more important
   is the accountability of the recommendation, and not the
   cryptographic relationship between the device and the file.
seems not really true.

   An example:

   % openssl cms -verify -in mudfile.p7s -inform DER -content
   % mudfile

   Note the additional step of verifying the common trust root.

The additional step that's not included in the example?  Maybe it
could be included?

Section 15

Lots of tiny comments, so I'll quote and put inline.

% Based on how a MUD URL is emitted, a Thing may be able to lie about

s/emitted/conveyed to the network/?

% what it is, thus gaining additional network access.  There are

s/thus/potentially/
And maybe clarify ", based on the (false) MUD that is claimed"?

% several means to limit risk in 

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

[Alan DeKok]

On Apr 17, 2018, at 10:15 AM, Douglas Gash (dcmgash)  wrote:
> Initially (up to around version 5) we included just a very simple security 
> section admitting that T+ was insecure and that the second document would 
> address the issue. This was deemed to be insufficient, and instead the WG 
> collectively determined that more detail should be added to enumerate some of 
> the issues, you kindly catalogued some of these, providing a proposed text 
> which we took to be a genuine suggestion for text for the document.

  Which it was.

  The point I've been trying to make for over a year is apparently still 
unclear.

  There was no excuse for plagiarizing the text in the first place.  Using it 
verbatim was fine, so long as attribution was given.

  There was no excuse for ignoring every single email I made to the list asking 
about this issue.

  There was no excuse for *continuing* to plagiarize the text for over a year, 
across four separate revisions of the document.

> Subsequently we interpreted your proposal more accurately (as just a 
> suggestion of the points to cover), and so we made sure that these were 
> covered, but without verbatim reuse of the text.  We hope that we have 
> covered the thrust of your issues (and others), but without the plagiarism.

  I have no idea.  Because at this point, I'm pretty much done reviewing the 
document.

> 2) Reactivity of the Authors.
> 
> As far as I know, we have responded to most posts regarding the content of 
> the document, with point-by-point replies,

  No.

  See the list archives, especially May 2017.  There are multiple people 
suggesting that you have *not* done this, and that you *should* do this.

  See line-by-line reviews done by me, which were generally ignored.  Despite 
that, I did *multiple* such reviews, until such time as it became clear that 
such reviews were entirely unproductive.

> but there has been, for various logistic reasons, long delays in submitting 
> the resulting new documents. Hopefully this has been addresses in last 
> versions and we will continue with more rapid uploads until process completes 
> one way or other.

  The issue isn't rapid uploads.  The issue is engagement.  It's not productive 
to ignore the messages on the mailing list for 6 months, and then to issue a 
new release saying "we fixed stuff".

> We have not generally responded to posts regarding procedural matters, and 
> would leave such discussions to more knowledgeable stewards of the lists 
> where possible,

  You haven't responded to posts where I ask about the plagiarism.  A simple 
reply of "oops, sorry, I'll fix it ASAP" has taken over a year to write.

> 3) Change Tracking
> 
> The uploads have generally had extensive changes relating to comments (which 
> should generally have been summarized by previous email responses to 
> comments). 

  Which I admit did happen sometimes, but not nearly as often as it should 
have.  Again, see mailing list archives from May 2017.  I'm not the only person 
who holds this opinion.  I'm just the main one pushing the point.

> Because of this, unless the updates have been for specific purposes (such as 
> the recent update of the security section) then I would leave the changes to 
> the diff tool which works pretty effectively.

  The diff tool lets us know what changed in the document.  It doesn't let us 
know if those changes addressed issues raise on the mailing list.

  To summarize:

* we have no idea if this revision of the document addresses multiple WG reviews

* we have no idea if the document even describes TACACS+ as currently 
implemented

  As such, it should not be put into working group last call, or much less 
published until such time as those issues are addressed.

  Alan DeKok.

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

Re: [OPSAWG] New Version Notification for draft-ietf-opsawg-tacacs-10.txt

[Douglas Gash (dcmgash)]

Hi Alan,

I hope that we can address your concerns. I think the main points that you 
raise the we (the authors) need to address are:

1) The security section
2) Reactivity of the authors 
3) Change Tracking

1) The Security Section

The starting point is that we know that TACACS+ needs enhancement from security 
perspective. That was the reason that this process was initiated, the first 
document being mainly an adaption of the original draft with security features 
plus some minor cleansing. This plan was evolved into two documents, the first, 
that we are in process of preparing, that codifies the protocol, to be followed 
by the version with enhanced security.

Initially (up to around version 5) we included just a very simple security 
section admitting that T+ was insecure and that the second document would 
address the issue. This was deemed to be insufficient, and instead the WG 
collectively determined that more detail should be added to enumerate some of 
the issues, you kindly catalogued some of these, providing a proposed text 
which we took to be a genuine suggestion for text for the document. 
Subsequently we interpreted your proposal more accurately (as just a suggestion 
of the points to cover), and so we made sure that these were covered, but 
without verbatim reuse of the text.  We hope that we have covered the thrust of 
your issues (and others), but without the plagiarism.

2) Reactivity of the Authors.

As far as I know, we have responded to most posts regarding the content of the 
document, with point-by-point replies, but there has been, for various logistic 
reasons, long delays in submitting the resulting new documents. Hopefully this 
has been addresses in last versions and we will continue with more rapid 
uploads until process completes one way or other.

We have not generally responded to posts regarding procedural matters, and 
would leave such discussions to more knowledgeable stewards of the lists where 
possible,

3) Change Tracking

The uploads have generally had extensive changes relating to comments (which 
should generally have been summarized by previous email responses to comments). 
Because of this, unless the updates have been for specific purposes (such as 
the recent update of the security section) then I would leave the changes to 
the diff tool which works pretty effectively.

Please let us know if there are specific points below that you’d like to 
address which would not be covered above.

Many thanks,

Regards,

Doug


 Responding to:

“I have some concerns with the document, and with the process by which we've 
gotten here.

  Let me recap some history.  There's a lot to take
in, so I'll present concerns in point form.

  First, the document.

* my "Security Considerations" text was first plagarised in draft-06,

* when I pointed this out (May 9, 2017), there was no reply to my
  message by the authors, and no change was made to the document.

* the ADs did respond, and indicated that they had talked to the
  authors about the issue, and that it was a simple misunderstand and
  would be fixed.

* A year later, I raised the issue again (March 2018).  There as no
  reply to my concerns by the authors, and no change was made to the
  document.

* in all, 4 separate revisions of the document plagarized my text, for
  over a year, sometimes with minor edits, despite repeated requests
  to address the issue.

  Those issues alone are surprising.

* The text which was good enough to plagarize was then claimed to have
  deficiencies

* no one in the WG had noted any technical issues with the text

* the only issues were with attribution, not with the text in the
  Security Considerations section

* there is now a -10, which has essentially the same points as the
  previous text, just reworded






  I should point out that the RFC process is supposed to be about
content, not authorship.  There are many RFCs issued with text written
by multiple people.  Where the authors cannot all be acknowledged on
the first page, the primary editor can be listed with the (Ed.)
suffix, to indicate editorship.  Other authors can be named as authors
on the first page, or in the Acknowledgements section.

  Second, concerns with engagement with the WG.  It continues.

* multiple people in the WG have requested the authors engage with the
  Working Group.  Most notably, many messages in May 2017.

* multiple people in the WG have requested the authors explain what's
  changed in each new revision, or perhaps to acknowlege comments and
  reviews (May 2017 again, among other times).

* This engagement has been minimal, despite multiple revisions of
  the document being published after these WG requests.

* new revisions have most often been "thrown over the wall" with
  minimal (or no) explanation as to what changed, and why.

* this new draft is no different, i.e. it "revised the security
  section".  Why?  How?  What changed?  What were any alleged
  "deficiencies"?

* the author have 

[OPSAWG] Ignas Bagdonas' No Objection on draft-ietf-opsawg-mud-20: (with COMMENT)

[Ignas Bagdonas]

Ignas Bagdonas has entered the following ballot position for
draft-ietf-opsawg-mud-20: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



--
COMMENT:
--

S2.1: Valid MUD file will contain "mud" and "acls" containers - what if it does
not, especially if it does not contain an ACL container - how will the
connectivity requirement be interpreted then?

A few nits:

s/MUR-URL/MUD-URL

s/yang/YANG in the document and module description fields.

s/dns/DNS in the modules.

S1, MUD building blocks section: "A URL that is can be used"


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

Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Eliot Lear]

On 17.04.18 14:44, Spencer Dawkins at IETF wrote:
> Hi, Eliot,
>
> On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear  > wrote:
>
> Responding to Spencer, Ben, and Alexy (in order).
>
>
> On 16.04.18 21:09, Spencer Dawkins wrote:
>> Spencer Dawkins has entered the following ballot position for
>> draft-ietf-opsawg-mud-20: Yes
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> 
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>> 
>>
>>
>>
>> --
>> COMMENT:
>> --
>>
>> I'm a Yes who's watching Discussions with other ADs, but that's still a 
>> Yes.
>> Thanks for doing this work.
>>
>> I do have some questions and comments.
>>
>> I don't think this requires any changes to the current document, but I 
>> note that
>>
>> 3.15.  direction-initiated
>>
>>When applied this matches packets when the flow was initiated in the
>>corresponding direction.  [RFC6092] specifies IPv6 guidance best
>>practices.  While that document is scoped specifically to IPv6, its
>>contents are applicable for IPv4 as well.  When this flag is set, and
>>the system has no reason to believe a flow has been initiated it MUST
>>drop the packet.  This node may be implemented in its simplest form
>>by looking at naked SYN bits, but may also be implemented through
>>more stateful mechanisms.
>>
>> it's not clear that "looking at naked SYN bits" will have an analogy in 
>> HTTP/2
>> over QUIC, and I'm a bit suspicious of "may also be implemented through 
>> more
>> stateful mechanisms" in 2018. Do the right thing, of course.
>
> I proposed a clarification: direction initiated is a TCP element.
>
>
> That is a clarification. 
>
> I guess what I'm thinking, on reflection, is that direction is likely
> to be helpful for TCP-based communication, is not likely to be helpful
> for UDP-based communication without stateful inspection (so, my camera
> probably does need to act as a DNS client, but probably doesn't need
> to act as a DNS server), and is likely to be increasingly unhelpful if
> we really do see things using encrypted, UDP-based transports like QUIC. 
>
> This does poke the "how are network managers going to manage networks
> running encrypted, UDP-based transport" bear, but that's way bigger
> than this document. Say as much as you think is helpful, and then move
> on, I think.

Well indeed.  I think the key here is to recognize that all MUD can do
is invoke network management capabilities already present in the
infrastructure.  "Picture if you will", however, a MUD extension that
modifies the meaning of "direction-initiated" to say, please do stateful
to allow stuff outbound, and re-adds the element in the UDP context. 
Absolutely possible.  I think it's a matter of whether the underlying
infrastructure broadly supports such a capability.



>> Does
>>
>> 3.5.  is-supported
>>
>>This boolean is an indication from the manufacturer to the network
>>administrator as to whether or not the Thing is supported.  In this
>>context a Thing is said to not be supported if the manufacturer
>>intends never to issue an update to the Thing or never update the MUD
>>file.  A MUD controller MAY still periodically check for updates.
>>
>> ever mean anything except "is-updated"? 
>
> Mostly that what it means, but the implication is that there's no
> support, and enterprise administrators in particular might want to
> know that (usually they do- because those devices represent a
> particular risk).
>
>
>  Here, I must apologize, because I've been thinking of MUD as the
> other side of a coin that also has SUIT, TEEP, and similar tools - If
> your Thing is just being installed and forgotten until it's an attack
> platform, you need MUD descriptions, but if your Thing is going to be
> updated, you should be looking at SUIT, TEEP, and whatever else seems
> helpful. 
>
> I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
> that's a lack of imagination on my part, but the most relevant side
> effect of that, is that if you know what your printer needs to do, to
> be a network printer, and you get a MUD description for it, and the
> printer isn't going to be 

Re: [OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Eliot,

On Tue, Apr 17, 2018 at 1:43 AM, Eliot Lear  wrote:

> Responding to Spencer, Ben, and Alexy (in order).
>
> On 16.04.18 21:09, Spencer Dawkins wrote:
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found 
> here:https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> COMMENT:
> --
>
> I'm a Yes who's watching Discussions with other ADs, but that's still a Yes.
> Thanks for doing this work.
>
> I do have some questions and comments.
>
> I don't think this requires any changes to the current document, but I note 
> that
>
> 3.15.  direction-initiated
>
>When applied this matches packets when the flow was initiated in the
>corresponding direction.  [RFC6092] specifies IPv6 guidance best
>practices.  While that document is scoped specifically to IPv6, its
>contents are applicable for IPv4 as well.  When this flag is set, and
>the system has no reason to believe a flow has been initiated it MUST
>drop the packet.  This node may be implemented in its simplest form
>by looking at naked SYN bits, but may also be implemented through
>more stateful mechanisms.
>
> it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2
> over QUIC, and I'm a bit suspicious of "may also be implemented through more
> stateful mechanisms" in 2018. Do the right thing, of course.
>
>
> I proposed a clarification: direction initiated is a TCP element.
>

That is a clarification.

I guess what I'm thinking, on reflection, is that direction is likely to be
helpful for TCP-based communication, is not likely to be helpful for
UDP-based communication without stateful inspection (so, my camera probably
does need to act as a DNS client, but probably doesn't need to act as a DNS
server), and is likely to be increasingly unhelpful if we really do see
things using encrypted, UDP-based transports like QUIC.

This does poke the "how are network managers going to manage networks
running encrypted, UDP-based transport" bear, but that's way bigger than
this document. Say as much as you think is helpful, and then move on, I
think.

> Does
>
> 3.5.  is-supported
>
>This boolean is an indication from the manufacturer to the network
>administrator as to whether or not the Thing is supported.  In this
>context a Thing is said to not be supported if the manufacturer
>intends never to issue an update to the Thing or never update the MUD
>file.  A MUD controller MAY still periodically check for updates.
>
> ever mean anything except "is-updated"?
>
>
> Mostly that what it means, but the implication is that there's no support,
> and enterprise administrators in particular might want to know that
> (usually they do- because those devices represent a particular risk).
>

 Here, I must apologize, because I've been thinking of MUD as the other
side of a coin that also has SUIT, TEEP, and similar tools - If your Thing
is just being installed and forgotten until it's an attack platform, you
need MUD descriptions, but if your Thing is going to be updated, you should
be looking at SUIT, TEEP, and whatever else seems helpful.

I had not been thinking of using both MUD and SUIT/TEEP/whatever, and
that's a lack of imagination on my part, but the most relevant side effect
of that, is that if you know what your printer needs to do, to be a network
printer, and you get a MUD description for it, and the printer isn't going
to be updated, that MUD description should be fine, forever.

I'm still connecting dots.

> "Supported" covers a lot of ground …
>
> If a manufacturer sells off one product line (so, flobbidy.example.com covered
> multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be
> maintained by a manufacturer that isn't flobbidy.example.com), is there a good
> plan for what comes next? I'm not sure what happens to is-supported, for
> instance.
>
>
> The intent is that the entity providing the MUD file (probably the
> manufacturer) will not be issuing software/firmware updates or MUD file
> updates.  But your point is more about device lifecycle, and that's a more
> interesting question than just "is-supported".  Steve Rich and Thorsten
> Dahm have begun to delve in that direction.  There are at least a few
> possibilities, such as the use of redirects, or even domain names that are
> used for particular classes of devices, or even common repos.  More work
> needed.

Re: [OPSAWG] regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call

[Joel M. Halpern]

As far as I can tell, the formal IPR disclosure with IPR terms was not 
filed until several days after that request.

Thus, the WG can not have considered it in the light of the actual terms.

When I asked one WG participant, he was quite surprised by the terms.

Given the difficulty both Huawei and Ericsson have gotten from IETF 
participants over similar terms, I do not think this can be ignored.


Yours,
Joel

On 4/17/18 1:12 AM, Tianran Zhou wrote:

Hi Joel,

Thanks for reminding this important information.
Yes, we did the IPR poll when it became a WG draft. The IPR was disclosed then. 
Please see
https://www.ietf.org/mail-archive/web/opsawg/current/msg04792.html
We did not received any objection based on this.

Thanks,
Tianran

-Original Message-
From: Joel M. Halpern [mailto:j...@joelhalpern.com]
Sent: Tuesday, April 17, 2018 8:25 AM
To: opsawg-cha...@ietf.org
Subject: regarding draft-ietf-opsawg-ipfix-bgp-community: IPR call

Is the working group aware of the IPR disclosure China Mobile made against
this document?  Specifically, that the IPR disclosure says that a license
may be required?

Normally, I would not even comment on that, and as you can see, I am not
commenting on the list about it.

But I note that this is a case where there is a clear workaround (just don't
do this).  So I would expect that the shepherd report, whenever that is
produced, will need to discuss the IPR disclosure.

Yours,
Joel


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

Re: [OPSAWG] Alexey Melnikov's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Eliot Lear]

Hi Alexey,


On 17.04.18 13:35, Alexey Melnikov wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> COMMENT:
> --
>
> 3.6.  systeminfo
>
>This is a textual UTF-8 description of the Thing to be connected.
>The intent is for administrators to be able to see a localized name
>associated with the Thing.
>
> systeminfo is provided by the manufacturer (or whoever generated the MUD 
> file),
> right? Why would it be *localized* for the administrator? Think of a
> manufacturer from China and a sysadmin in Russia.

Yes, that was a spurious leftover from earlier versions.  It is gone in
my copy.  I  do wish we could have done better at this, but with the
response Robert's review, I hope I can at least get a link that people
can copy into their browsers to actually find localized content.

>
> 3.13.  controller
>
>This URI specifies a value that a controller will register with the
>MUD controller.  The node then is expanded to the set of hosts that
>are so registered.  This node may also be a URN.  In this case, the
>URN describes a well known service, such as DNS or NTP.
>
> You don't list the DNS/NTP URNs until much later in the document. Please 
> either
> add a forward reference or list them here.

Ok.  Will add forward reference.

And indeed the below are corrected in my copy.

Thanks for improving the work,

Eliot

>
> As per response from Eliot, my earlier comments should have been addressed in
> editor's copy:
>
> 16.4.  MIME Media-type Registration for MUD files
>
>The following media-type is defined for transfer of MUD file:
>
> o Type name: application
> o Subtype name: mud+json
> o Required parameters: n/a
> o Optional parameters: n/a
> o Encoding considerations: 8bit; application/mud+json values
>   are represented as a JSON object; UTF-8 encoding SHOULD be
>   employed.
>
> I am tempted to say "MUST be UTF-8 encoded".
>
> o Security considerations: See Security Considerations
>   of this document.
> o Interoperability considerations: n/a
> o Published specification: this document
>
> Nit: IANA Media Type registration templates need to have fully qualified
> references. Use "[RFC]" instead of "this document" here, so that when the
> RFC is published, the registration template can be posted to IANA website and
> will have correct reference.
>
> o Applications that use this media type: MUD controllers as
>   specified by this document.
>
> As above.
>
> o Fragment identifier considerations: n/a
> o Additional information:
>
> Magic number(s): n/a
> File extension(s): n/a
> Macintosh file type code(s): n/a
>
> o Person & email address to contact for further information:
>   Eliot Lear , Ralph Droms 
>
> I think Ralph's address is wrong in 2 places.
>
> o Intended usage: COMMON
> o Restrictions on usage: none
> o Author:
>  Eliot Lear 
>  Ralph Droms 
> o Change controller: IESG
> o Provisional registration? (standards tree only): No.
>
> UTF-8 needs to be a Normative reference (RFC 3629).
>
>
>




signature.asc
Description: OpenPGP digital signature
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Alexey Melnikov's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-opsawg-mud-20: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/



--
COMMENT:
--

3.6.  systeminfo

   This is a textual UTF-8 description of the Thing to be connected.
   The intent is for administrators to be able to see a localized name
   associated with the Thing.

systeminfo is provided by the manufacturer (or whoever generated the MUD file),
right? Why would it be *localized* for the administrator? Think of a
manufacturer from China and a sysadmin in Russia.

3.13.  controller

   This URI specifies a value that a controller will register with the
   MUD controller.  The node then is expanded to the set of hosts that
   are so registered.  This node may also be a URN.  In this case, the
   URN describes a well known service, such as DNS or NTP.

You don't list the DNS/NTP URNs until much later in the document. Please either
add a forward reference or list them here.

As per response from Eliot, my earlier comments should have been addressed in
editor's copy:

16.4.  MIME Media-type Registration for MUD files

   The following media-type is defined for transfer of MUD file:

o Type name: application
o Subtype name: mud+json
o Required parameters: n/a
o Optional parameters: n/a
o Encoding considerations: 8bit; application/mud+json values
  are represented as a JSON object; UTF-8 encoding SHOULD be
  employed.

I am tempted to say "MUST be UTF-8 encoded".

o Security considerations: See Security Considerations
  of this document.
o Interoperability considerations: n/a
o Published specification: this document

Nit: IANA Media Type registration templates need to have fully qualified
references. Use "[RFC]" instead of "this document" here, so that when the
RFC is published, the registration template can be posted to IANA website and
will have correct reference.

o Applications that use this media type: MUD controllers as
  specified by this document.

As above.

o Fragment identifier considerations: n/a
o Additional information:

Magic number(s): n/a
File extension(s): n/a
Macintosh file type code(s): n/a

o Person & email address to contact for further information:
  Eliot Lear , Ralph Droms 

I think Ralph's address is wrong in 2 places.

o Intended usage: COMMON
o Restrictions on usage: none
o Author:
 Eliot Lear 
 Ralph Droms 
o Change controller: IESG
o Provisional registration? (standards tree only): No.

UTF-8 needs to be a Normative reference (RFC 3629).


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

[OPSAWG] (Also Ben Campbell's and Alexey's) Re: Spencer Dawkins' Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Eliot Lear]

Responding to Spencer, Ben, and Alexy (in order).


On 16.04.18 21:09, Spencer Dawkins wrote:
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-opsawg-mud-20: Yes
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
>
>
>
> --
> COMMENT:
> --
>
> I'm a Yes who's watching Discussions with other ADs, but that's still a Yes.
> Thanks for doing this work.
>
> I do have some questions and comments.
>
> I don't think this requires any changes to the current document, but I note 
> that
>
> 3.15.  direction-initiated
>
>When applied this matches packets when the flow was initiated in the
>corresponding direction.  [RFC6092] specifies IPv6 guidance best
>practices.  While that document is scoped specifically to IPv6, its
>contents are applicable for IPv4 as well.  When this flag is set, and
>the system has no reason to believe a flow has been initiated it MUST
>drop the packet.  This node may be implemented in its simplest form
>by looking at naked SYN bits, but may also be implemented through
>more stateful mechanisms.
>
> it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2
> over QUIC, and I'm a bit suspicious of "may also be implemented through more
> stateful mechanisms" in 2018. Do the right thing, of course.

I proposed a clarification: direction initiated is a TCP element.
>
> Does
>
> 3.5.  is-supported
>
>This boolean is an indication from the manufacturer to the network
>administrator as to whether or not the Thing is supported.  In this
>context a Thing is said to not be supported if the manufacturer
>intends never to issue an update to the Thing or never update the MUD
>file.  A MUD controller MAY still periodically check for updates.
>
> ever mean anything except "is-updated"? 

Mostly that what it means, but the implication is that there's no
support, and enterprise administrators in particular might want to know
that (usually they do- because those devices represent a particular risk).

> "Supported" covers a lot of ground …
>
> If a manufacturer sells off one product line (so, flobbidy.example.com covered
> multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be
> maintained by a manufacturer that isn't flobbidy.example.com), is there a good
> plan for what comes next? I'm not sure what happens to is-supported, for
> instance.

The intent is that the entity providing the MUD file (probably the
manufacturer) will not be issuing software/firmware updates or MUD file
updates.  But your point is more about device lifecycle, and that's a
more interesting question than just "is-supported".  Steve Rich and
Thorsten Dahm have begun to delve in that direction.  There are at least
a few possibilities, such as the use of redirects, or even domain names
that are used for particular classes of devices, or even common repos. 
More work needed.

>
> I'm sensitive to Eliot's "walk before trying to run" comment on another ballot
> thread, but I'm thinking that
>
> 3.11.  model
>
>This string matches the entire MUD URL, thus covering the model that
>is unique within the context of the authority.  It may contain not
>only model information, but versioning information as well, and any
>other information that the manufacturer wishes to add.  The intended
>use is for devices of this precise class to match, to permit or deny
>communication between one another.
>
> might usefully result in a BCP about naming models, after the community has
> some experience with MUD. So, that's not intended to affect the current draft
> text, only the working group that produced it ;-)
>
> And, double ;-) ;-) but I wrote that before I saw this text in Section 14:
>
>   A caution about some of the classes: admission of a Thing into the
>"manufacturer" and "same-manufacturer" class may have impact on
>access of other Things.  Put another way, the admission may grow the
>access-list on switches connected to other Things, depending on how
>access is managed.  Some care should be given on managing that
>access-list growth.  Alternative methods such as additional network
>segmentation can be used to keep that growth within reason.
>
> So, when people know enough to describe best practices, I hope they do.
>

Thanks, Spencer.  We're just getting going.

Now to Ben:

> §1.6, 2nd paragraph: Why is the SHOULD not a MUST?

Because at this