Bonjour Éric, Thanks a lot for your feedback, Best regards, Sabine >-----Original Message----- >From: Eric Vyncke (evyncke) <[email protected]> >Sent: Friday, November 26, 2021 3:11 PM >To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ><[email protected]>; The IESG <[email protected]> >Cc: [email protected]; [email protected]; >[email protected]; Vijay Gurbani <[email protected]> >Subject: Re: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new- >20: (with COMMENT) > >Bonjour Sabine, > >Thank you for revision -21, it addresses all my previous non-blocking >comments. > >Have a nice WE! > >Regards > >-éric > >On 26/11/2021, 14:57, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" ><[email protected]> wrote: > > Hello Éric, > > A new version has been posted to address your comments. > We hope the updates meet your expectation and will like to have your >feedback. > Best regards, > Sabine and co-authors > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-21 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-21 > > > >-----Original Message----- > >From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) > ><[email protected]> > >Sent: Thursday, November 25, 2021 2:29 PM > >To: Éric Vyncke <[email protected]>; The IESG <[email protected]> > >Cc: [email protected]; [email protected]; > >[email protected]; Vijay Gurbani <[email protected]> > >Subject: RE: Éric Vyncke's No Objection on draft-ietf-alto-unified-props- >new- > >20: (with COMMENT) > > > >Hello Éric, > > > >Thanks a lot for your review and comments. > >Please find our answers inline. > >A version 21 is under edition and will integrate the changes upon your > >feedback. > > > >Best regards, > >Sabine and co-authors > > > >>-----Original Message----- > >>From: Éric Vyncke via Datatracker <[email protected]> > >>Sent: Monday, November 22, 2021 11:01 AM > >>To: The IESG <[email protected]> > >>Cc: [email protected]; [email protected]; > >>[email protected]; Vijay Gurbani <[email protected]>; > >>[email protected] > >>Subject: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new- >20: > >>(with COMMENT) > >> > >>Éric Vyncke has entered the following ballot position for > >>draft-ietf-alto-unified-props-new-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/blog/handling-iesg-ballot-positions/ > >>for more information about how to handle DISCUSS and COMMENT > >positions. > >> > >> > >>The document, along with other ballot positions, can be found here: > >>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ > >> > >> > >> > >>---------------------------------------------------------------------- > >>COMMENT: > >>---------------------------------------------------------------------- > >> > >>Thank you for the work put into this document. > >> > >>Please find below some non-blocking COMMENT points (but replies >would > >>be appreciated even if only for my own education), and some nits. > >> > >>Special thanks to Vijay Gurbani for the shepherd's extended write-up > >>about the WG consensus (even if not using the usual template). > >> > >>While the document supports clearly the two address families (IPv4 and > >>IPv6), I can only regret that the vast majority of examples are for IPv4. > >> > >>I hope that this helps to improve the document, > >> > >>Regards, > >> > >>-éric > >> > >>== COMMENTS == > >> > >>While the documents is very detailed, I would have preferred to have a > >>generic introduction of the concepts at the beginning. It also seems to > >>me that part of the text is repetitive. > > > >[ [SR] ] The Introduction indeed, lists features such as entity, entity > domain > >and its type, resource specific entity domain, Filtered/Property map, that >are > >introduced at high level w.r.t. how they address the limitations of the >current > >protocol. > > > >The generic introduction of the concepts is provided right after the > >Introduction, in the 4 pages Section 3. "Basic Features of the Entity >Property > >Map Extension". Section 3, in its introduction, also references a table > that > >summarizes all the features introduced by this extension, in the paragraph > >below: > >"The Entity Property Maps extension described in this document >introduces a > >number of features that are summarized in Appendix A, where Table 4 lists > >the features and references the sections in this document that give a > high- > >level and normative description thereof." > > > >Do you think it would be helpful to move this paragraph to Section > >1.Introduction, just before its last paragraph? > >> > >>-- Section 3.1 -- > >>I am a little puzzled by the use of "TCP/IP network flow" as it mixes up >layers. > >>Also, the "associated 5-tuple" is redundant because TCP has always 6 as > >>protocol so it is not really a 5-tuple as one is constant. > >> > >[ [SR] ] We propose to update item 5 as follows: > >OLD > >a TCP network flow, that is identified by a TCP 5-Tuple specifying its > source > >and destination addresses and port numbers and the utilized protocol, >NEW a > >TCP/UDP network flow, that is identified by a TCP/UDP 5-tuple specifying >its > >source and destination addresses and port numbers and the IP protocol > > > >>-- Section 4.6.1 -- > >>The use of "ane" is done before its explanation later in section 4.6.2. > >> > >[ [SR] ] As citing "ane" does not add anything to understand the point, we > >propose to remove it. > >We propose to update sentence in parag 2 as follows: > >OLD > >... > >This is useful for entity domain types that are by essence > domain-specific, > >such as "pid" and "ane" domain types. > >... > >NEW > >... > >This is useful for entity domain types that are by essence > domain-specific, > >such as the "pid" domain type. > >... > > > >>-- Section 5.1.3 -- > >>"net1.ipv6:2001:db8::1/48" is probably not an address block as it is a > >>/128 address. > >[ [SR] ] Thanks for catching this typo. We propose to replace > >"net1.ipv6:2001:db8::1/48" with "net1.ipv6:2001:db8::/48". > >> > >>-- Section 10.4 (and possibly others) -- Please use RFC 5398 when using > >>ASN in examples. > >> > >[ [SR] ] following section "4. IANA Considerations" of https://www.rfc- > >editor.org/rfc/pdfrfc/rfc5398.txt.pdf, > >we will use either of the 64496 - 64511 and 65536 - 65551 blocks reserved >by > >IANA for documentation purposes. > > > >Example ASN numbers 12345 and 12346 will be replaced with 65543, 65544 > > > >>-- Section 10.9 -- > >>Is the JSON reply valid ? > >> > >[ [SR] ] Indeed, the property values are not to be exposed with their > units, > >thanks a lot for this catch. > >The units will be removed and the reply will look like: > >OLD > >..... > >{"storage-capacity" : 40000 Gbytes, "cpu" : 500 Cores}, ..... > >NEW > >..... > >{"storage-capacity" : 40000, "cpu" : 500}, > > > >>-- Section 13 -- > >>No hard feeling but I find it strange that the acknowledgements section > >>also includes some affiliations. > >> > >[ [SR] ] we will remove the affiliations > > > >>== NITS == > >> > >>-- Section 10.1 -- > >>RFC 5792 prefers ipv6:::/0 to ipv6:::0/0 > >> > >[ [SR] ] Thanks a lot for catching this typo We will replace " > ipv6:::0/0" with " > >ipv6:::/0" in the examples > >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
