Re: [alto] ?==?utf-8?q? ?==?utf-8?q? 5/3/2022 Meeting Minutes

2022-05-09 Thread Danny Lachos 

Hello Jordi, Kai, all
 
Thanks a lot for sharing,
I have a couple of quick comments/questions:
 
Regarding the OpenALTO meetings [0], I saw that Kai is currently working on 
integrate ALTO in DNS. If I do not wrong, it is supposed to use ALTO as a 
northbound interface to provide information about the domain name resolution to 
DNS clients, right?, if not, there is a chance to explain a little bit more 
about what is being done on ALTO/DNS?
 
Here at Benocs, we are also working with DNS information that is correlated 
with network traffic flows to obtain a multi-dimensional traffic information. 
In fact, we are implementing a PoC environment for the development of practical 
use cases. This PoC is able to read DNS traffic, network traffic flows, BGP 
information and then making correlations (real-time or batch processing).
 
In some point, could be interesting to find some kind of interception about 
what you/we are currently dealing in terms of technical and/or scientific 
challenges.
 On 04.05.22 14:12, Jordi Ros Giralt wrote:Thank you very much Jensen for 
taking meeting minutes yesterday.  For those who could not attend our call 
yesterday (and for our bookkeeping), here you will find them: 
https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2022.md
 Going forward, you will also find minutes for the OpenALTO meetings being held 
weekly too (Mon, Wed and Thu) here: 
https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-openalto-2022.md.
 As you know, everyone is invited to attend these other meetings that focus on 
the implementation of the Standard, see the meeting coordinates in this 
previous link for days and zoom link. This action resolves ticket  
https://github.com/ietf-wg-alto/wg-materials/issues/23 Thanks,Jordi on behalf 
of ALTO WG  ___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
--
Best regards,

Dr.-Ing. Danny Lachos
BENOCS GMBH
www.benocs.com


[0] 
https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-openalto-2022.md
 
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Question on ANE name format

2022-05-09 Thread Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
Dear ALTO WG and chairs and area directors,

The document draft-ietf-alto-unified-props-new-24 
(https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24.txt 
) has now entered AUTH48 and is on its way to be published as RFC 9240,  once 
it has been reviewed and approved by all coauthors.

In draft-ietf-alto-unified-props-new-24  - Section 10.9. Filtered Property Map 
for ANEs Example #5,  there is an issue, regarding the ANEs name format, on 
which we would like to have your thoughts and WG chair and area director 
guidance.
Two example ANEs are provided in  Section 10.9.: ".ane:dc45.srv9" and 
".ane:dc6.srv-cluster8".
That is, their ANE names are respectively: "dc45.srv9" and "dc6.srv-cluster8" 
and both include the '.' separator (U+002E).

- The ANE name format is specified in draft-ietf-alto-path-vector-25: 
https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-25.txt 
Section 6.1 ANE name.
"An ANE Name is encoded as a JSON string with the same format as that of the 
type PIDName (Section 10.1 of [RFC7285]) "

- In Section 10.1 of [RFC7285] https://datatracker.ietf.org/doc/html/rfc7285
"A PID Name is encoded as a JSON string. The string MUST be no more than 64 
characters, and it MUST NOT contain characters other than US- ASCII 
alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the 
hyphen ('-', U+002D), the colon (':', U+003A), the at sign ('@', code point 
U+0040), the low line ('_', U+005F), or the '.' separator (U+002E).
The '.' separator is reserved for future use and MUST NOT be used unless 
specifically indicated in this document, or an extension document."

Since Section 6.1 ANE name of draft-ietf-alto-path-vector-25 does not 
explicitly allow the '.' separator (U+002E), the example ANE names provided in 
Section 10.9.of draft-ietf-alto-unified-props-new-24 are illegal.

To solve this issue, three options have been identified:
-- OPTION 1: correct the examples in  Section 10.9. of  
draft-ietf-alto-unified-props-new-24, with for instance:
OLD
".ane:dc45.srv9" and ".ane:dc6.srv-cluster8"
NEW
".ane:dc45_srv9" and ".ane:dc6_srv-cluster8"  OR ".ane:dc45-srv9" and 
".ane:dc6-srvcluster8"

-- OPTION 2: relax the ANE name format in Section 6.1 ANE name of 
draft-ietf-alto-path-vector-25.
Given that PV is as well in the RFC Ed Queue, this may be too late or too 
complicated at this stage.  After all, an ANE name and a PID name are to be 
interpreted as a string. On the other hand, upon discussions with the PV 
co-authors, there is no  particular reason to forbid '.'.
The text of section 6.1 of draft-ietf-alto-path-vector-25 may be updated as 
follows:

OLD
An ANE Name is encoded as a JSON string with the same format as that
of the type PIDName (Section 10.1 of [RFC7285]).
The type ANEName is used in this document to indicate a string of
this format.

NEW
An ANE Name is encoded as a JSON string with the same format as that
of the type PIDName (Section 10.1 of [RFC7285]).
The type ANEName is used in this document to indicate a string of
this format.
This document allows to use the '.' separator (U+002E).

-- OPTION 3: correct the examples in  Section 10.9. of UP with for 
instance +  propose extensions on ANE name format in future use cases.

What do you recommend?
Thanks a lot in advance
Sabine and co-authors
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Genart last call review of draft-ietf-alto-cost-mode-02

2022-05-09 Thread mohamed.boucadair 
Hi Roni, 

Thank you for the review. It will be ACKed in the next iteration of the draft. 

Cheers,
Med

> -Message d'origine-
> De : Roni Even via Datatracker 
> Envoyé : samedi 7 mai 2022 13:39
> À : gen-...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-cost-mode@ietf.org; last-
> c...@ietf.org
> Objet : Genart last call review of draft-ietf-alto-cost-mode-02
> 
> Reviewer: Roni Even
> Review result: Ready
> 
> 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-alto-cost-mode-??
> Reviewer: Roni Even
> Review Date: 2022-05-07
> IETF LC End Date: 2022-05-13
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is ready for publication as a standard track
> RFC
> 
> Major issues:
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

Re: [alto] Last Call: (A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol) to Proposed Standard

2022-05-09 Thread mohamed.boucadair 
Hi Ben, 

Thank you for the comment. 

I think that you got the reasoning for not including such an encouragement 
text. 

BTW, I expect that the main concern will be related to modifying modes so that 
cost metrics are erroneously interpreted. That risk falls under 15.1 of 7285.  

Cheers,
Med

> -Message d'origine-
> De : alto  De la part de Benjamin Kaduk
> Envoyé : dimanche 8 mai 2022 05:53
> À : last-c...@ietf.org
> Cc : alto@ietf.org; draft-ietf-alto-cost-m...@ietf.org
> Objet : Re: [alto] Last Call: 
> (A Cost Mode Registry for the Application-Layer Traffic
> Optimization (ALTO) Protocol) to Proposed Standard
> 
> On Fri, Apr 29, 2022 at 06:57:26AM -0700, The IESG wrote:
> >
> > The IESG has received a request from the Application-Layer
> Traffic
> > Optimization WG (alto) to consider the following document: - 'A
> Cost
> > Mode Registry for the Application-Layer Traffic Optimization
> >(ALTO) Protocol'
> >as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
> solicits
> > final comments on this action. Please send substantive comments
> to the
> > last-c...@ietf.org mailing lists by 2022-05-13. Exceptionally,
> > comments may be sent to i...@ietf.org instead. In either case,
> please
> > retain the beginning of the Subject line to allow automated
> sorting.
> 
> This document is meeting a real need by fleshing out an extension
> point for ALTO that was previously over-constrained and not
> actually usable for extensions.
> 
> The security considerations section currently just defers to the
> core ALTO procotol spec, RFC 7285.  This seems appropriate, as
> this document is just opening up the extension point, but we might
> also consider providing specific encouragement for authors of new
> cost modes to document considerations unique to that cost mode.
> Hopefully such documents would already provide comprehensive
> security considerations, though, so it does not seem strictly
> needed for us to say anything here.
> 
> -Ben
> 
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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