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

[Adam Roach]

Adam Roach 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 would like to thank everyone who worked on this document, and the authors in
particular for clear, easy-to-read prose. The described mechanism seems quite 
useful.

---

§1.3:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

This document also uses lowercase forms of these words. Consider using the
boilerplate from RFC 8174.

---

§1.6:

>  Section 5.3.2) containing "application/mud+json", an "Accept-
>  Language" header ([RFC7231], Section 5.3.5), and a "User-Agent"
>  header ([RFC7231], Section 5.5.3).

s/header/header field/ (three times)

---

§1.7:

>  JSON is used as a serialization for compactness and readability,

Perhaps cite RFC 7159 here?

---

§3.5:

>  A MUD controller MAY still periodically check for updates.

I'm surprised to see this as a "MAY" rather than a "SHOULD." For example, even
an unsupported device may be the subject of a CERT security advisory, and the
manufacturer would presumably (if possible) take whatever mitigating steps would
make sense.

---

§8:

>"ietf-acldns:src-dnsname": "test.com",

The domain "test.com" is registered by an entity known as TESTCOM Inc. It's
probably best to avoid its use in an example. I would propose "test.example.org"
or something else reserved by RFC 6761.

(This applies to three other locations in the document as well)

---

§9:

>   reserved = 1*( CHAR ) ; from [RFC5234]

Is there a reason to restrict this to be only 7 bits?

---

§11:

>  The LLDP vendor specific frame has the following format:
>
>  +++--+-+--
>  |TLV Type|  len   |   OUI|subtype  | MUD URL
>  |  =127  ||= 00 00 5E|  = 1|
>  |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets)
>  +++--+-+--

Should this final field be a MUD URL? Or should it be the (extensible)
MUDstring defined in §9?

---

§12.2:

>  Prior to retrieving a MUD file the MUD controller SHOULD retrieve the
>  MUD signature file by retrieving the value of "mud-signature" and
>  validating the signature across the MUD file.

I'm really confused about how this works. My understanding so far is that the
Thing will provide a URL that points to the MUD file. Inside this MUD file is a
"mud-signature" that points to the signature discussed in this section. So, to
get to the MUD signature, the MUD controller has to first retrieve the MUD file.
But the text above says that it SHOULD retrieve the signature before it
retrieves the MUD file.

How?

---

§12.2:

I'm surprised to see no discussion in here of duration of signature validity. I
presume these will typically be cached by the MUD controller.

---

§16.4:

>   o Security considerations: See Security Considerations
> of this document.

Ideally, this would also cite RFC 7159, section 12.


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

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

[Alissa Cooper]

Alissa Cooper 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:
--

Thank you for addressing the Gen-ART review.


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

Re: [OPSAWG] draft-ietf-opsawg-tacacs-?? overview of significant changes over the last year

[Alan DeKok]

On Apr 18, 2018, at 2:49 PM, Andrej Ota  wrote:
> 
> TACACS+ draft had undergone a number of changes since revision -06 back in 
> the February 2017 and we, the "collective of authors" have been less than 
> satisfactory on keeping the WG updated. This is an attempt to start fixing 
> the problem by going through changes, enumerating them and explaining the 
> reason for each significant change.

  That's good.

> A year's worth of changes is a round number and -06 was also the version 
> where we misread Alan's intention and made the mistake of including his text 
> verbatim.

  The message I sent yesterday said *explicitly* that including the text 
verbatim was fine, so long as attribution was given.

  The message from Scott Bradner to the list last year also said this:

https://www.ietf.org/mail-archive/web/opsawg/current/msg04835.html

  The issue is *not* including the text verbatim.  The issue is the failure to 
acknowledge authorship.

  I fail to understand how this point has been misunderstood.

> I will skip the minor changes that deal with things like 
> 's/Connect/Connection/' or updates to author's contact details. I will also 
> be sending the overview over multiple e-mails, each dealing with a specific 
> section of the draft, so nobody will have to read through a single huge tome 
> if you only care or wonder about specific parts of the draft. I understand 
> this is far from ideal, but the damage had been done and this split into 
> smaller and more manageable chunks should go a long way towards getting 
> changes reviewed and understood, one by one.

  That's good.

> I do not wish to ignore the metaphorical elephant in the room. However, I 
> wish to split technical and organizational conversations into their separate 
> threads to avoid confusing the two. While I'll be describing changes in the 
> "technical" conversation, I and the rest of the authors will continue 
> listening and responding to Alan's organizational criticism, past and future, 
> in what we believe is the most constructive way: improving in the areas where 
> we were found wanting.

  The goal *is* to have a specification after all.

  I am, however, deeply concerned at the miscommunication.  The messages could 
not have been more clear for the past year, and they are *still* being 
misunderstood.

  Alan DeKok.

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

[OPSAWG] Mirja Kühlewind's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Mirja Kühlewind]

Mirja Kühlewind 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:
--

Minor comments:

1) "is-supported" confused me a bit at the beginning. Maybe "is-maintained"
could be a better name?

2) Why does the MUD file contain the MUD URL? Is this meant to be used as an
identifier?

3) Given this document talks quite often about possible future extensions, I'm
also wondering if this should be Experimental. However, I assume the
framework/architecture that is defined in this doc is not suppoed to change and
as such PS might be good as well.

4) I understand that the use of YANG is quite convinent for ACLs, however, I'm
wondering if it is still the right choice if the MUD File would be used to
describe more detailed behavior/traffic patterns. However, that should probably
not be changed now, but might be another reason to go for experimental.
Annother solution would be to further separate the architecture from the MUD
file format (maybe into different doc?) and include a versioning mechanism in
the MUD URL.


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

[OPSAWG] Mirja Kühlewind's Yes on draft-ietf-opsawg-mud-20: (with COMMENT)

[Mirja Kühlewind]

Mirja Kühlewind 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:
--

Minor comments:

1) "is-supported" confused me a bit at the beginning. Maybe "is-maintained" 
could be a better name?

2) Why does the MUD file contain the MUD URL? Is this meant to be used as an 
identifier?


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

[OPSAWG] R: Notification of the new draft of "Coordinated Address Space Management architecture"

[Fioccola Giuseppe]

Hi Chongfeng,
I have read this draft.
I think the architectural concepts and components that are introduced here 
allows a good coordination for the address space management.
I would suggest to add an Use Cases section where it is possible to specify 
better how CASM system integrates with a Network Operator SDN architecture for 
the control and supervision of the network and the services.

Best Regards,

Giuseppe

Da: OPSAWG [mailto:opsawg-boun...@ietf.org] Per conto di 
xiechf@chinatelecom.cn
Inviato: martedì 6 marzo 2018 03:24
A: opsawg
Oggetto: [OPSAWG] Notification of the new draft of "Coordinated Address Space 
Management architecture"


Dear all,

We have subumitted a new draft as below,


 
https://datatracker.ietf.org/doc/draft-li-opsawg-address-pool-management-arch/

If you have comments or suggestions, pls feel free to send them.

Thank you for your attention!


Chongfeng Xie


xiechf@chinatelecom.cn

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie.

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.
___
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

[Tianran Zhou]

Hi the Authors,

I remember you posted a list of Alan's comments in the mailing list, and 
mentioned what have been addressed and how, what will be addressed later. 
I think it's a good start. Why not continue doing this for your new revision.
It would be very helpful.

Tianran

> -Original Message-
> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Alan DeKok
> Sent: Tuesday, April 17, 2018 11:07 PM
> To: Douglas Gash (dcmgash) 
> Cc: opsawg@ietf.org; Andrej Ota ; Thorsten Dahm
> 
> Subject: Re: [OPSAWG] New Version Notification for
> draft-ietf-opsawg-tacacs-10.txt
> 
> 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

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