Re: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04

2018-09-26 Thread Dave Crocker 

Henrik,

Thanks for the quick followup...


On 9/26/2018 1:08 PM, Henrik Levkowetz wrote:

I think xml2rfc does the right thing.  The quotes are provided by
you, the author, not the processor, and you've enclosed the element
completely in the quotes:


yeah, sorry.  played with the combinatorials a bit more and agree.



xml2rfc is not a do-what-I-mean-not-what-I-say piece of code quite yet ,;-)


well, now, that's something to work on.

d/

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart telechat review of draft-ietf-softwire-mesh-multicast-23

2018-09-26 Thread Alissa Cooper 
Brian, thanks for your reviews of this document. WG, thanks for your responses. 

I entered a No Objection ballot. I think Ole’s response on your point below 
clarified this.

Alissa

> On Sep 21, 2018, at 8:19 PM, Brian Carpenter  
> wrote:
> 
> Reviewer: Brian Carpenter
> Review result: Ready with Issues
> 
> Gen-ART telechat review of draft-ietf-softwire-mesh-multicast-23
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-softwire-mesh-multicast-23.txt
> Reviewer: Brian Carpenter
> Review Date: 2018-09-22
> IETF LC End Date: 2018-09-06
> IESG Telechat date: 2018-09-27 
> 
> Summary: Ready with issues
> 
> 
> Comments: 
> -
> 
> Thank you for handling my Last Call comments. I am mentioning my previous
> issue again in case the IESG thinks any further change is needed.
> 
> Issue:
> --
> 
> "7.3.  Fragmentation
> 
>   The encapsulation performed by an upstream AFBR will increase the
>   size of packets.  As a result, the outgoing I-IP link MTU may not
>   accommodate the larger packet size.  It is not always possible for
>   core operators to increase the MTU of every link, thus fragmentation
>   after encapsulation and reassembling of encapsulated packets MUST be
>   supported by AFBRs [RFC5565].  The specific requirements for
>   fragmentation and tunnel configuration COULD be referred to in
>   [I-D.ietf-intarea-tunnels], which is under revision currently."
> 
> This text is significantly improved. However, I still wonder, if I-IP is
> IPv6, how does the originator of the IPv6 packet (the AFBR) know that it
> needs to include a fragment header? In addition to the discussion in
> [I-D.ietf-intarea-tunnels], isn't it necessary to specify that PMTUD
> should be enabled and that ICMPv6 packets must not be filtered?
> 
> Nit:
> 
> 
> Please change COULD to SHOULD in the above paragraph.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [DNSOP] Genart last call review of draft-ietf-dnsop-kskroll-sentinel-15

2018-09-26 Thread Alissa Cooper 
Jari, thank you for your review. Geoff, thanks for your responses. I have 
entered a No Objection ballot.

Alissa


> On Aug 30, 2018, at 10:10 PM, Jari Arkko  wrote:
> 
> Thanks for the responses, Geoff. 
> 
> One minor follow-up:
> 
>> The final point I am not so convinced about. The reason is scope of the 
>> document. This document is an instruction to folk who write DNS recursive 
>> resolvers. It is not an instruction to folk who want to set up zones that 
>> could be used to test KSK trust status. I would rather avoid adding text 
>> about the latter topic in this document, as I strongly prefer to leave it to 
>> others who may be sufficiently motivated to write a document about how to 
>> set up a measurement zone.
> 
> Oh, I do agree with this. However, as a reader I wasn’t sure if the document 
> expects that there be an existing name (with the special labels) or none is 
> needed. Does all this work fine, even if I don’t add anything to the sites 
> being used in the test? That might be worth clarifying, if it isn’t somewhere 
> already.
> 
> Jari
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ospf-segment-routing-msd-17

2018-09-26 Thread Alissa Cooper 
Paul, thanks for your review. I entered a No Objection ballot.

Alissa

> On Sep 14, 2018, at 10:57 AM, Paul Kyzivat  wrote:
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review 
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for the 
> IETF Chair. Please wait for direction from your document shepherd or AD 
> before posting a new version of the draft. For more information, please see 
> the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Document: draft-ietf-ospf-segment-routing-msd-20
> Reviewer: Paul Kyzivat
> Review Date: 2018-09-14
> IETF LC End Date: 2018-08-29
> IESG Telechat date: 2018-09-25
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that should be 
> fixed before publication.
> 
> Issues:
> 
> Major: 0
> Minor: 0
> Nits:  1
> 
> 1) NIT:
> 
> IdNits reports:
> 
> == Outdated reference: A later version (-15) exists of
>draft-ietf-isis-segment-routing-msd-13
> 
> We discussed this earlier during last call review and you indicated that it 
> must be a tooling issue because your document source doesn't reference a 
> particular version of this document. If so you can leave this to be fixed by 
> the editor during publication.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-netconf-nmda-netconf-06

2018-09-26 Thread Alissa Cooper 
Christer, thanks for your review. I have flagged your first comment in my No 
Objection ballot since it seems like a good point to clarify.

Alissa

> On Jul 16, 2018, at 6:55 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Tue, Jul 10, 2018 at 04:14:43AM -0700, Christer Holmberg wrote:
>> 
>> Minor issues:
>> 
>> Sometimes, when a draft updates an existing RFC, people ask whether
>> implementations not implementing the draft are still compliant with the 
>> updated
>> RFC. Based on discussions, the consensus seems to be that existing
>> implementations are still compliant, and if one wants to mandate the new
>> features a bis is needed. I would just like to confirm whether that applies
>> also to this draft. If so, perhaps a note indicating that would be useful, in
>> order to avoid discussions in future?
> 
> An existing NETCONF server not implementing NMDA is still compliant to
> the RFC 6241. However, a NETCONF server implementing NMDA (RFC 8342)
> has to implement this update to RFC 6241. Do you want to have this
> stated more explicitly? (We will have the same for RESTCONF and the
> NMDA update of RESTCONF.)
> 
>> Related to that, it would also be good to have an interoperability
>> statement, saying that implementations that implement the draft will
>> still work with implementations that do not.
> 
> This primarily concerns clients: They need to be able to fallback to
> using  instead of  and  instead of
>  if they communicate with a non NMDA NETCONF server. I am
> not sure whether this is a "SHOULD be able to fallback" or a "MUST be
> able to fallback".
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-netconf-nmda-restconf-04

2018-09-26 Thread Alissa Cooper 
Russ, thanks for your review. I have flagged it in my No Objection ballot since 
the edits have not been applied yet.

Alissa

> On Jun 28, 2018, at 3:47 PM, Russ Housley  wrote:
> 
> Reviewer: Russ Housley
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> .
> 
> Document: draft-ietf-netconf-nmda-restconf-04
> Reviewer: Russ Housley
> Review Date: 2018-06-28
> IETF LC End Date: 2018-07-09
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> 
> Major Concerns:
> 
> None.
> 
> 
> Minor Concerns:
> 
> The last paragraph of Section 3.1 says:
> 
>   If a server implements the example datastore "ds-ephemeral" in the
>   module "example-ds-ephemeral", it would implement the resource
>   {+restconf}/ds/example-ds-ephemeral:ds-ephemeral.
> 
> It is unclear to me why this datastore is not included in the bullets
> at the beginning of the section.  Obviously, it is optional to
> implement, but so are two of the datastores that are included in
> the list.
> 
> The last bullet of Section 3.2 says that [RFC8040], Section 3.5.4,
> paragraph 3 does not apply when interacting with any resource under
> {+restconf}/ds.  The referenced paragraph says:
> 
>   If the target of a GET method is a data node that represents a leaf
>   or leaf-list that has a default value and the leaf or leaf-list has
>   not been instantiated yet, the server MUST return the default value
>   or values that are in use by the server.  In this case, the server
>   MUST ignore its "basic-mode", described in Section 4.8.9, and return
>   the default value.
> 
> I suspect that this paragraph does not apply because the leaf and
> leaf-list will always be instantiated.  A sentence to say one way or
> the other would be useful to the implementer.
> 
> 
> Nits:
> 
> There is a missing ')' in the last paragraph of Section 5.
> 
> 
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04

2018-09-26 Thread Henrik Levkowetz 
Hi Dave,

Responding only to the xml2rfc issue, not to the document content:

On 2018-09-26 21:24, Dave Crocker wrote:
> On 9/24/2018 6:16 AM, Dave Crocker wrote:
>>>
>>> +  Those registered by IANA in the "Service Name and Transport
>>>  Protocol Port Number Registry [RFC6335]"
>>>
>>> Move the end quote after Registry.
>> 
>> ok.  Good catch.
> 
> 
> Interesting. Just discovered that this probably qualifies as a bug in 
> the xml2rfc processor tool at the IETF site.

I beg to differ.  More below:

> 
> (I only submitted the xml, which I think is formally ok.)
> 
> Here's the xml for that paragraph:
> 
>  Those registered by IANA in the "target="RFC6335">Service Name and Transport
>Protocol Port Number Registry" The
> underscore is prepended to the service
> parameters to avoid collisions with DNS labels
> that occur in nature, and the order is reversed
> to make it possible to do delegations, if
> needed, to different zones (and therefore
> providers of DNS).


I think xml2rfc does the right thing.  The quotes are provided by
you, the author, not the processor, and you've enclosed the element
completely in the quotes:

  "
Service Name and Transport Protocol Port Number Registry
   "

which as expected gives the  expansion enclosed in quotes:

  "Service Name and Transport Protocol Port Number Registry [RFC6335]"

The expansion of the  does not, and should not, change because
it's surrounded it by quotes.

If this was wanted:

"Service Name and Transport Protocol Port Number Registry" [RFC6335]

this should have been specified:

  
"Service Name and Transport Protocol Port Number Registry"
  

xml2rfc is not a do-what-I-mean-not-what-I-say piece of code quite yet ,;-)


Henrik




signature.asc
Description: OpenPGP digital signature
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04

2018-09-26 Thread Dave Crocker 

On 9/24/2018 6:16 AM, Dave Crocker wrote:


    +  Those registered by IANA in the "Service Name and Transport
 Protocol Port Number Registry [RFC6335]"

Move the end quote after Registry.


ok.  Good catch.



Interesting. Just discovered that this probably qualifies as a bug in 
the xml2rfc processor tool at the IETF site.


(I only submitted the xml, which I think is formally ok.)

Here's the xml for that paragraph:

Those registered by IANA in the "Service Name and Transport
  Protocol Port Number Registry" The
   underscore is prepended to the service
   parameters to avoid collisions with DNS labels
   that occur in nature, and the order is reversed
   to make it possible to do delegations, if
   needed, to different zones (and therefore
   providers of DNS).

(I'm changing the xml to avoid this bug for the next version.)


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art