date:20180926

[netmod] Adam Roach's No Objection on draft-ietf-netmod-acl-model-19: (with COMMENT)

2018-09-26 Thread Adam Roach

Adam Roach has entered the following ballot position for
draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/



--
COMMENT:
--

Thanks to everyone who contributed their time and knowledge to this document. I
have two minor comments.

Throughout the data module, the terms "ace" and "ACE" are used interchangeably.
It would probably be good to rationalize these (I would suggest "ACE").

---

§4.3 and 4.4:

These examples use IPv4 addresses exclusively. Please update to use IPv6 or a
mix of IPv4 and IPv6. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/
for additional information.


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

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

2018-09-26 Thread Suresh Krishnan

Hi Mahesh,
  Thanks for your quick reply. Please find comments inline.

> On Sep 27, 2018, at 12:57 AM, Mahesh Jethanandani  
> wrote:
> 
> Hi Suresh,
> 
>> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan  wrote:
>> 
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/
>> 
>> 
>> 
>> --
>> DISCUSS:
>> --
>> 
>> This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the
>> ICMP types and codes are different for ICMP and ICMPv6 I think this model
>> should be included to cover ICMPv6.
> 
> I understand that there are many protocols that fall into such a criteria. As 
> has already been discussed, we are offering the minimum set of protocols for 
> which there is a demand, while giving the option to extend it through 
> augmentations of the base model.

I understand where you are coming from but ICMPv6 is not just another protocol. 
It is a core protocol in the IPv6 protocol suite. Do you know of any systems 
that support IPv6 acls but not support ICMPv6 there?

> 
> Let us not boil the ocean. As it is, this draft has been in the works for 
> more than 4 years.

This is a very clear and bounded request (i.e. not boiling the ocean). I do not 
think this will be significant amount of work. If you do feel otherwise, I will 
be glad to revisit my position

Regards
Suresh
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

2018-09-26 Thread Mahesh Jethanandani

Hi Suresh,

> On Sep 26, 2018, at 9:36 PM, Suresh Krishnan  wrote:
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the
> ICMP types and codes are different for ICMP and ICMPv6 I think this model
> should be included to cover ICMPv6.

I understand that there are many protocols that fall into such a criteria. As 
has already been discussed, we are offering the minimum set of protocols for 
which there is a demand, while giving the option to extend it through 
augmentations of the base model.

Let us not boil the ocean. As it is, this draft has been in the works for more 
than 4 years.

> 
> 
> 
> 

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

[netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

2018-09-26 Thread Suresh Krishnan

Suresh Krishnan has entered the following ballot position for
draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/



--
DISCUSS:
--

This document is missing ACL handling for ICMPv6 (RFC4443) completely. As the
ICMP types and codes are different for ICMP and ICMPv6 I think this model
should be included to cover ICMPv6.




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

Re: [netmod] Warren Kumari's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Warren Kumari

On Wed, Sep 26, 2018 at 6:32 PM Mahesh Jethanandani 
wrote:

>
>
> > On Sep 26, 2018, at 1:49 PM, Warren Kumari  wrote:
> >
> > Warren Kumari has entered the following ballot position for
> > draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/
> >
> >
> >
> > --
> > DISCUSS:
> > --
> >
> > Be ye not afraid -- this DISCUSS is easily cleared, but sufficiently
> important
> > that I thought it worth making, and making sure it didn't slip through
> the
> > cracks.
> >
> > The description for match-on-ipv4 says: "The device can support matching
> on
> > IPv4 headers.", but the description for 'match-on-tcp', 'match-on-udp',
> > 'match-on-icmp' say: "The device can support  headers." I
> really
> > think that these need to be "The device can support matching on
> 
> > headers.”
>
> Ok.
>
>

Discuss cleared.



> >
> >
> > --
> > COMMENT:
> > --
> >
> > Section 1:
> > "In case a vendor supports it, metadata matches apply to fields
> associated with
> > the packet but not in the packet header such as input interface or
> overall
> > packet length". I don't have a suggested replacement, but seeing as this
> is
> > introductory text, I figured it was aimed at people not familiar with how
> > forwarding / filtering works. I'm slightly concerned that some people
> will get
> > confused, because almost all protocols include a "packet length" in the
> header.
> > Perhaps just dropping the "or overall packet length"? (Yes, we could get
> into
> > a long thing on protocol packet length, and overall length, etc, but
> that's
> > likely to not be helpful in the document).
>
> I am not sure what the concern is. The "overall packet length" being
> referred to is not the “packet length” in the header field. It is the
> length of the packet as received over the wire. Is that the clarification
> you were looking for in the document?
>

Yup, perfect.

People often seem to forget this -- the surrounding text is all
introductory, and so I was concerned that the audience would see that, and
think: "But the packet length is in the header", and miss the distinction
that L3 packet length != L2 packet lenght, etc.


>
> >
> > Section 2:
> > Nit: "It is very important that model can be used easily by
> > applications/attachments." models.
>
> Ok.
>
> >
> > Section 3:
> > "Packet header matching applies to fields visible in the packet such as
> address
> > or CoS or port numbers." CoS isn't expanded, and isn't in the well known
> > acronyms list. RFC2474 perhaps?
>
> It is in Section 1 and 1.1.
>

Doh! Sorry.



>
> >
> > Section 3:
> > "These include features such as "Device can support ethernet headers" or
> > "Device can support of IPv4 headers". "can support of" makes no sense.
> Also, I
> > *think* Ethernet is uppercase. This is a nit.
>
> Will
> s/support/match on/
>
>
Win!

Thank you for accepting the suggestions in the spirit they were offered.
W



> Thanks.
>
> >
> >
>
> Mahesh Jethanandani
> mjethanand...@gmail.com
>
>
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Mahesh Jethanandani

Hi Alissa,

> On Sep 26, 2018, at 2:26 PM, Alissa Cooper  wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> We previously had a work item we were tracking with the IEEE leadership around
> the IEEE writing a YANG module for ethertypes. I just wanted to check that the
> IEEE is aware that this document is defining a placeholder module for
> ethertypes until such time that they define one.

They were told as much in the joint IETF-IEEE meeting.

> 
> 
> --
> COMMENT:
> --
> 
> Sec 1:
> 
> s/Policy Based Routing, Firewalls etc./policy-based routing, firewalls, etc./

Isn’t Policy Based Routing (PBR) and particular form of routing, with its own 
acronym and all? I can make the F in Firewalls, lowercase.

> 
> "The matching of filters and actions in an ACE/ACL are triggered only
>   after application/attachment of the ACL to an interface, VRF, vty/tty
>   session, QoS policy, routing protocols amongst various other config
>   attachment points.”

> 
> This is a sentence fragment.

How about this:

OLD:
   The matching of filters and actions in an ACE/ACL are triggered only
   after application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, routing protocols amongst various other config
   attachment points.

NEW:
   The matching of filters and actions in an ACE/ACL are triggered only
   after the application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, or routing protocols amongst various other config
   attachment points.

> 
> s/in the ACE's/in the ACEs/

Ok.

> 
> Sec 3.1:
> 
> "There are two YANG modules in the model."
> 
> Is this technically correct, given that ietf-ethertypes is also defined here?
> 
> Also, I don't think the definition of ietf-ethertypes belongs in an appendix
> under the heading "Extending ACL model examples." I can imagine that other
> modules will want to import this module and that seems like a strange place to
> put it.

That is what we could agree with IEEE on.

> 
> Sec 4.1:
> 
> For avoidance of confusion, I would suggest replacing "l2," "l3," and "l4" 
> with
> "layer2," "layer3," and "layer4," respectively.

I would object to making these changes in the model, particularly since the 
description already defines what they are.

> 
> s/Definitions of action for this ace entry/Definitions of action for this ACE
> entry/

It is referring to the node ‘ace’ defined in the module.

> 
> s/Specifies the forwarding action per ace entry/Specifies the forwarding 
> action
> per ACE entry/

Same as above.

> 
> Sec 4.2:
> 
> "This module imports definitions from Common YANG Data Types [RFC6991]
>   and references IP [RFC0791], ICMP [RFC0792], Definition of the
>   Differentiated Services Field in the IPv4 and IPv6 Headers [RFC2474],
>   The Addition of Explicit Congestion Notification (ECN) to IP
>   [RFC3168], , IPv6 Scoped Address Architecture [RFC4007], IPv6
>   Addressing Architecture [RFC4291], A Recommendation for IPv6 Address
>   Text Representation [RFC5952], IPv6 [RFC8200]."
> 
> It looks like something is missing from this list, possibly RFC 793.

Ok.

> 
> Sec 5:
> 
> In this section or elsewhere it would be nice to see a sentence noting that
> this YANG model allows the configuration of packet logging, which if used 
> would
> additionally warrant protections against unauthorized log access and a logs
> retention policy.

How about this addition to the section under list of subtrees and data nodes 
that are sensitive and vulnerable:

  /acls/acl/aces/ace/actions/logging: This node specifies ability to log
  packets that match this ace entry.  Unauthorized write access to this
  node can allow intruders to enable logging on one or many ace entries, 
  overwhelming the server in the process. Unauthorized read access of this 
node 
  can allow intruders to access logging information, which could be used to
  attack the server.

Thanks.

Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Benjamin Kaduk

It looks like I was thinking of the review of draft-ietf-opsawg-nat-yang,
not this one -- sorry for the mixup!  (And thanks for spotting the issue!)

-Benjamin

On Wed, Sep 26, 2018 at 02:39:23PM -0700, Alissa Cooper wrote:
> This is in the -19:
> 
> /*
> * Logging actions for a packet
> */
>identity log-action {
>  description
>"Base identity for defining the destination for logging actions";
>}
> 
>identity log-syslog {
>  base log-action;
>  description
>"System log (syslog) the information for the packet";
>}
> 
>identity log-none {
>  base log-action;
>  description
>"No logging for the packet";
>}
> Is there a more recent version?
> 
> Thanks,
> Alissa
> 
> > On Sep 26, 2018, at 2:25 PM, Benjamin Kaduk  wrote:
> > 
> > Just on the logging point...
> > 
> > On Wed, Sep 26, 2018 at 02:20:49PM -0700, Alissa Cooper wrote:
> >> 
> >> Sec 5:
> >> 
> >> In this section or elsewhere it would be nice to see a sentence noting that
> >> this YANG model allows the configuration of packet logging, which if used 
> >> would
> >> additionally warrant protections against unauthorized log access and a logs
> >> retention policy.
> > 
> > My understanding is that this was removed entirely from the document in
> > response to the secdir review.  Could you double-check which version you
> > were looking at, or if the current version still is problematic?
> > 
> > Thanks,
> > 
> > Benjamin
> 

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

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Alissa Cooper

This is in the -19:

/*
* Logging actions for a packet
*/
   identity log-action {
 description
   "Base identity for defining the destination for logging actions";
   }

   identity log-syslog {
 base log-action;
 description
   "System log (syslog) the information for the packet";
   }

   identity log-none {
 base log-action;
 description
   "No logging for the packet";
   }
Is there a more recent version?

Thanks,
Alissa

> On Sep 26, 2018, at 2:25 PM, Benjamin Kaduk  wrote:
> 
> Just on the logging point...
> 
> On Wed, Sep 26, 2018 at 02:20:49PM -0700, Alissa Cooper wrote:
>> 
>> Sec 5:
>> 
>> In this section or elsewhere it would be nice to see a sentence noting that
>> this YANG model allows the configuration of packet logging, which if used 
>> would
>> additionally warrant protections against unauthorized log access and a logs
>> retention policy.
> 
> My understanding is that this was removed entirely from the document in
> response to the secdir review.  Could you double-check which version you
> were looking at, or if the current version still is problematic?
> 
> Thanks,
> 
> Benjamin

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

Re: [netmod] IPR call draft-ietf-netmod-module-tags-02

2018-09-26 Thread Dean Bogdanovic




> On Sep 27, 2018, at 12:26 AM, joel jaeggli  wrote:
> 
> Authors, Contributors, WG,
> 
> Regarding the document
> draft-ietf-netmod-module-tags-02
> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
> Are you aware of any IPR that applies to draft identified above?
> 

No, I'm not aware of any IPR that applies to this draft

Dean

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

[netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Alissa Cooper

Alissa Cooper has entered the following ballot position for
draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/



--
DISCUSS:
--

We previously had a work item we were tracking with the IEEE leadership around
the IEEE writing a YANG module for ethertypes. I just wanted to check that the
IEEE is aware that this document is defining a placeholder module for
ethertypes until such time that they define one.


--
COMMENT:
--

Sec 1:

s/Policy Based Routing, Firewalls etc./policy-based routing, firewalls, etc./

"The matching of filters and actions in an ACE/ACL are triggered only
   after application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, routing protocols amongst various other config
   attachment points."

This is a sentence fragment.

s/in the ACE's/in the ACEs/

Sec 3.1:

"There are two YANG modules in the model."

Is this technically correct, given that ietf-ethertypes is also defined here?

Also, I don't think the definition of ietf-ethertypes belongs in an appendix
under the heading "Extending ACL model examples." I can imagine that other
modules will want to import this module and that seems like a strange place to
put it.

Sec 4.1:

For avoidance of confusion, I would suggest replacing "l2," "l3," and "l4" with
"layer2," "layer3," and "layer4," respectively.

s/Definitions of action for this ace entry/Definitions of action for this ACE
entry/

s/Specifies the forwarding action per ace entry/Specifies the forwarding action
per ACE entry/

Sec 4.2:

"This module imports definitions from Common YANG Data Types [RFC6991]
   and references IP [RFC0791], ICMP [RFC0792], Definition of the
   Differentiated Services Field in the IPv4 and IPv6 Headers [RFC2474],
   The Addition of Explicit Congestion Notification (ECN) to IP
   [RFC3168], , IPv6 Scoped Address Architecture [RFC4007], IPv6
   Addressing Architecture [RFC4291], A Recommendation for IPv6 Address
   Text Representation [RFC5952], IPv6 [RFC8200]."

It looks like something is missing from this list, possibly RFC 793.

Sec 5:

In this section or elsewhere it would be nice to see a sentence noting that
this YANG model allows the configuration of packet logging, which if used would
additionally warrant protections against unauthorized log access and a logs
retention policy.


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

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Benjamin Kaduk

Just on the logging point...

On Wed, Sep 26, 2018 at 02:20:49PM -0700, Alissa Cooper wrote:
> 
> Sec 5:
> 
> In this section or elsewhere it would be nice to see a sentence noting that
> this YANG model allows the configuration of packet logging, which if used 
> would
> additionally warrant protections against unauthorized log access and a logs
> retention policy.

My understanding is that this was removed entirely from the document in
response to the secdir review.  Could you double-check which version you
were looking at, or if the current version still is problematic?

Thanks,

Benjamin

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

[netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Alissa Cooper

Alissa Cooper has entered the following ballot position for
draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/



--
DISCUSS:
--

We previously had a work item we were tracking with the IEEE leadership around
the IEEE writing a YANG module for ethertypes. I just wanted to check that the
IEEE is aware that this document is defining a placeholder module for
ethertypes until such time that they define one.


--
COMMENT:
--

Sec 1:

s/Policy Based Routing, Firewalls etc./policy-based routing, firewalls, etc./

"The matching of filters and actions in an ACE/ACL are triggered only
   after application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, routing protocols amongst various other config
   attachment points."

This is a sentence fragment.

s/in the ACE's/in the ACEs/

Sec 3.1:

"There are two YANG modules in the model."

Is this technically correct, given that ietf-ethertypes is also defined here?

Also, I don't think the definition of ietf-ethertypes belongs in an appendix
under the heading "Extending ACL model examples." I can imagine that other
modules will want to import this module and that seems like a strange place to
put it.

Sec 4.1:

For avoidance of confusion, I would suggest replacing "l2," "l3," and "l4" with
"layer2," "layer3," and "layer4," respectively.

s/Definitions of action for this ace entry/Definitions of action for this ACE
entry/

s/Specifies the forwarding action per ace entry/Specifies the forwarding action
per ACE entry/

Sec 4.2:

"This module imports definitions from Common YANG Data Types [RFC6991]
   and references IP [RFC0791], ICMP [RFC0792], Definition of the
   Differentiated Services Field in the IPv4 and IPv6 Headers [RFC2474],
   The Addition of Explicit Congestion Notification (ECN) to IP
   [RFC3168], , IPv6 Scoped Address Architecture [RFC4007], IPv6
   Addressing Architecture [RFC4291], A Recommendation for IPv6 Address
   Text Representation [RFC5952], IPv6 [RFC8200]."

It looks like something is missing from this list, possibly RFC 793.

Sec 5:

In this section or elsewhere it would be nice to see a sentence noting that
this YANG model allows the configuration of packet logging, which if used would
additionally warrant protections against unauthorized log access and a logs
retention policy.


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

[netmod] Warren Kumari's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Warren Kumari

Warren Kumari has entered the following ballot position for
draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/



--
DISCUSS:
--

Be ye not afraid -- this DISCUSS is easily cleared, but sufficiently important
that I thought it worth making, and making sure it didn't slip through the
cracks.

The description for match-on-ipv4 says: "The device can support matching on
IPv4 headers.", but the description for 'match-on-tcp', 'match-on-udp',
'match-on-icmp' say: "The device can support  headers." I really
think that these need to be "The device can support matching on 
headers."


--
COMMENT:
--

Section 1:
"In case a vendor supports it, metadata matches apply to fields associated with
the packet but not in the packet header such as input interface or overall
packet length". I don't have a suggested replacement, but seeing as this is
introductory text, I figured it was aimed at people not familiar with how
forwarding / filtering works. I'm slightly concerned that some people will get
confused, because almost all protocols include a "packet length" in the header.
 Perhaps just dropping the "or overall packet length"? (Yes, we could get into
a long thing on protocol packet length, and overall length, etc, but that's
likely to not be helpful in the document).

Section 2:
Nit: "It is very important that model can be used easily by
applications/attachments." models.

Section 3:
"Packet header matching applies to fields visible in the packet such as address
or CoS or port numbers." CoS isn't expanded, and isn't in the well known
acronyms list. RFC2474 perhaps?

Section 3:
"These include features such as "Device can support ethernet headers" or
"Device can support of IPv4 headers". "can support of" makes no sense. Also, I
*think* Ethernet is uppercase. This is a nit.


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

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

2018-09-26 Thread Martin Bjorklund

Hi,

Kent Watsen  wrote:
> Hi Tom,
> 
> 
> >> Good enough?
> >
> > No:-)  The authors of YANG modules seem not to understand that it
> > applies to them, or incorrectly use the tools that would apply 
> > were they correctly used.  
> 
> This seems to be a problem outside the scope of this draft.  I was 
> thinking to strengthen Section 4.2 some, but this sentence really
> seems to say it right:
> 
>As such, it is RECOMMENDED that authors do as much as possible
>within the selected format to avoid long lines.

I think you also should change the first paragraph in section 3.1:

   Automated folding of long lines is needed in order to support draft
   compilations that entail a) validation of source input files (e.g.,
   YANG, XML, JSON, ABNF, ASN.1) and/or b) dynamic generation of output
   (e.g., tree diagrams) that are stitched into the final document to be
   submitted.

At least remove YANG from the example, and I also think that
auto-folding of tree diagrams should be strongly discouraged, so find
a better example for (b).

Also remove YANG from 4.1

To further emphasize this, I think you should add YANG and tree
diagrams as examples in section 4.2.


/martin

> 
> 
> > OLD
> > [RFC7994][RFC7994]sets out the requirements for plain-text RFCs and
> >   states that each line of an RFC (and hence of an Internet-Draft) must
> >   be limited to 72 characters followed by the character sequence that
> >   denotes an end-of-line (EOL).
> >
> > NEW
> > [RFC7994]sets out the requirements for plain-text RFCs and
> >   states that each line of an RFC (and hence of an Internet-Draft) must
> >   be limited to 72 characters followed by the character sequence that
> >   denotes an end-of-line (EOL).  This applies to all of an RFC,
> >   including, for example, the comments or description clauses in a YANG
> >   module, and to artwork.
> 
> First, I'd recommend simplifying the last sentence to just "This applies
> to all of an RFC, including any artwork.", but then it seems to step on
> what the next paragraph says.  Perhaps the next paragraph could be 
> simplified? - suggestions welcomed.
> 
> 
> > Not sure why you have [RFC7994] twice.
> 
> Fixed in my local copy.
> 
> 
> PS: folded YANG-modules will break tooling (e.g., module validation) until
> extraction tools (i.e., `xym`) are updated to be folding aware.  Even after
> this draft becomes an RFC, authors need to ensure that YANG modules are not
> folded until such tools are updated.  Other artwork (tree diagrams, instance
> examples, etc.) being folded is not a problem, as no automated tooling acts
> on them currently.
> 
> 
> Kent // contributor
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 

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

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

2018-09-26 Thread Kent Watsen

Hi Tom,


>> Good enough?
>
> No:-)  The authors of YANG modules seem not to understand that it
> applies to them, or incorrectly use the tools that would apply 
> were they correctly used.  

This seems to be a problem outside the scope of this draft.  I was 
thinking to strengthen Section 4.2 some, but this sentence really
seems to say it right:

   As such, it is RECOMMENDED that authors do as much as possible
   within the selected format to avoid long lines.



> OLD
> [RFC7994][RFC7994]sets out the requirements for plain-text RFCs and
>   states that each line of an RFC (and hence of an Internet-Draft) must
>   be limited to 72 characters followed by the character sequence that
>   denotes an end-of-line (EOL).
>
> NEW
> [RFC7994]sets out the requirements for plain-text RFCs and
>   states that each line of an RFC (and hence of an Internet-Draft) must
>   be limited to 72 characters followed by the character sequence that
>   denotes an end-of-line (EOL).  This applies to all of an RFC,
>   including, for example, the comments or description clauses in a YANG
>   module, and to artwork.

First, I'd recommend simplifying the last sentence to just "This applies
to all of an RFC, including any artwork.", but then it seems to step on
what the next paragraph says.  Perhaps the next paragraph could be 
simplified? - suggestions welcomed.


> Not sure why you have [RFC7994] twice.

Fixed in my local copy.


PS: folded YANG-modules will break tooling (e.g., module validation) until
extraction tools (i.e., `xym`) are updated to be folding aware.  Even after
this draft becomes an RFC, authors need to ensure that YANG modules are not
folded until such tools are updated.  Other artwork (tree diagrams, instance
examples, etc.) being folded is not a problem, as no automated tooling acts
on them currently.


Kent // contributor


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

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Juergen Schoenwaelder

On Wed, Sep 26, 2018 at 07:21:49PM +, Kent Watsen wrote:
> 
> 
> > This is not an improvement. Just more complexity and noise.
> 
> Disagree.  The RFC should not mandate the tool exits, that would be
> overreaching.  How about this simpler language?
> 
> NEW:
> 
>Scan the artwork for horizontal tab characters.  If any horizontal
>tab characters appear, either resolve them to space characters or
>exit, forcing the input provider to convert them first.

Sounds good.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Kent Watsen




> This is not an improvement. Just more complexity and noise.

Disagree.  The RFC should not mandate the tool exits, that would be
overreaching.  How about this simpler language?

NEW:

   Scan the artwork for horizontal tab characters.  If any horizontal
   tab characters appear, either resolve them to space characters or
   exit, forcing the input provider to convert them first.

Kent // co-author



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

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Mahesh Jethanandani

Hi Benjamin,

> On Sep 26, 2018, at 10:31 AM, Benjamin Kaduk  wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> I think this is good work to have, overall, and the document pretty easy to 
> read.
> That said, I think the Security Considerations need to be expanded a bit more 
> before
> this document get published:
> 
>  Write operations (e.g., )
>   to these data nodes without proper protection can have a negative
>   effect on network operations.
> 
> I think the effects can be on more than just *network* operations, there
> can be negative effects for end systems that (e.g.) experience DoS attacks
> that would otherwise have been blocked, receive maliciously crafted packets
> that trigger application bugs, are used as part of (e.g.) UDP amplification
> attacks, etc.

How about this?

OLD:
   Write operations (e.g., )
   to these data nodes without proper protection can have a negative
   effect on network operations.

NEW:
   Write operations (e.g., )
   to these data nodes without proper protection can have a negative
   effect on network operations and end systems. The end systems, for
   example, can experience DoS attacks that would otherwise have been blocked,
   and receive maliciously crafted packets that trigger applications bugs.

> 
>  /acls/acl/aces: This list specifies all the configured access
>  control entries on the device.  Unauthorized write access to this
>  list can allow intruders to access and control the system.
>  Unauthorized read access to this list can allow intruders to spoof
>  packets with authorized addresses thereby compromising the system.

Back in July we went through this section, and here was the change that was 
proposed, that Steve had accepted. Since they were provided for the current 
version of the draft (-19), they were not applied till we had received all the 
reviews. Were you looking for changes in addition to this?

OLD:
  /acls/acl/aces: This list specifies all the configured access
  control entries on the device.  Unauthorized write access to this
  list can allow intruders to access and control the system.
  Unauthorized read access to this list can allow intruders to spoof
  packets with authorized addresses thereby compromising the system.

NEW:
  /acls/acl/aces: This list specifies all the configured access
  control entries on the device.  Unauthorized write access to this
  list can allow intruders to modify the entries so as to permit traffic
  that should not be permitted, or deny traffic that should be permitted.
  The former may result in a DoS attack, or compromise the device.
  The latter may result in a DoS attack. The impact of an unauthorized 
  read access to the list will allow the attacker to determine which rules
  are in effect, to better craft an attack.

> 
> I agree with the secdir reviewer that "the system" needs to be clarified,
> and that the consequences of unauthorized write and read access need to be
> more clearly described.
> His proposed text is much better than the present text, though there are
> other ways to convey the needed information.
> 
> 
> --
> COMMENT:
> --
> 
> I tried to call out the editorial nits as such; there are a couple 
> non-editorial
> comments embedded within.
> 
> Section 1
> 
>   The match criteria allows for definition of packet headers and
>   metadata, all of which must be true for the match to occur.
> 
> nit: Is this missing a word like "contents”?

I am not sure if we are, possibly because I do not understand what you mean by 
“contents”.  ACL rules are written to match against packet headers and 
metadata. They are not written to match against the “contents” of the packet.

> 
>   The matching of filters and actions in an ACE/ACL are triggered only
>   after application/attachment of the ACL to an interface, VRF, vty/tty
>   session, QoS policy, routing protocols amongst various other config
>   attachment points.
> 
> nit: I think the end of this list needs some clarification/termination,
> like "and routing protocols, amongst”

Ok. Will add the

Re: [netmod] IPR call draft-ietf-netmod-module-tags-02

2018-09-26 Thread Christian Hopps




joel jaeggli  writes:


Authors, Contributors, WG,

Regarding the document
draft-ietf-netmod-module-tags-02
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02



Are you aware of any IPR that applies to draft identified above?


No, I'm not aware of any IPR that applies to this draft

Thanks,
Chris.

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

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Juergen Schoenwaelder

On Wed, Sep 26, 2018 at 05:38:22PM +, Kent Watsen wrote:
> 
> The only change we're envisioning is to the following paragraph from
> Section 6.1 (Automated Folding):
> 
> OLD:
> 
>Scan the artwork to ensure the horizontal tab character does not
>appear.  If any horizontal tab character appears, exit (this artwork
>cannot be folded).
> 
> NEW:
> 
>Scan the artwork to ensure the horizontal tab character does not
>appear.  If any horizontal tab character appears, either 1) do
>something to support tabs in the folded output (out of scope to
>this draft), 2) do something to convert the horizontal tabs in
>the input to space characters in the folded output, or 3) exit,
>forcing the input provider to convert the horizontal tabs to
>space characters first.
> 
> Note: the "do something" phraseology seems too informal, would welcome
> suggestions for tightening it up.
>

This is not an improvement. Just more complexity and noise.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Kent Watsen





> Given that 2) has a)-c), I do not understand what the recommendation
> actually is. The recommendation is hopefully 2a) and we are done.



For the script that we include in the Appendix, the authors wish to
keep the current "2a" behavior and have no plans to change that.

The only change we're envisioning is to the following paragraph from
Section 6.1 (Automated Folding):

OLD:

   Scan the artwork to ensure the horizontal tab character does not
   appear.  If any horizontal tab character appears, exit (this artwork
   cannot be folded).

NEW:

   Scan the artwork to ensure the horizontal tab character does not
   appear.  If any horizontal tab character appears, either 1) do
   something to support tabs in the folded output (out of scope to
   this draft), 2) do something to convert the horizontal tabs in
   the input to space characters in the folded output, or 3) exit,
   forcing the input provider to convert the horizontal tabs to
   space characters first.

Note: the "do something" phraseology seems too informal, would welcome
suggestions for tightening it up.


Kent // co-author


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

[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

2018-09-26 Thread Benjamin Kaduk

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-acl-model-19: 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-netmod-acl-model/



--
DISCUSS:
--

I think this is good work to have, overall, and the document pretty easy to 
read.
That said, I think the Security Considerations need to be expanded a bit more 
before
this document get published:

  Write operations (e.g., )
   to these data nodes without proper protection can have a negative
   effect on network operations.

I think the effects can be on more than just *network* operations, there
can be negative effects for end systems that (e.g.) experience DoS attacks
that would otherwise have been blocked, receive maliciously crafted packets
that trigger application bugs, are used as part of (e.g.) UDP amplification
attacks, etc.

  /acls/acl/aces: This list specifies all the configured access
  control entries on the device.  Unauthorized write access to this
  list can allow intruders to access and control the system.
  Unauthorized read access to this list can allow intruders to spoof
  packets with authorized addresses thereby compromising the system.

I agree with the secdir reviewer that "the system" needs to be clarified,
and that the consequences of unauthorized write and read access need to be
more clearly described.
His proposed text is much better than the present text, though there are
other ways to convey the needed information.


--
COMMENT:
--

I tried to call out the editorial nits as such; there are a couple non-editorial
comments embedded within.

Section 1

   The match criteria allows for definition of packet headers and
   metadata, all of which must be true for the match to occur.

nit: Is this missing a word like "contents"?

   The matching of filters and actions in an ACE/ACL are triggered only
   after application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, routing protocols amongst various other config
   attachment points.

nit: I think the end of this list needs some clarification/termination,
like "and routing protocols, amongst"

Section 3

  The
   match criteria allows for definition of packet headers or metadata,
   if supported by the vendor.  [...]

(same nit as above re "contents")

   Metadata matching applies to fields associated with the packet, but
   not in the packet header such as input interface, packet length, or
   source or destination prefix length.  The actions can be any sort of

nit: comma after "not in the packet header"

Section 4.1

nit: The feature match-on-udp and -icmp descriptions should probably use
the plural "headers" to match the other features' descriptions.

The mixed- features seem to implicitly assume that if features X and
Y are individually supported, then the combination is also supported.  I
could imagine that there might exist hardware for which that assumption is
not true, but don't know if there actually is any such hardware or it's
common enough to be worth caring about here.

   grouping acl-counters {
 leaf matched-packets {
  [...]
  An implementation should provide this counter on a
  per-interface per-ACL-entry if possible.

nit: missing "basis"?  (Also in subsequent instances.)

Section A.1

It's unclear that using a...@newco.com (in particular, the @newco.com part)
in an example is reasonable; @newco.example would be better.


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

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

2018-09-26 Thread Andy Bierman

On Wed, Sep 26, 2018 at 9:09 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Sep 26, 2018 at 07:55:44AM -0700, Andy Bierman wrote:
> > On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli  wrote:
> >
> > > This is start of a two week poll on making
> > > draft-ietf-netmod-module-tags-02 a NetMod working group
> > > document.
> > >
> >
> >
> > I think we did this step already.
> > https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html
> >
> > Otherwise how would the draft be named draft-ietf-netmod?
> > Maybe you mean to start a WGLC, which I also support.
> >
>
> While we figure out what the action is, here are a few quick review
> comments:
> 
> - Standard tags defined in description statements
>
>   I do not like this. YANG has extension statements and having to
>   parse stuff out of free text description statements seems to be a
>   movement backwards.
>

It is even worse than a step backwards.
The draft specifies a lot of details about module tag conformance
that needs to be present in the description-stmt.

The idea that tools must screen-scrape description statements goes against
everything YANG-based management is all about. YANG has extension
statements, so we don't need to put complex syntax into comments and
descriptions.

IMO all text about module tag conformance and defining tags in
description-stmts
should be removed.  There is no explanation why a standard YANG module
would define multiple module-tags for the same module in the first place,
let alone why each different tag would have different conformance
requirements.

> .
>
> /js
>

Andy

>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

2018-09-26 Thread Juergen Schoenwaelder

On Wed, Sep 26, 2018 at 07:55:44AM -0700, Andy Bierman wrote:
> On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli  wrote:
> 
> > This is start of a two week poll on making
> > draft-ietf-netmod-module-tags-02 a NetMod working group
> > document.
> >
> 
> 
> I think we did this step already.
> https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html
> 
> Otherwise how would the draft be named draft-ietf-netmod?
> Maybe you mean to start a WGLC, which I also support.
>

While we figure out what the action is, here are a few quick review
comments:

- What does this mean? In particular the second sentence makes me wonder.

   Implementations MUST ensure that a modules tag list is consistent
   across any location from which the list is accessible.  So if a user
   adds a tag through configuration that tag should also be seen when
   using any augmentation that exposes the modules tag list.

- Wording - suggest to remove 'types':

Tags may be IANA assigned or privately defined types.";

- Leaf names:

   module: ietf-module-tags
   +--rw module-tags* [name]
  +--rw name  yang:yang-identifier
  +--rw tag*  string
  +--rw masked-tag*   string

   Name seems to refer to a module but this is not clear until you
   read the description. I understand that in RFC 7895 and its bis we
   also just use 'name' but I would find things easier to understand
   if we would have this:

   module: ietf-module-tags
   +--rw module-tags* [module]
  +--rw moduleyang:yang-identifier
  +--rw tags* string
  +--rw masked-tags*  string

   Note that I also used plural for the leaf-lists.

   In the description, I would also say "A list of tags associated
   with..."  instead of "A tag associated with...".

- Editorial

  s/This user/A user

- Adding and masking the same tag

  What happens if config adds a tag and masks the same tag? Is the
  masking taking priority in this case, i.e., you first all all tags
  and then you filter those that are masked?

- Standard tags defined in description statements

  I do not like this. YANG has extension statements and having to
  parse stuff out of free text description statements seems to be a
  movement backwards.

- System management

  What is 'system management' and a 'system management protocol'?

- Tag format

  Apparently, the colon has a special meaning in a tag string and
  otherwise there do not seem to be any restrictions. (Which is good,
  I can finally put various smileys on my gear.)

  Should we state explicitly somewhere that a colon has a special
  meaning and that tag strings are structured into a sequence of
  'taggies' separated by colons? Or is definition by example good
  enough?

- Meaning of tag masks

  Do masks mean a complete string match or can I mask along the prefix
  hierarchy, i.e., 'vendor:acme:' masks everything starting with
  'vendor:acme:'?

- Retrieval of the final list of tags

  Once I have configured tags and masks, how do I obtain the resulting
  tag list? Do I have to calculate this locally? Or will the final
  list be found in the operational state datastore (i.e., the applied
  config

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Martin Bjorklund

Juergen Schoenwaelder  wrote:
> On Wed, Sep 26, 2018 at 04:28:18PM +0100, Robert Wilton wrote:
> > My interpretation:
> > 
> > Option 2 is to disallow tabs in the output, but leave it to the
> > implementation to decide how to handle tabs in the input document, so a
> > script would be allowed to do a, b, or c.
> > 
> > Just supporting "option 2(a)" is the same as "option 1":
> > 
> >   1) RFC disallows TABS in both the source-input and folded-output.
> >  ***This is what we currently have***
> > 
> > Perhaps you mean that you prefer option 1?
> >
> 
> 1) or 2a) since 2b) and 2c) are not implementable in tools that are
> detached from the author and his/her editor and they will ultimately
> require to carry some metadata around and this means additional
> complexity for no real gain since the output has no TABs anyway.

I agree.  I prefer option 1.  If you do have tabs in your input,
simply translate them before running the folding algorithm.





/martin

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

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Juergen Schoenwaelder

On Wed, Sep 26, 2018 at 04:28:18PM +0100, Robert Wilton wrote:
> My interpretation:
> 
> Option 2 is to disallow tabs in the output, but leave it to the
> implementation to decide how to handle tabs in the input document, so a
> script would be allowed to do a, b, or c.
> 
> Just supporting "option 2(a)" is the same as "option 1":
> 
>   1) RFC disallows TABS in both the source-input and folded-output.
>  ***This is what we currently have***
> 
> Perhaps you mean that you prefer option 1?
>

1) or 2a) since 2b) and 2c) are not implementable in tools that are
detached from the author and his/her editor and they will ultimately
require to carry some metadata around and this means additional
complexity for no real gain since the output has no TABs anyway.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

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

Re: [netmod] IPR call draft-ietf-netmod-module-tags-02

2018-09-26 Thread Lou Berger


No, I'm not aware of any IPR that applies to this draft

Lou

On 9/26/2018 11:26 AM, joel jaeggli wrote:

Authors, Contributors, WG,

Regarding the document
draft-ietf-netmod-module-tags-02
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
Are you aware of any IPR that applies to draft identified above?


Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"


If yes, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state
either:
"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If no, please provide any additional details you think appropriate.


If you are listed as a document author or contributor, please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.


If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under the
IETF IPR rules which encourages you to notify the IETF if you are aware
of IPR of others on an IETF contribution, or to refrain from participating
in any contribution or discussion related to your undisclosed IPR. For
more information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.


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


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

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Robert Wilton


My interpretation:

Option 2 is to disallow tabs in the output, but leave it to the 
implementation to decide how to handle tabs in the input document, so a 
script would be allowed to do a, b, or c.


Just supporting "option 2(a)" is the same as "option 1":

  1) RFC disallows TABS in both the source-input and folded-output.
 ***This is what we currently have***

Perhaps you mean that you prefer option 1?

Thanks,
Rob


On 26/09/2018 16:22, Juergen Schoenwaelder wrote:

On Wed, Sep 26, 2018 at 02:09:52PM +, Kent Watsen wrote:

I recommend that we select "option-2" (see bottom).


[...]
  

   2) RFC disallows TABS only in the folded-output, per RFC 7991,
  leaving it to the folding-logic (the script) to decide if it
  wants to:
   a) disallow TABS in the source input (curr script does this)
   b) detect TABS exist and prompt user for TAB stop info
   c) detect TABS and query environment for cur TAB stop info
  (but tab-stops may differ in the shell the text editor,
  or whatever was used to create the text, right?)

Given that 2) has a)-c), I do not understand what the recommendation
actually is. The recommendation is hopefully 2a) and we are done.

/js



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

[netmod] IPR call draft-ietf-netmod-module-tags-02

2018-09-26 Thread joel jaeggli

Authors, Contributors, WG,

Regarding the document
draft-ietf-netmod-module-tags-02
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
Are you aware of any IPR that applies to draft identified above?


Please state either:
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"


If yes, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)? Please state
either:
"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If no, please provide any additional details you think appropriate.


If you are listed as a document author or contributor, please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.


If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under the
IETF IPR rules which encourages you to notify the IETF if you are aware
of IPR of others on an IETF contribution, or to refrain from participating
in any contribution or discussion related to your undisclosed IPR. For
more information, please see the RFCs listed above and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.


signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

2018-09-26 Thread Andy Bierman

On Wed, Sep 26, 2018 at 7:40 AM joel jaeggli  wrote:

> This is start of a two week poll on making
> draft-ietf-netmod-module-tags-02 a NetMod working group
> document.
>


I think we did this step already.
https://www.ietf.org/mail-archive/web/netmod/current/msg20344.html

Otherwise how would the draft be named draft-ietf-netmod?
Maybe you mean to start a WGLC, which I also support.


Andy


> You may review at:
> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
>
> Please send email to the list indicating "yes/support" or "no/do not
> support".  If indicating no, please state your reservations with the
> document.  If yes, please also feel free to provide comments you'd like
> to see addressed once the document is a WG document.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

2018-09-26 Thread Robert Wilton


Yes/support.

Thanks,
Rob


On 26/09/2018 15:40, joel jaeggli wrote:

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a NetMod working group
document.

You may review at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.



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


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

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

2018-09-26 Thread Acee Lindem (acee)

Yes/support
Thanks,
Acee

On 9/26/18, 10:41 AM, "netmod on behalf of joel jaeggli" 
 wrote:

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a NetMod working group
document.

You may review at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.



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

[netmod] WG adoption poll draft-ietf-netmod-module-tags-02

2018-09-26 Thread joel jaeggli

This is start of a two week poll on making
draft-ietf-netmod-module-tags-02 a NetMod working group
document.

You may review at:
https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02

Please send email to the list indicating "yes/support" or "no/do not
support".  If indicating no, please state your reservations with the
document.  If yes, please also feel free to provide comments you'd like
to see addressed once the document is a WG document.



signature.asc
Description: Message signed with OpenPGP
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Robert Wilton





On 26/09/2018 15:09, Kent Watsen wrote:

I recommend that we select "option-2" (see bottom).

Yes, option 2 seems reasonable to me.

Thanks,
Rob



- it easy to do.
- there's no current support for having tabs in folded output.
- doing so doesn't preclude an "option-3" someday in the future.

The authors will assume that this is WG consensus if there are no
objections within a week's time.

Kent // co-author


-Original Message-


[new subject line]

It is one thing for an editor to use tabs during the creation of text,
and another to publish text with an expectation that consumers will
render the tabs the same way.  Either the source editor converts tabs
to spaces, which is interoperable today, or keep the tabs while
publishing metadata in the text, using some TBD standard, enabling
consumers to use the same tab stops.

If there were a standard enabling the publishing of text including
tabs, it should work for all artwork, not just artwork that has been
folded.  This is similar to the discussion we had before about having
begin/end markers enabling perfect extractions, in that it is also
something that pertains to all artwork, not just artwork that has
been folded.

Thus, there are a total of three problems:
   P1: perfect extraction
   P2: tabs
   P3: long lines

Assuming all thing were solved problems, and assuming that we always
want perfect extraction, the possible combinations for the occurrence
of the other two problems are:
   - no tabs or long lines
   - tabs, but no long lines
   - long lines, but no tabs
   - tabs and long lines

How are they ordered?  Clearly supporting perfect extractions has
to be the outermost thing, but what about the other two?   Does it
matter?

Thinking about solutions:

  - the solution for long-lines is to use a header (not a footer)
because it's believed important to prime readers *before* they
read the text.

  - the solution for perfect-extraction could be either:
  - use both a header-and-footer marker (low tech)
  - or use either a header or a footer that encodes
something like a "num lines" value into the
marker.  (note: footer-only okay since the marker
is for programmatic processors, not the readers)

  - the solution for tabs could be to use either a header
or a footer that encodes the tab- stop metadata. (note:
footer-only okay since the marker is for programmatic
processors, not the readers)


If tabs were to be supported by the folding solution (note: it
doesn't make sense to talk about "folds being supporting by the
tabbing solution"), then either:

   a) tabs are handled *before* folding, and the folding-solution
  is aware of the tab-solution (i.e., it is able to process
  the metadata).

   - everybody nods ;)

   b) the folding-solution is really a folding+tab solution, that is,
  it has a built-in way of handling tabs (i.e., encoding tab stop
  metadata) independent of how tabs are handled for text that has
  not been folded.

   - this may be technically possible, but we should avoid having
 two solutions to solve the tab problem.  We would be better
 off solving the tab-problem directly and then use (a).

   c) the folding-solution folds using the source tab stops, but does
  not itself encode metadata about the tab stops, assuming that
  there is a "promise" that the encoding of the metadata will
  occur in a wrapper layer around it.

   - this feels icky, but it seems viable and, would possible
 allow us to proceed with this draft without having to solve
 the tabbing problem now.


Options:

   1) RFC disallows TABS in both the source-input and folded-output.
  ***This is what we currently have***

   2) RFC disallows TABS only in the folded-output, per RFC 7991,
  leaving it to the folding-logic (the script) to decide if it
  wants to:
   a) disallow TABS in the source input (curr script does this)
   b) detect TABS exist and prompt user for TAB stop info
   c) detect TABS and query environment for cur TAB stop info
  (but tab-stops may differ in the shell the text editor,
  or whatever was used to create the text, right?)

   3) RFC allows TABS in the folded output, and solves it by
  depending on a tab-solution, as described by (a).

   4) RFC allows TABS in the folded output, but does not solves it,
  as described by (c). This would probably NOT be allowed from
  a standardization perspective.


Moving to (2) would be easy and probably resolves most concerns
here.

Moving to (3) is possible, but we would do so only to:

  - support non-IETF use cases

  - or pave the way for an rfc7991bis that could depend on the
solutions we define here.

That is, rfc7991bis could *allow* long-lines and tabs while
`xml2rfc` applies the solutions being discussed here only
for when exporting the "plain-text" format (other formats
may have better ways

Re: [netmod] perfect extraction, tabs, and long lines - oh my

2018-09-26 Thread Kent Watsen



I recommend that we select "option-2" (see bottom).

- it easy to do.
- there's no current support for having tabs in folded output.
- doing so doesn't preclude an "option-3" someday in the future.

The authors will assume that this is WG consensus if there are no 
objections within a week's time.

Kent // co-author


-Original Message-


[new subject line]

It is one thing for an editor to use tabs during the creation of text,
and another to publish text with an expectation that consumers will
render the tabs the same way.  Either the source editor converts tabs
to spaces, which is interoperable today, or keep the tabs while
publishing metadata in the text, using some TBD standard, enabling
consumers to use the same tab stops.  

If there were a standard enabling the publishing of text including
tabs, it should work for all artwork, not just artwork that has been
folded.  This is similar to the discussion we had before about having
begin/end markers enabling perfect extractions, in that it is also
something that pertains to all artwork, not just artwork that has 
been folded.  

Thus, there are a total of three problems:
  P1: perfect extraction
  P2: tabs
  P3: long lines

Assuming all thing were solved problems, and assuming that we always
want perfect extraction, the possible combinations for the occurrence
of the other two problems are:
  - no tabs or long lines
  - tabs, but no long lines
  - long lines, but no tabs
  - tabs and long lines

How are they ordered?  Clearly supporting perfect extractions has 
to be the outermost thing, but what about the other two?   Does it
matter?

Thinking about solutions:

 - the solution for long-lines is to use a header (not a footer)
   because it's believed important to prime readers *before* they
   read the text.

 - the solution for perfect-extraction could be either:
 - use both a header-and-footer marker (low tech)
 - or use either a header or a footer that encodes
   something like a "num lines" value into the 
   marker.  (note: footer-only okay since the marker
   is for programmatic processors, not the readers)

 - the solution for tabs could be to use either a header
   or a footer that encodes the tab- stop metadata. (note:
   footer-only okay since the marker is for programmatic
   processors, not the readers)


If tabs were to be supported by the folding solution (note: it
doesn't make sense to talk about "folds being supporting by the
tabbing solution"), then either:

  a) tabs are handled *before* folding, and the folding-solution 
 is aware of the tab-solution (i.e., it is able to process 
 the metadata).

  - everybody nods ;)

  b) the folding-solution is really a folding+tab solution, that is,
 it has a built-in way of handling tabs (i.e., encoding tab stop
 metadata) independent of how tabs are handled for text that has
 not been folded.

  - this may be technically possible, but we should avoid having
two solutions to solve the tab problem.  We would be better
off solving the tab-problem directly and then use (a).

  c) the folding-solution folds using the source tab stops, but does
 not itself encode metadata about the tab stops, assuming that
 there is a "promise" that the encoding of the metadata will
 occur in a wrapper layer around it.

  - this feels icky, but it seems viable and, would possible
allow us to proceed with this draft without having to solve
the tabbing problem now.


Options:

  1) RFC disallows TABS in both the source-input and folded-output.
 ***This is what we currently have***

  2) RFC disallows TABS only in the folded-output, per RFC 7991,
 leaving it to the folding-logic (the script) to decide if it
 wants to:
  a) disallow TABS in the source input (curr script does this)
  b) detect TABS exist and prompt user for TAB stop info
  c) detect TABS and query environment for cur TAB stop info
 (but tab-stops may differ in the shell the text editor,
 or whatever was used to create the text, right?)

  3) RFC allows TABS in the folded output, and solves it by 
 depending on a tab-solution, as described by (a).

  4) RFC allows TABS in the folded output, but does not solves it,
 as described by (c). This would probably NOT be allowed from 
 a standardization perspective.


Moving to (2) would be easy and probably resolves most concerns
here.  

Moving to (3) is possible, but we would do so only to:

 - support non-IETF use cases

 - or pave the way for an rfc7991bis that could depend on the 
   solutions we define here.  

   That is, rfc7991bis could *allow* long-lines and tabs while
   `xml2rfc` applies the solutions being discussed here only
   for when exporting the "plain-text" format (other formats
   may have better ways to support perfect extractions and/or
   not care about long-lines or tabs).

   PS: as a corollary, realize that when we pre-textualizing

Re: [netmod] [Netconf] mbj's WGLC review of yang-push-17

2018-09-26 Thread tom petch



- Original Message -
From: "Robert Wilton" 
To: "Qin Wu" ; "Kent Watsen" ;
"Netconf" 
Sent: Wednesday, September 26, 2018 11:06 AM

> Hi Juergen,
>
> Yes, I think that updating RFC 6991 would be useful, if there are
types
> missing.


Give us a clue!

And isn't this one one for the netmod WG (a list that is pleasantly
quiet currently) ?

Tom Petch

> Thanks,
> Rob
>
>
> On 26/09/2018 10:28, Juergen Schoenwaelder wrote:
> > On Wed, Sep 26, 2018 at 08:00:26AM +, Qin Wu wrote:
> >> I wonder whether you really need a uint32 range of hours in the OAM
models.
> >>
> >> [Qin]: not necessary for OAM model, but It may be used in some
other models that require unint32 range of hours.
> > Authors may not want to depend on ietf-lime-time-types for generic
> > types for time periods, nor am I sure the solution there is a simple
> > solution.
> >
> > Perhaps its time to see whether it makes sense to spin an update of
> > RFC 6991 to add definitions that are apparently missing. Aftert 5
> > years this may be a reasonable thing to do. We should not hold off
> > work because of this but we may allow authors to transition to
common
> > definitions if what they do now is compatible with a common solution
> > underway. I would be willing to allocate some of my time to an
update
> > of RFC 6991 if the WG believes this is useful.
> >
> > /js
> >
>
> ___
> Netconf mailing list
> netc...@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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

[netmod] Adam Roach's No Objection on draft-ietf-netmod-acl-model-19: (with COMMENT)

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

Re: [netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

[netmod] Suresh Krishnan's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS)

Re: [netmod] Warren Kumari's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] IPR call draft-ietf-netmod-module-tags-02

[netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[netmod] Warren Kumari's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

Re: [netmod] New Version Notification for draft-kwatsen-netmod-artwork-folding-07.txt

Re: [netmod] perfect extraction, tabs, and long lines - oh my

Re: [netmod] perfect extraction, tabs, and long lines - oh my

Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] IPR call draft-ietf-netmod-module-tags-02

Re: [netmod] perfect extraction, tabs, and long lines - oh my

Re: [netmod] perfect extraction, tabs, and long lines - oh my

[netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

Re: [netmod] perfect extraction, tabs, and long lines - oh my

Re: [netmod] perfect extraction, tabs, and long lines - oh my

Re: [netmod] IPR call draft-ietf-netmod-module-tags-02

Re: [netmod] perfect extraction, tabs, and long lines - oh my

[netmod] IPR call draft-ietf-netmod-module-tags-02

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

Re: [netmod] WG adoption poll draft-ietf-netmod-module-tags-02

[netmod] WG adoption poll draft-ietf-netmod-module-tags-02

Re: [netmod] perfect extraction, tabs, and long lines - oh my

Re: [netmod] perfect extraction, tabs, and long lines - oh my

Re: [netmod] [Netconf] mbj's WGLC review of yang-push-17

36 matches

Site Navigation

Mail list logo

Footer information