Re: [OPSAWG] [Editorial Errata Reported] RFC8520 (5702)

[Ignas Bagdonas]

Verified.
Thank you.


On Wed, Apr 24, 2019 at 2:32 PM Joe Clarke (jclarke) 
wrote:

>
>
> > On Apr 21, 2019, at 20:53, RFC Errata System 
> wrote:
> >
> > The following errata report has been submitted for RFC8520,
> > "Manufacturer Usage Description Specification".
> >
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5702
> >
> > --
> > Type: Editorial
> > Reported by: Stuart Cheshire 
> >
> > Section: 16
> >
> > Original Text
> > -
> >   implementors should take into
> >   account what other information they are advertising through
> >   mechanisms such as Multicast DNS (mDNS) [RFC6872]
> >
> > Corrected Text
> > --
> >   implementors should take into
> >   account what other information they are advertising through
> >   mechanisms such as Multicast DNS (mDNS) [RFC6762]
>
> This seems dead on to me.  I didn’t think you meant somehow reference CLF
> for SIP.
>
> Joe
___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

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

[Ignas Bagdonas]

Could you provide any more details on what specifically is being 
patented? Given that the document does not define new protocol mechanics 
and only adds in codepoints and element encodings, what can be 
practically patented there?


Ignas



On 19/04/2018 10:14, li zhenqiang wrote:

Hello All,

We have updated the IPR Disclosures. The application number is given. 
At present the IPR that MAY relate to this draft is a patent 
application in China.


I have to say that we do the IPR Disclosures following the IETF IPR 
rules and procedures.  We think the disclosed patent application MAY 
relate to this draft, so we did the IPR disclosures. Whether or not it 
is really related to this draft depends on the lawyer's judgement.



Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*发件人：* Tianran Zhou 
*发送时间：* 2018-04-18 07:00
*收件人：* heasley ; li zhenqiang
;
draft-ietf-opsawg-ipfix-bgp-community.all
;
opsawg 
*主题：* RE: Rtgdir early review of
draft-ietf-opsawg-ipfix-bgp-community-06
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

[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] Genart early review of draft-ietf-opsawg-ipfix-bgp-community-04

[Ignas Bagdonas]

Dear authors of draft-ietf-opsawg-ipfix-bgp-community document,

This document is a WG document, and you have received community feedback 
on it stating that there are unclear aspects and questionable approaches 
described in it. Please address the comments to have the document cover 
the concerns raised.


The comments specifically on the operational aspects of how this 
proposed mechanism is expected to be used tend to repeat - this seems to 
be an area that is not clear to the community. Please focus on 
addressing it in substantial detail.


It would be beneficial to bring this document to the attention of the 
operations community too (as any other document - there is nothing 
specific to your document in this regard). Try to talk to Apricot, RIPE, 
NANOG, regional NOGs communities to sense the need and the details of 
this proposed mechanism, and then incorporate the feedback received 
there to the document.


Thank you.

Ignas



On 01/03/2018 15:39, li zhenqiang wrote:

Hi Joel,

Thank you for your prompt reply and sorry for the confusing words.

Let me try to explain it clearly in simple words again. BGP community 
attributes, such as standard community, extended community, large 
community, have already  been defined by IDR working group. Operaters 
use those already defined BGP communities in their field networks with 
their own plans to represent the groups of customers, peers, 
geographical and topological regions. For example, using standard 
community XXX to represent fixed line customers,  YYY for WLAN 
customers, and ZZZ for mobile customers, using community AAA for state 
L, BBB for state M, CCC for state N. Now we want to know the traffic 
generated by the WLAN customer in state N. So we need the community 
information related to the traffic flow exported by IPFIX. If IPFIX 
can export BGP community information using the IEs introduced in my 
doc, the  IPFIX collector, without running BGP protocol, can easily 
figure up the traffic in BGP community granularity, i.e. the traffic 
from different customers, from different states, from different 
customers in different states, and so on.


Best Regards,
Zhenqiang Li

li_zhenqi...@hotmail.com

*From:* Joel Halpern Direct 
*Date:* 2018-02-28 23:19
*To:* li zhenqiang ; Dongjie
(Jimmy) ; gen-...@ietf.org

*CC:* draft-ietf-opsawg-ipfix-bgp-community@ietf.org
;
opsawg 
*Subject:* Re: Genart early review of
draft-ietf-opsawg-ipfix-bgp-community-04
I am having trouble reconciling two of your comments.
In you rlast email you said that this is for "planed communities
represent the groups of customers peers an geographical and
topological
related information".  Planned communities is presumably a new
behavior,
not existing behavior.
In this email you say that these are "already defined BGP
communities".
You reference RFC 4384, which talks about several kinds of
communities.
maybe you intend the regional or national communities mentioned as
being
possible, but not defined, in that document.  This document's
descriptions do not align well enough with RFC 4384 for me to say.
Let's be clear.  The working group asked for an early review.  The WG
now has my review, indicating that this document is unclear in
multiple
regards and could use improvement.
It is now up to the WG and the chairs.
Yours,
Joel
On 2/28/18 6:22 AM, li zhenqiang wrote:
> Hi Joel,
>
> This is not for one operator, instead it is a common practice.
Please
> refer to RFC4384 and comments from Thomas who are from Swisscom.
>
> One clarification for this doc is it is not to introduce any new
BGP
> communities but to report the already defined BGP communities
related to
> a traffic flow through IPFIX, thus the IPFIX collector can
analyze the
> traffic in BGP community granularity without running BGP protocol.
>
> BGP community is a transitive attibute, thus the exporter can
report all
> the communities carried in the matching route entry, unless some
BGP
> communities are filtered by some routers.
>
> Sure I can add some text in the doc to say the proper processing
of the
> exporter, something like what I said in the previous mail, do
you think
> it is ok and enough?
>   When the exporter, i.e. router, receives the templete to report
> the communities, the exporter gets the information through BGP
lookup
> using the corresponding source or destination IP of a traffic flow.
>
> Thank you for your comments.
>
> Best Regards,
> Zhenqiang Li
>

Re: [OPSAWG] Request for document shepherd for draft-ietf-opsawg-ipfix-bgp-community

[Ignas Bagdonas]

A clarification addition - it is not a hard requirement for shepherd to 
be associated with an operator, it is a strong wish though as the 
document would benefit from being guided through the publication process 
by someone who would be a potential user of the proposed mechanism. In 
addition, any other review, especially by potential users of the 
proposed mechanism would be really appreciated.


Thank you Joe for raising this.

Ignas



On 15/11/2017 05:40, Joe Clarke wrote:

As Ignas mentioned in yesterday's meeting, we're looking for a document
shepherd for draft-ietf-opsawg-ipfix-bgp-community, specifically one who
is an operator.

If you are interested, please let the chairs know.  Thank you.

Joe

___
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

Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans

[Ignas Bagdonas]

Alan,


On 16/05/2017 13:36, Alan DeKok wrote:


I don't see how reviews (which were ignored) can be construed as "no 
evidence" that the authors were ignoring reviews.

   Which was my point.  If document authors issue new revs irrespective of what 
the WG suggests, the chairs should replace the authors with ones who work 
towards WG consensus.


No-one has seen the -07 revision yet, therefore it seems to be too early 
to make judgement whether comments and suggestions were or were not 
addressed. Authors have promised to address the raised comments 
discussing them on the list and responding to previous reviews.


I certainly agree with you that comments were not addressed. That is 
history now and reiterating this topic will do nothing to change what 
has already happened. Progress will happen if comments get addressed. 
Authors do have a token on this now.




   The alternative is to accept a draft as a WG document, and then to allow the 
authors to do pretty much whatever they want, and then to rubber-stamp the 
final document as an RFC.


That is not how the IETF works. I fail to see what else could be 
commented here.





   I just don't understand what point you were trying to make here.  The only 
subjects you addressed were ones I hadn't raised.



The point of my mail was on the changes to the list of authors. To 
summarize - changes to author list are not happening at this time. 
Important part to emphasize is "at this time".


Ignas


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

Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status and Plans

[Ignas Bagdonas]

Hi Alan,


On 13/05/2017 12:59, Alan DeKok wrote:
The approach in the IETF is to have authors move towards WG consensus. 
i.e. to prove to to the WG that the draft is ready for publication.

   If you're not going to work towards WG consensus, I suggest the chairs 
replace you with authors who will.



WG chairs can appoint or change authors if needed under the process 
described in RFC7221 and its referenced documents. The individual draft 
has been accepted as a WG one a while ago with no changes in author 
list. If current document authors would like to make any changes to 
author/co-author/editor list WG chairs will certainly approve those 
changes. Otherwise unless there is clear evidence that current authors 
cannot make progress with the document, WG chairs do not have intentions 
of changing the author list. This decision may be revisited if evidence 
of author/co-author/editor duties not being performed to the expected 
level surfaces, but at this time there is no such evidence. The process 
of progressing the document is slow, slower than it could have been, but 
it is not stalled.


Thank you.

Ignas



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

Re: [OPSAWG] Serious concerns with draft-ietf-opsawg-tacacs-06

[Ignas Bagdonas]

On 09/05/2017 20:10, Alan DeKok wrote:

On May 9, 2017, at 2:43 PM, Ignas Bagdonas <ibagdona.i...@gmail.com> wrote:,


Based on the information received from authors while tracking the progress of 
the draft, they intend to publish a revised version covering the comments 
received during the previous WGLC timeframe.

   I made no statements about my comments and their inclusion in the draft.

   But since you brought it up, I think the document is still nowhere near 
ready for publication.  Many comments have been addressed, but many have not 
been addressed.

   I question the utility of having a WGLC when the draft *still* doesn't 
adequately describe the protocol.


WGLC is for bringing the attention for finalizing the outstanding 
issues. If there are too many issues or they are too deep - that is 
fine, it is always possible to go back and do another WGLC later if needed.


The version that will go into WGLC is still not published therefore at 
this time it is just a speculation whether that particular version will 
or will not describe the protocol adequately. We need to wait for the 
authors to do their part and then it will be visible.




WG chairs are not for waving a stick at the WG in trying to tell what a 
document needs to do to progress.

   The draft must document the protocol.


While the WG document is formally owned by the WG, it is for the authors to do 
the actual text editing work and track and credit the changes in the text.

   I find it surprising that text was copied without attribution.  This just 
shouldn't happen.


That is correct. Authors are aware of this and it is under their 
decision and responsibility to resolve this.




Please initiate a discussion with authors, ideally on the list, on how your 
comments were or were not resolved.

   As the list archive shows, I've done that.  It also shows little in the way 
of responses.

   The last response to my review was "Many thanks Alan for the thorough review.  
We¹ll collate all your comments and respond shortly."

   That was six months ago, and there has been no further response.

   Given the extensive nature of my reviews, I would suggest it's not *my* 
responsibility to double-check each rev of the document to see if my comments 
are addressed.

   What I've seen in other WGs is that the authors respond to comments with 
clarifications, suggested replacement text, etc.  That pretty much hasn't 
happened here.


I agree with the facts and indeed the communication could have been 
better, and I understand the negative sentiments from your side. However 
it does not seem to be practical to try to escalate this in the rush at 
the timescale of days given that it already took half a year. Authors 
are aware of this discussion, it is their turn now to produce the new 
revision (which by the word of authors should be coming within a few 
weeks), and then if the new revision still does not address your 
concerns we would need to revisit this discussion again. Your reviews 
are definitely appreciated and valuable, it is the following up with 
them still has room for improvement.




Quite many of past instances of such discussions were happening before, and 
they eventually have moved the document forward. Continuing with that 
discussion would be the right approach to take.

   That's what I'm asking for.  That's not what's happening.

   Instead, new revs of the draft come out, with minimal interaction with the 
WG.


Looking further, there will be a new WG last call coming out after the revised 
version is posted. Usual WG LC discussion and commenting procedures will be 
followed.

   I would suggest that it's too early to have a WGLC, as the authors simply 
haven't responded to reviews of the draft.

   i.e. I have no idea what state the draft is in.  After doing multiple 
detailed reviews that largely get ignored, I'm not inclined to do more.  It's 
up to the authors to demonstrate that the comments have been addressed.


Authors have the next step to do at this time. Let's wait for the new 
revision first.



Ignas



   Alan DeKok.




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

Re: [OPSAWG] Serious concerns with draft-ietf-opsawg-tacacs-06

[Ignas Bagdonas]

Hi Alan,

Based on the information received from authors while tracking the 
progress of the draft, they intend to publish a revised version covering 
the comments received during the previous WGLC timeframe.


WG chairs are not for waving a stick at the WG in trying to tell what a 
document needs to do to progress. While the WG document is formally 
owned by the WG, it is for the authors to do the actual text editing 
work and track and credit the changes in the text. Please initiate a 
discussion with authors, ideally on the list, on how your comments were 
or were not resolved. Quite many of past instances of such discussions 
were happening before, and they eventually have moved the document 
forward. Continuing with that discussion would be the right approach to 
take.


Please also discuss the aspects of lack of credit for the text that you 
have proposed. Contributed changes need to be credited, on what level - 
that is for the document authors and editors to agree and decide.


Looking further, there will be a new WG last call coming out after the 
revised version is posted. Usual WG LC discussion and commenting 
procedures will be followed.


Thank you again for reviewing and improving the document.


Ignas



On 09/05/2017 18:41, Alan DeKok wrote:

   I've taken a look at the latest draft, and have some serious concerns.

   Specifically, large chunks of the Security Considerations sections appear to 
have been lifted from my post to the list:

https://mailarchive.ietf.org/arch/msg/opsawg/tU2wBFIV4MkpKChWn6EvrqeZtXU

   There are minor edits, but multiple sentences are copied word for word.  
Sentences which don't occur in the -05 draft, but do appear in my review, and 
subsequently are copied to the -06 draft with minor edits.

   Multiple paragraphs are copied with only minor edits.  The total amounts to 
about a page of text.

   While I appreciate that the document is improving, blatant copying of my 
text without attribution is entirely inappropriate.

   What are the chairs recommendations?

   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

[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

Re: [OPSAWG] WG adoption poll for draft-li-opsawg-ipfix-bgp-community-02

[Ignas Bagdonas]

Hi there,

[Copying GROW WG as this might be relevant to their coverage areas]

The document seems to be a good start but covers only standard 
communities. This is not sufficient given the universal deployment of 4 
octet ASNs. Both extended communities [RFC4360] and large communities 
[RFC8092] are needed and are used to address the signalling requirements 
for AS4 ASNs. Having separate documents each addressing only a specific 
type of community does not seem practical and rational. The document 
should include the definitions for IEs covering extended and large 
communities.


What is the logic of selecting multiple communities for export that a 
prefix may have been decorated with? Is it all of them all the time? The 
upper limit may be reaching 16000 standard communities per prefix - 
would that fit into resulting IPFIX IE? If there is a limit, how does it 
work? Is there any interpretation done on the values of the communities 
(all types, not just standard ones)? Those all are operational 
considerations aspects and should be covered in the document, appendix A 
likely could be a good place for it.


Security considerations on the privacy aspects would to be covered.

Ignas




On 13/02/2017 03:36, Tianran Zhou wrote:

Dear OPSAWG,

In Seoul, we got enough interest and positive response on this IPFIX IE 
extension draft.
By the authors' request, this email starts a formal poll. The chairs would like 
to know if the WG participants agree that the following document should be 
adopted as a WG document in OPSAWG.

Export BGP community information in IP Flow Information Export (IPFIX)
https://tools.ietf.org/html/draft-li-opsawg-ipfix-bgp-community-02

The adoption poll will take two weeks. Please let us know your opinion by Feb 
27. It would also be good to hear who is willing to review and/or implement or 
deploy the extension described in the document.

Since we already found that the majority of the f2f participants at our IETF97 
session like this idea, please do speak up now if you do not agree or have 
serious objections (with explanation of course).

Regards,
Tianran

___
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